Dungeon Quest Post-MortemDesignI wanted a game that would satisfy some gamers' sense of retro nostalgia, something like an arcade mini-RPG like the original Gauntlet games. Something that I would enjoy playing. The idea really solidified when I realized that I could create regions as rooms, to trigger monsters to attack the player upon entering the room/region. This gives a natural progression and flow to fighting monsters and I think it's elegant design because it allows the player a soft difficulty control by choosing how fast they enter rooms to trigger more monsters.
Allowing 3 chooseable classes increased development time by almost a factor of 3. I probably could have done things in a more efficient way, but the way I set it up I had to make 1 scene for each class for each level. I ended up creating a level once for Paladin, in its entirety, then duplicating it twice for Nomad and Warlock and recustomizing/resetting targets for all the enemy actors for each level. Very tedious.
Also once I had my level completely designed, I wasn't able to mess with it much because I had to make identical changes to the other 2 classes' levels, which may have hampered my post-design play testing and tweaking a bit. Once I finished a level design, it was awkward to make serious changes, although I did make many small changes to balance each level.
My design tends toward more hardcore play styles which are not always accessible to everyone. I tried to tone down the difficulty after incorporating specific feedback but the game probably should have been a little easier in general.
ProgrammingI basically taught myself Stencyl while making this game. I had made some half completed prototypes for a few simple games but I was almost entirely unfamiliar with Stencyl programming when I started this. I'm pretty proud of how much I learned and I think that just in terms of programming, I probably achieved as much as anyone did in this jam.
I had no idea how much time I would spend troubleshooting bugs and performance issues. I probably spent at least 15-20% of the final development time just on working out bugs. I'm very happy that there are no game-breaking bugs in the final version, although there are just a couple of not-ideal interactions that I wasn't able to solve, such as the collisions that happen when Nomad uses his Dancing Scimitars ability. I did make efforts to fix it, but wasn't able to figure out, or didn't have time to figure out what exactly was happening with those collisions.
If I made a list of specific things I fixed for the final version throughout the design process, it would definitely be in the hundreds.
ArtMy art graphics were adapted from sprite sheets from other games. Even though I didn't make them from scratch, I certainly put tons of hours into cropping files, making images transparent, making the animations and sizing collision boxes based on image sizes. I have to wonder if not having original graphics was a factor in not winning, but I really didn't have the time to be able to teach myself Stencyl programming and from-sratch pixel art simultaneously so I just decided to go with the art I could find. I do think that the game achieved a very coherent aesthetic considering that the sprites are culled from a half dozen or so games, and I feel good about being honest about where the sprites came from.
MusicI had fun finding songs for the soundtrack, which I think is pretty epic. I did get some feedback though that it didn't suit the game, and it may have been better suited to a retro styled chiptune soundtrack. I do have many years of sound design and electronic music experience so for my next game I will strive for all original sound. I think all the sound effects in the game work pretty well for their functions.
Play TestingI underestimated how significant play testing can be in the design process. One of my testers gave me a totally crucial suggestion early on that completely changed the flow of the game, by doubling the speed of player and enemy movement I achieved something much closer to the arcade feel that I was going for, then I originally had at the movement speeds I started with. Through this I realized how important speed of movement is to games in general, but especially for an arcade style game. Each of my testers gave me very different feedback about what they didn't like, and I was able to get a better sense of the game's difficulty with feedback from more people. The more testers you have, the more accurate your objective sense of the game will be.
Mistakes
I feel like my biggest mistake was the switch on level 4 inside the bricks that the player can pass through, but look like regular bricks. I wonder how much time people may have spent trying to figure that out and been frustrated. My failure was to not provide adequate information to the player that his character was able to move through the solid bricks. One of my play testers said “You lost my trust” at that part because I didn't give enough indication that I was “breaking” one of my game rules. That should have been a big red flag to me to change it! The solid-yet-passable bricks would have been perfect for a secret area, but shouldn't have been used for a puzzle that was necessary to finish the level.
Aside from that, the only other major mistake that really bugs me is the collisions on Nomad when he does Dancing Scimitars, but as I said, I wasn't able to fix that in the time I had. The Werewolf boss is particularly bad in this regard.
There's also an issue with using the tutorial character screens which set off the player's ability cooldowns, which I didn't consider in testing.
I'm happy to say that other than that and a few other minor unintended interactions, I don't feel like there are many major mistakes in the game!
What I LearnedLimiting global attributes to only the ones you really need, and using scene/behavior attributes for everything is better for performance.
Create regular actor / kill and not doing Create actor / recycle is crucial for performance.
Having only a few actors in the scene set to Always Active is crucial for performance.
Having customized actors for enemies leads to some tedious programming, but may be crucial for some interactions to work (ie. follow player target).
Persistent upgradable stats are fairly complicated to implement, at least for this game.
Boss fights need more detailed balance testing than normal levels.
The more testers you can have at an early stage of development, the better. Ideally I would want detailed feedback from at least 10 people for any game.
Movement speeds are very important to overall game design.
Collision box sizes are also really important.
Showing the player information on the UI, specifically the cooldowns for both abilities, greatly improved the ease of play.
I will be editing for a final post-jam version of the game that fixes the issues mentioned above. I would like to know more about the details of sponsorship from flash game portals like Newgrounds, so if anyone has any advice on how to make that happen please let me know in one of my threads or by PMs. Thanks!
Also, anyone interested in doing art for my next game?
