Towers of the Prophet Recap: Part 2

After a relaxing Fourth of July I think it is time to get back to my recap of the making of my seven day game, Towers of the Prophet.

(This is a shot of the finished game for comaprison to the WIP shots below)

I had planned for my second day to be dedicated to finishing up a fully functional tower defense game.  I figured I should have all of those ducks in a row before I started adding in the melee combat elements.  I had plans to implement those on my third day of work, Friday. 

Thursday started off very well and I cranked out a good list of new features, UI tweaks, and bug-fixes by lunch.   Many of the fixes I made were based on feedback given from a few of my close friends who play tested the game for me at every stage.  This process definitely showed me the value of constant play testing.  Some of the games I had finished in the past didn’t really have much play testing and, if they did, it was at the very end of the design process so not much could be changed.  By having a couple of people who tested for the whole development of the game I was able to spot frustrations and usability problems early on.  It also helped me by forcing me to have a “shippable” build every day for them to test. 

This sort of iterative design process was meant to help me “find the fun” early on.  However, after pouring most of my Thursday into putting the tower defense stuff together I didn't feel like the game was very fun or interesting.  The feedback I got from my testers, while supportive, seemed to have a similar vibe.  It was early in the evening and I had planned to spend the rest of the night building some new tower types and the trying to balance all of them but I was losing steam quickly.  I knew if I wanted to keep my motivation I needed to keep things fun.  I wanted to get the melee combat in there as soon as I could just to see if the game would be fun at all.  I figured if it still wasn’t fun after adding that in I would probably scrap the project. 

So I abandoned my list of stuff I wanted to do for the tower defense part and went to work on getting a basic version of the melee stuff in the game.  By around midnight I had a prototype with melee working.  After playing around a little I knew that I had found the fun I was looking for.  I went to bed confident that my game might yet be a success. 

Friday I had a shorter list of stuff to do but each item would take a significant chunk of time.  I spent the morning getting some basic usability features in place for the UI.  I had been on projects where this stuff got put on the backburner and you ended up with a game that was really fun to play… if you were the guy who programmed it and knew all the tricks.  For all other people the games seemed unplayable due to poor interface. 

So UI was a priority this time.  I know it Is not the prettiest but it has all the info you need.  After getting tooltips, health bars and a few other things working I decided to tackle the big task of the day, reworking the enemy spawn handler.   I had hacked something together for the initial prototype but it was hard to tweak wave composition and it definitely would not scale with different levels.  I decided to break the spawner up into two objects.  The spawn master, that calculates what kind and how many enemies to spawn in each wave and divided them up among spawn points, and the spawn points that spawn enemies from the selection they are given in a somewhat randomized fashion.  I wanted the spawn master to be able to make waves of any composition and to send different “orders” to each spawn point.  I actually sat down and wrote pre-code for both the objects, which I usually don’t do.  It took a few hours to work everything out but I was happy with the results.  I knew that bit of work would not be very visible to the player but it would prove invaluable later when I needed to balance the game for my release.

After some more play testing I was getting some very positive feedback and knew the changes I had made were worthwhile. 

Next, I’ll cover the polishing, balancing, and pixle-arting of Saturday and Sunday.



Towers of the Prophet Recap: Part 1

Welcome to my blog.  Here I will be covering my perspective on games I play, culture I enjoy consuming and the games I make.  For my first few posts I have decided to go over the process that I went through while making Towers of the Prophet in seven days.  It will be like a mini post-mortem.  What went right? What went wrong? What would I do differently? Ext.  I always find these types of articles interesting and full of good insight when I read them on Gamasutra.  Hopefully this article will prove useful, or at the very least, entertaining. 

I made Towers of the Prophet for the Experimental Gameplay Project’s June theme, Mashup.  They suggest that the game is made in seven days by one person and I decided to take on these constraints.  I have started many games that never got finished due to a lack of direction.  I figured that the tight schedule would make me stay focused. 

The idea for the game came from a few things I don’t like about many tower defense games.  There are decisions to make in between waves of enemies but for the most part you are a passive observer just watching the towers shoot and the enemies walk along.  In addition, I never really enjoyed the “mazing” or “juggling” aspects of the genre.  Why would these enemies walk such a long way when they could just destroy the one tower with a whopping 5 hp instead?  I wanted my game to be engaging during the whole game and have enemies that exhibited at least a little bit of intelligence. 

One game I looked at as an example was Revenge of the Titans which does a good job of having intelligent enemies and keeping the player engaged.  It’s a fun game although it gets pretty stinking difficult.  I figured this type of gameplay would mesh well with a 2d hack and slash since both genres use large numbers of weaker enemies to try and overwhelm you.  There are many great games in this genre, Diablo being the most obvious, but I wanted a more responsive control scheme.  I looked at twin stick shooters for inspiration.  I had not seen any that used melee combat but I thought it would work.  (You can let me know of any that exist)

So with this little bit of brainstorming I set out to make my tower-defense, twin-stick Hack-n-slash mashup. (You can call it a “TowDe-TwiSti-HashUp” for short)   I chose to make it using Game Maker 8.1 because it makes prototyping super-fast. 

The first thing I did was build a feature backlog and a roadmap that looked something like this.

Wednesday – Tower Defense Framework
Thursday – Tower Defense Polish
Friday – Build warrior and melee stuff
Saturday – Polish, Polish, Polish
Sunday – Sound, Polish, Polish
Monday –Art and Sound, Polish
Tuesday – Art and Polish

I put in a solid day of work that Wednesday and finished a solid tower defense framework. 

This is what things were looking like after day 1. 

Tomorrow I’ll cover how Thursday and Friday went and what changes were made.