7DRL Takeaway Lessons

I promise this will be my last 7DRL post, but I thought I should record some thoughts I’ve had about it now that it is over.

This post could alternately be called “Why I Will Not Use MonoGame in the Foreseeable Future.”

First, the motto of MonoGame is “Write Once, Play Everywhere.” This sounded promising to me, because my first game had issues deploying almost anywhere. Of course, what they mean is that you can play anywhere supported by Windows.

There are ways to get builds onto other platforms so that Mac and Linux users can play, but I only had 7 days, and I’m not a trained computer scientist, so that wasn’t going to happen. This was a little frustrating, and also one Windows user already complained they couldn’t get it installed.

Second, MonoGame is effectively a re-implementation of XNA 4. Unfortunately, some of the pipelines (especially with an up to date Visual Studio) are broken and require hacks to work. This caused major problems with sound. So much so that I scratched all sound from the game.

I know that with enough time, I probably could have gotten this working (because lots of games made with it have sound), but I couldn’t waste the time in those 7 days to fight with it. This was frustrating, because one of the main reasons to use MonoGame was to make all of that streamlined and easy.

I also felt trapped into using Visual Studio as an IDE. This is certainly a fine IDE, but I’m most comfortable with Sublime Text 2. Switching editors wastes a lot of time, especially when you “downgrade.”

By this I mean VS doesn’t have half the great features of ST2 (including my most used feature: multiple cursors). In retrospect, I should have edited in ST2 and built in VS.

All this being said, MonoGame was a good enough framework to produce a full working game in 7 days, so I can’t complain too much. Also, if I were part of a larger team with a longer time frame, many of these issues would disappear. So I admit these complaints come specifically from the 7 day issue.

If I do this again, I will almost certainly try Cocos2d-x. It looks like this will fix all the complaints I had. First, Cocos2d-x is open source. This means I can actually see what the engine is doing if I need to! What a concept.

Second, it is C++, so it will deploy across platforms much easier. Lastly, it isn’t in some transition period like MonoGame where content management seems to use outdated, unsupported pipelines. I’m also more familiar with C++ than C# which would have solved a few headaches.


Theseus: a 7DRL 2015 Completed!

Final Stats:

One week.
About 90 hand drawn 64×64 pixel tiles.
Over 2000 lines of code.
A completed one-hp strategy roguelike.

Proof that it can be beaten happened during my stream where I tested for bugs (quality isn’t the best):

Actually, I think I’ve finally gotten it balanced so that you should be able to win if you know what you are doing every time except for extraordinarily rare scenarios dictated by the randomness.

7DRL 2015 Success.

[Edit:] I’ve set up an itch page: http://hilbert90.itch.io/theseus
Download the game to play for free here: https://www.dropbox.com/sh/1ywjy7s3y72bq5k/AABOZWsPOFBYs0qgcxW5Ccqxa?dl=0

7DRL: Theseus, Alpha Testing Phase

Alright. I have to leave for the day. I’ve thrown a few more things in this morning at the last minute, and then built the whole game.

If anyone wants to test it and give feedback, that would be much appreciated. I’ll still do a lot of polishing tomorrow.

Sorry, as of right now I have a build that I’m 99% positive will work on any Windows 7 or 8 machine. Earlier probably works, but hasn’t been tested. I haven’t made any others (the opposite of my first game which people could only get to work on Linux).

I’ve learned my lesson. If I do this again, I’ll probably switch to Cocos2d-x, which is open source, and easily builds into any machine.

Types of things I’m looking for:

1. The whole thing crashes. If this happens, try to remember exactly what happened and leave a comment.

2. The setup doesn’t install it on your computer, but you are using Windows. Let me know something about your computer if this happens.

3. The game is too easy (for example, you consistently scale up too quickly and bash your way to victory with no thought).

4. You can let me know if it is too hard, but I probably won’t change that.

5. Anything else that seems reasonable to need a fix for being on Day 6 of developing a game (you can say the art is not polished, but that will just hurt my feelings … it’s Day 6 and I had a lot of other things to do for goodness sake).

6. The Readme didn’t have enough information.

Tonight or tomorrow, I’ll probably add 2 more items for reference of what will be added before the final release.

Thanks. Have fun.

I’ll think of a better way of distributing this later. For now, go here: https://github.com/wardm4/Theseus

Press Download Zip (button to right). Ignore all the files except the one called “Theseus.zip” Right click on that and save it somewhere (your Downloads folder or whatever). Unzip it and then double click on setup.exe. That will prompt a standard install.

Better yet. I’ve added just the zip to a Dropbox here if you don’t want to get the source code too: https://www.dropbox.com/sh/1ywjy7s3y72bq5k/AABOZWsPOFBYs0qgcxW5Ccqxa?dl=0

7DRL Dev Log Day 5

Today turned out well. I didn’t get trapped trying to fix some problematic C# syntax like in the past two days. The main improvements were to draw the final boss, get him animated, program his AI, and get the final room set up (which has different design structure than the rest of the labyrinth).

I did some balancing with the boss to figure out how much HP seemed reasonable for what level I thought an average person would be at. I also drew, animated, and designed an AI for a new NPC that will make an appearance later in the game. They are pretty tricky, so I imagine a bunch of deaths for people who dare to make an attempt at them.

The game feels reasonably complete at this point. There is a nice progression leading up to the final boss, and you win the game if you kill it. I made a push to get it to this point before today, because it turns out that tomorrow I’ll have almost no time to work on it at all.

I have two more significant additions I want to make, and then tons of polishing I can do (tons of extra animations, sound, balancing, bug finding and fixing, etc). Overall, I’m finding the game a bit too easy, but my alpha tester hasn’t beaten it yet, so who knows. If you know all the enemy patterns (like I do), then I think it is beatable pretty much every time with caution. I never came across an impossible situation today.

Tomorrow I’ll give a download of the most up-to-date version in case any readers want to volunteer a few playthroughs to give some feedback before the end of the last day.

7DRL Dev Log Day 4

Today I’ve put in some more details, but I still haven’t gotten around to programming the final fight, so the game technically goes on forever right now. I plan to do that first thing tomorrow.

I added another weapon and a bunch more items, which will be one of the main things that keep repeated plays interesting. The weapon was a spear (technically a bident) which can damage enemies at range.

I’ll keep the items a mystery, but I will say that items all have positive effects. This choice came from two places. The first is that in a “one HP” roguelike, you cannot have much by way of negative effects without causing an unfair death.

The second is that I really want everything identifiable on sight, because part of the strategy is to make hard choices about what to use and what to keep. You have a weapon slot and a spacebar item slot (in my head these correspond to what you hold in your two hands).

Since the maze has no backtracking, you can’t bring two really good items with you. Items are fairly sparse, which I like. The game should be beatable without any, so finding something will make the run more enjoyable and safer.

I also implemented the dragon I drew last time into the game. Again, today’s changes were mostly behind the scenes, so there isn’t really a screenshot that helps you see what has happened. Instead, I’ll post a video with sample gameplay.

Don’t watch if you want to experience it yourself. I’ve gotten a lot of standard movement patterns down after playing it a bunch, so I might spoil how to handle lots of situations.

7DRL Dev Log Day 3

Yesterday I got through the hardest coding section of the game. I separated out the zone logic into it’s own class, so I could make repeat calls and chain together the zones to make a large labyrinth.

I also implemented experience points, level up, more of the GUI, and fixed many of the bugs I had from day one like spawining in an instant death situation, enemies occupying the same square, and a permanent stun effect.

Also, there is an annoying bug where the game crashes if I put sound in it on some machines (maybe it is just Windows 7?). I may end up not doing sound and music to be safe.

Most of these changes were under the hood, so it doesn’t look much different right now:


Today I got hung up on a few technicalities with C#. I guess I should have practiced some basics more before this week to avoid wasting time. Apparently, when you iterate through a list, you can only read the objects you iterate over (you can’t set them to new values). This caused lots of confusion for a bit while I tried to work out what was wrong.

I had a pretty good day. I realized lots of stuff was hard to see/read with the fancy vector swept background. I’m not sure I like what I’ve switched to, but it is certainly better from a readability standpoint, and makes the various sprites pop a lot more:


Other than that, I did a lot of art again. I added some items and a new weapon. This meant drawing the various places the item could be, and then redoing the main character sprite with the new weapon in its various positions. The weapon has a pretty cool mechanic attached: it is a damage multiplier, so super over-powered, but it is heavy, so it costs a turn to turn around while holding it. This drawback may make it too risky to be worth it putting in an interesting choice.

I also completed a new enemy, a dragon. It is the best thing I’ve ever made with pixel art (I only started learning a few weeks ago):


I animated him by just bobbing up and down and breathing fire so that I wouldn’t have to deal with the intricacies of moving the wings. It’s coming together and finally feels like a real game.

7DRL Dev Log Day 1

Today the 7DRL began (for me at least)!

I got through everything I wanted to with time to spare. I mostly built the art today and got some stuff displayed. I settled on a 960×545 window (unchangeable, because I don’t want to deal with scaling at the moment) with each segment of the maze being a 40×20 grid of 64×64 tiles. Once you leave a segment, the previous part will change.

Today I drew the title screen, a “lose” screen, a “win” screen, the background, 3 wall tiles, 3 floor tiles, a fire elemental enemy, a raven enemy, and some of the GUI (health, weapon, and item get displayed).

Here’s two screen shots:



Both of the enemy types are fully animated, but the fire could use some work later if there is time. I’ve implemented movement patterns for the two enemies, and trigger win/lose conditions if you clear the area (not the real win condition, just testing!) or die.

Overall, this was a wildly successful day, but all of the hard coding is ahead of me, not to mention, I’ve only thought of one weapon and one item so far.