Sunday, August 17, 2014

Postmortem - Defeat The Boss #IndieQuilt

Made a game called "Defeat The Boss" for the IndieQuilt game jam during most of my July's free time.

You can check out the game here:
Defeat The Boss @ GameJolt

One of the goal of the jam was to make a game completable within 30 seconds per difficulty, and having just finished A Link Between World, and very impressed by its boss design ( and also Ocarina of Time's bosses, but I haven't finish that game yet ), I decided to make my own boss design centered game, like Dark Souls and Shadow of the Colossus.

What Went Right
30 Seconds Rule Rules~!!!
Lovin' the fact that the game have a "need to be accomplished within 30 seconds" rule. I think somewhere within the rules, they stated that they wanted to do something like WarioWare, 10 seconds a game.

I always have this sort of design problem where I tend to go too far when developing a game. I'm not very good at limiting and simplifying my designs. I kept thinking that this sorta thing needs lots of practices in game making to get it right. Yet, after countless hours of game making throughout my gamedev life, I still couldn't master it.

Developing this game gave me the idea that I can start with just limiting the gameplay time.

Simple Controls
Asides from limiting the gameplay time, I also limit the controls and character's capabilities.
The character can only move ( WASD ) and dash ( space ). There's no button for slashing, you just stab that sword of yours towards that beast's weakness and he's dead.

Nice Tracks and Collaboration
It's been a looong time since I last collaborated with someone on a game, not since this year's Global Game Jam. It's especially cool when the composer I collaborated with got me some really cool tracks that fits the game, within a short time ( a week if I'm not mistaken ), as I was very eager to get the game out already.

Simple Graphics
As I'm going through with the limiting game, I also limit the game's graphics by a ton. There's originally gonna be a beautiful medieval stage, with much more boss design, but I scrapped them. I mean, it's a prototype, it's the game feels that counts.

That's another lesson learned, don't spend too much time on graphics for prototype.

Develop and Release Within A Month
Since the start of the development, I've planned to work on the game for 1 month top, which is the reason why I was so eager to get the game out quickly. I don't wanna work on any prototype for more than a month. My past experience told me my patience will run out as soon as a prototype project passes a month of development time.

Achieve the Achievements
Prior to this project I've had a lot of experience in handling achievement system ( not in my own games tho ), so I was able to get it done within a short time, and linking it with the GameJolt's API.

Stylised, Hand-Drawn Font
This time around, I go with a random font I simply drew on Photoshop, as opposed to spending long hours looking for the perfect font on the internet ( another bad habits I always have ). Thus, cutting the dev-time cost by a ton.

What Went Wrong
Overuse of Coroutines
In order to develop the AI within a short time, I used a lot of coroutines to handle stuff quickly, such as making the boss jump, change the height of the mesh and shadow projector, make the boss wait before carrying out the next move, etc. I wanna avoid using too many non-coroutine state machines, as I'm afraid that I won't be able to handle them. That decision also resulted in lots of nested coroutines, so many that even StopAllCoroutines couldn't stop them all. In the end, I have to add a check-then-yield-break mechanic that breaks the coroutine whenever there's a need to.

The code wasn't pretty as a result, it was a big mess, and I barely fix all the coroutine bugs, but nevertheless, it's a lesson well learned. Not gonna use coroutines to do my state machines next time.

Array-Grid System
I'm not quite fond of Unity's CharacterController and their collider physics, and I don't have time to write my own collider system, so I wrote something like a 2 dimensional integer array with information that the code can access to detect whether certain areas are approachable or not. There's really no problem for this part except I found out that I don't really need such system, and I spent a long time to tweak it.

And then...
Most of the lessons to be learned here are:
- Limit more on game design
- Don't use too much coroutines, especially the nested ones, unless if you can control them or you write your own

Making a turn based game prototype up next, had plenty of ideas for it as always. Will try to limit the design again for this project.

No comments: