Tuesday, May 21, 2013

Two games failed? Make a third

Finally, I have something to show. A preview of a working, functional game. After two failed, unfinished prototypes, I started a new project and this time it looks like it might actually work.

Things I learned.

When making a game, it's natural to start with gameplay - except it completely doesn't work for me, because I tend to lose interest as soon as I have something playable. However, there's a very long road from playable to feature complete, and then even longer to polished.

A gameplay prototype? At best 50% of a game, and that's for a small, free game (the bigger the game, the more polishing it requires). Building interfaces and bug fixing is what kills any entertainment in game making for me. And that's why I never finish anything. Or maybe I'm just lazy and dummmm.

Anyway, this time around, I started with title screens, menus, options, level selectors, preloaders, saves, mute buttons... And honestly - I don't see myself ever getting excited about that kind of stuff. But there was a difference: I knew that once I'm done with that, I had a moderately exciting phase of actual game design waiting for me.

One thing I know I should have done, was to write down a proper code/class design. My programming skills are far too horrible for any kind of "agile development", and yet I continue to make the mistake of carelessly creating illogical code structures, thinking only about the issue directly in front of me. Truth is, I really am lazy and dummmm, so no surprise there.

Here are some prototype screenshots:

The graphics are extremely basic, but I actually like them that way, and it's not like anyone is ever going to play this game except for me and my girlfriend, hue hue.

Gameplay

So, in this (yet-unnamed, although I have a working title - see screenshot above) puzzle/logic game, you click on a square, which spreads its color in four directions. Fill the entire board with a single color of your choice, and you win. Simple? I hope so. Are the puzzles themselves simple? Well...  According to me some of them should be quite, uh, intricate, especially if you want to get the "gold medal" solution, but I'm just a puny Earthling with little imagination, so I wouldn't be surprised if someone found them childish.

To spice things up, you have a limited amount of moves, and - as I should probably mention in the beginning - the spreading of colors doesn't go all the way to the border, but stops on squares (tiles?) that are colored the same, which creates interesting dilemmas, such as: "I want to fill the board with blue, but this particular row would require several clicks of blue squares, but if I first color it red, then I can recolor it back to blue with a single click" etc. Well, that sentence hopefully makes sense at least to someone who played the game.

I start with some tutorial-ish levels, and I also have a few instruction screens, like:

There are also some variations, such as squares that can only be colored from a single direction, or squares that resist coloring a couple of times. All in all, I think I managed to keep it simple enough, but challenging (yeah for sure).

Code

This project has once again demonstrated that I'm a bad programmer. At first, the code looked passable, maybe not very universal, but I didn't intend it to be universal. I was surprisingly satisfied with its structure... until it occurred to me, that I came up with a "great" idea for a new type of square that simply must be in the game.

That was the "coloring-resistant" square. I didn't plan to include it at first, and my code was definitely not ready for it. It broke EVERYTHING - the basic "spread" function had to be patched four times before I was eventually forced to remake it. And since the "spread" function changed, the "unspread" function had to be fixed as well (I curse the day I thought implementing the Undo feature was a good idea). And then the functions and classes that govern the behaviors of special squares turned out to be bugged, so I had to rework them a bit. And by "a bit" I mean enough that I had to change their interfaces... Which were used in the "spread" and "unspread" functions, so I had to rewrite them again.

Loop this about five times and you'll have a picture.

And it's still a bit bugged.

"A bit".

There is a very, very rare bug with the Undo feature that I'm aware of, but unwilling to fix. What I HOPE will happen, is that maybe 1 in a 100 players will face this bug once in the entire game, but probably won't even notice anything (it's not game-breaking). What my objective pessimism tells me WILL happen, is that everyone will bump into this bug early in the game, decide that the entire thing is bollocks and quit.

But I just can't... force... myself... to even think about that code again.

Lesson learned? No. 1) Save great ideas for sequels.
No. 2) DESIGN YOUR CLASSES PROPERLY GODDAMMIT.

Level design

The third lesson learned would be: don't overextend.


My goal is to create 32 levels. And not only that, I also want to make sure, that there is a "great", gold-medal solution, as well as an "OK" solution for every puzzle. This means, that my puzzles need to have multiple paths to victory, and sometimes it really feels like designing two, or even three levels inside of one. Aside from giving me a headache, it will probably also make me look stupid, because I'm sure I'll miss some obvious, three-click solution to a complex puzzle that was intended to be solved in 15 clicks at minimum.

Also, I didn't make a level editor. I mean, am I stupid or am I stupid or what? Somehow, I convinced myself that designing puzzles directly in an XML file couldn't be too bad. They look like this:
    <level nr="9" max="7" great="5">
        <row nr="0">41314341</row>
        <row nr="1">00500000</row>
        <row nr="2">12314141</row>
        <row nr="3">00300000</row>
        <row nr="4">23231322</row>
        <mod row="0" col="2">SPREAD_VERTICAL</mod>
        <mod row="2" col="2">SPREAD_HORIZONTAL</mod>
    </level>
It's an early level, and I already don't want to look at it. And I can't even test the changes easily, I have to actually restart the entire game to re-load the level data, which is a major pain in the ass. Things would be so much smoother with an in-game editor, and as a bonus point, I would have an editor to give to the players! But nope, MS Notepad all the way.

It's ALI... well, not dead.

The best thing about this project, despite its numerous flaws, is that this time around, I am pretty sure I'm going to finish it. This could be my first complete game, not just a prototype, but a fully functional and maybe even entertaining title.

I'm not sure about the way I'm going to handle distribution. I know that sponsorship is the primary source of revenue for Flash games, so I left some space for branding in the layout. It's not actually an ActionScript game, but a Haxe game, which means it theoretically compiles to native mobile apps (and I made it flexible enough to work in any resolution, as long as it stays in landscape orientation), but I don't possess a smartphone for testing, so while I would love to try to make a mobile conversion, I will most likely not be able to.

In the end, I might even skip the sponsorship for this one, integrate some MochiAds, Kongregate API or whatever and just release it into the wild. I don't even have a code obfuscator nor enough cash to buy one (400$? really?), so even that may not be possible.

Anyway, it took me 6 days to get to this stage, and I plan to spend about 6 more days working on levels and general polish. I won't be too terribly sad if I don't make a single buck on this.

Eh, more MS Notepad...