Cormania Game Dev Diary (pt. 8) – The End

I slacked off for a week writing a blog, so this post actually represents two weeks of work. However, I can say that if there seems to be a lot done, it’s not just because there is two weeks of work involved. By the second week, I realized I was on the home stretch and did a lot of work. This will be the last blog post I forsee for CBI.

There were a lot of dead ends the week after the last blog post. I was trying to get a good options system going. I first thought of perhaps adding an “options” room, but with so few things for the player to actually manipulate, I thought that felt like a waste and it would be better for the player to simply have an options dialogue box that appeared over the content. It would allow the player to manipulate sound and music volume and turn graphical goodies such as shaders on or off. Creating the dialogue box took some work, but the big problem was that other parts of the game were still running whenever the dialogue box was on. I did not want to have other elements of the game interfering, so I had to find a way to turn them off.

This is very similar to the problem of implementing a pause system in GameMaker: Studio. One usually wants the game to freeze when paused, and the common solution is to deactivate instances that you want paused, then activating them when unpaused. There is often a screenshot drawn as well, to make it appear as if the game has frozen. This works fine unless you have instances deactivated for some reason other than for pausing; unpausing the game will reactivate those instances even though you don’t want them reactivated. Since I had to deactivate instances for a number of reasons besides pausing, this was a serious problem for me that I needed to overcome.

I looked in the YoYo Games Marketplace and tried to find a pause system that would not reactivate everything when unpausing. I ended up trying Crystal Fortress’s system. It works by pausing objects only if they have a parent object that indicates they are pausable (this object is called par_pausable). It will also draw those instances to a surface and draw that surface to the screen, which is a way of taking a screenshot of the paused state. Unfortunately, this did not work for me. I had lots of elements being drawn in the GUI layer that I wanted paused that I don’t think could be captured, and the parent object approach still wasn’t good enough. It was simply too complicated a system and various elements would not work with it, so I had to give up on it completely. In the end, I dumped the “Options” dialogue box and just put two buttons at the bottom of the screen to control music and sound. This very simple solution was the end result of hours of wasted time, although I suppose I did learn a lot, and gave me ideas of how I could come up with a better pause system that, at least in theory, should be able to circumvent the activation/deactivation problems.

After that ordeal came adding the final animations to the game. I added dashed lines to be drawn from a nuclear warhead to its origin, giving the game more of that WarGames feel. And I added animations. Before, when the player orders an attack the game processes the locations of the nuke targets and determines what silos are destroyed. If not all are destroyed, the game ends. Now, nukes actually fly from the silos to their targets and explode (with an animation) once the target it reached. The explosion is an object that destroys all enemy silos once its animation ends. When all explosions and player nukes are gone, a control object checks to see if any enemy silos remain. If even one has survived, it reveals the surviving silos and launches nukes from them, and once they have landed, the text “Game Over” types on the screen. If all were destroyed, “Victory” is typed. The end cinematics look really good and I am proud of how they turned out. In fact, they’re the most enjoyable part of the game.

Next came adding shaders. Like with the options dialogue box, this ended up in hours of wasted time, along with wasted money. There were two shaders I wanted: xygthop3’s CRT shader and Dodozen’s bloom shader (though I ended up bying a pack with all his shaders). I wanted both of these shaders running at the same time, which is doable but still kinda tricky, at least for a newbie using someone else’s shaders. I did learn about how to run a shader in GameMaker: Studio beyond sticking in a shader object that someone else created. But in the end, I couldn’t use either shader.

The CRT shader does things in a very particular way and requires the use of views. My game used the entire room, which was set to the view, but this shader requires that the room be larger than the view even if you don’t plan on using the whole room. At this phase in development for my game, it was way too late (at least in terms of my patience) to go back, find all the times I referred to the room width, and replace that with the view width. I didn’t even know how I would be able to catch every time I did so, since GameMaker: Studio does not allow users to search the code or use search/replace (and I think this functionality should be added ASAP; I don’t know how a large project could be managed without it). You can work the shader with the view being the same as the room, but no one would notice its existence, so it may as well be left out.

I had a little more success with the bloom shader. However, there were still problems. I wanted this shader to make everything in the game glow, like an old computer screen. Unfortunately, the color I was using for grey was below the tolerance level to be changed, which resulted in some objects seeing an effect and others looking the same as before, which bothered me. The real kicker, though, was that the shader wasn’t working in HTML5, the target platform of my game. I don’t know enough about shaders to try and make it work, so I had to abandon it. Hours of work were down the drain.

When the dust from this drama settled, it became clear to me that this game is nearing the end. There is little more that I can add. This is due to technical limitations, waning interest in myself, a growing maturity in the game, and the fact that the Indies vs. Gamers jam and the GMC Jam are both in only a few weeks. I was going to participate in those jams, without question, so I wanted the game done prior so I would not have to worry about reengaging in the project. This kicked production into high gear, it seems.

I had to have a tutorial. I had written one out for playtesting, but this was not going to be the best solution in the end. In my mind’s eye, I foresaw a slide show with various game elements and animations with text on the bottom. This did not work in practice. Some parts had to be animated, and the only way to animate them was to record really long GIFs that, when I tried to import, GameMaker flatly refused on the grounds of too little memory. I suppose I can’t blame it; that would be a nightmare for HTML5 anyway. I did come up with a better solution. Instead of videos, I had the game enter the game room, but with a fixed seed so that the game would always play the same way if the user followed instructions exactly. This was accompanied by a text box with slides telling the user exactly what to do and why. It would be better, admittedly, if my game could force the user to take the desired actions, and not allow him to deviate. This could be a mess to add, though, so I found it better off to make the instructions as clear as possible and warn the player to follow them exactly.

With the completion of the tutorial, all that was left was adding music and sound. I already had a list of songs I wanted from incompetech, and I searched the Internet for good, public domain sound effects, along with making a couple of my own in BFXR. All told, music and sound was easy to add, while making a positive impact. There is no way to control the volume, but this is more a nuisance than a dealbreaker. The sound and music can still be muted if it’s too much. After a few more finishing touches, I declared the game finished (prematurely).

I tried to submit my game to the beta projects on the GMC forum, but the moderators moved it to alpha instead. This puzzled me; my game looked like it was at least beta stage to me, if not complete. After asking questions, I got feedback on the game itself from the forum moderator that, while discouraging, was the most helpful feedback I got so far. He said that there was no need for a 24 page tutorial and that if that much explanation was needed, the game was not intuitive enough. The UI should be made more intuitive so that the player knows, without explanantion, how to play, and he offered suggestions for how to do this. He also felt that the game, as a whole, felt stale, a criticism I am open to. There’s too much text, and most of the game feels repetetive. While the missile launch scene has some character, the other parts do not, and they constitute the majority of the game. Thus the game needs a lot more work in order to be complete.

Some of these suggestions would not be that difficult to add, but sadly, I don’t know how to give life to the bulk of the game (namely, the assignment of missions to the spies). He suggested animations (and so did my brother, when he playtested it), but I don’t know if I have the skill or the patience to add them in an effective way. It really feel like the game is stuck where it is.

So what should I do? At this point, I think the best thing for me to do is shelve the game. I think there are other projects that would make for better games and be more fruitful pursuits. Continuing with this game feels like a waste of my time. So I will not publish it. The game is done, and it’s time to move on to something else.

So what have I learned? My technical skills have grown the most, and I won’t bother describing them. I did learn about the design and implementation process as well, though.

One thing I would do differently is look at packages I hoped to implement right away. While this system of building up from some base slowly did work for the most part, it has its flaws. When you have a large and increasingly complex project, it becomes more and more difficult to add more due to its growing interconnectedness and complexity. This is especially true when you are using content created by someone else, such as content obtained through the YoYo Games Marketplace. One thing to do is try to futureproof your game as much as you can. However, I think that this can be difficult to do perfectly. Quoting Donald Rumsfeld (I’ll shower later), there are “known unknowns” and there are “unknown unknowns”. You can futureproof for things you know you may need to be more flexible in the future, but if there are things you didn’t even know you want to do differently or could do differently, this is difficult to prepare in advance for. So I would suggest that if you are planning to use content created by someone else, look at it as soon as possible and think about what it will take to add it as early as possible. Also, be sure to try that content out in any demos they have provided, tweak it as much as you can, so that you can learn how to make it work without making any changes to your existing infrastructure. Otherwise, you may find yourself making massive changes that end up not being used and only make your project even more complicated.

I also advocate keeping a dev log like this one. Not only was this developer diary good to keep me motivated (it imposed deadlines and helped me develop a habit I actually want, since it calls for some accountability and wanting to have something produced by the end of the week), it helped me reflect on the design process and where I was in it. It also helped me reinforce the lessons I had learned, and they are less likely to be forgotten. Maybe if you are lucky someone will actually comment on your dev diary and you can learn from them too.

A lesson that should come to no surprise to someone with much more experience than me is that interest will wane and things that seem quick end up taking longer than expected. I was planning on this project lasting for a month, but it ended up taking twice as long as I thought, even when I found myself working more than an hour a night. This should be planned for. And as for waning interest, you can either tough it out, or try to identify why your interest is waning and see what solution to take. Perhaps its just one little part that maybe you could do without or skip.

I am glad I was working on this project. Working on it every night was good for me. My girlfriend and I broke up a week into this project (not due to it, of course), and I felt (and still feel) very sad and disappointed. This game was somewhat theraputic. There were nights where I was feeling depressed and didn’t want to do anything, yet somehow I was able to sit down in front of the keyboard for even just a little bit and add something to my game. It would make me feel better to do this, like I was going somewhere, and distracted me from my sadness.

Will I keep making games? Yes. I will be participating in the GMC Jam, my first game jam ever, and I look forward to what I create during that. And I would like to expand into mobile games; I already have plans for one and that could be my next project (and I will write a developer diary for it as well), and I do want to make money from it.

Do I want games to be my career? Probably not. I am perfectly content to make 2D games with GameMaker: Studio on my own time, how I like, and hopefully get a few extra dollars every month that would help with expenses. I will likely have a day job that will be my main source of income not at all related to games. With that said, I have many project ideas that I hope to work on.

Thank you all for reading through these developer diaries. This has been a wonderful experience. Please stay tuned for future blog posts, which could be about anything (dev diaries, essays, LPs, you name it).