I promised myself I would do a post mortem on the BaconGameJam 6 just like I did for my BaconGameJam 5 submission. So here we go, warning, it's quite a long read.

Pre-Jam

About two hours before the jam started I met my artist (cryphire / Rob) in the IRC chat of BaconGameJam. It was after I talked with some other people in the chat about our previous submissions, I talked about how my previous submission (Shadow Infiltration) contained nothing but primitives except for one rounded wall, Rob then said he was an artist who mainly does 3D stuff, I then said that perhaps we could work together, and that's what we ended up doing.

Rainbows

Rainbows. I can't say I was happy or thrilled about this theme at all. I was expecting every game to be robot unicorn attack or whatever, and I certainly did not feel like re-creating a game. I personally prefer creating games that have an end to it, an adventure/puzzle of sorts, not a game where you rack up as many points before dying.

Me and the artist quickly agreed to not create a game where you do that, but instead create a game with a beginning and an ending.

Scope

We now needed a game idea. We didn't have an easy time coming up with one as the theme wasn't really fit for this.. That's when the growth of the scope began. A zelda-esque game, yeah, that would be awesome, with items you can pick up, an experience system, an upgradeshop/window á la Bastion. We imagined a central hub where the  shop would be (just like in Bastion) and the player had to go through levels of different colors to collect fragments of color to then create some sort of key for the final castle with the end boss. Yeah, in a 48 hour jam, why not.

Start of development

Around 1 and a half hour after the jam had started, it was time for development to start. I started on some basic movement and input code and quickly got a cube moving around a flat field, I then quickly added controller support, because why not. I then continued coding by making the cube look in the direction of the mouse and I then started on creating a simple main menu.

This movement simply worked by taking a physics object (rigidbody cube) and adding a (sideways) force to it until it was at the desired velocity.

UI
GUIs that are responsive add a great deal to a game's experience, at least, that's how I feel. A simple scaling effect, sound effect and change of color when hovering over an option makes all the difference.

Here was the current version, we rolled with the name RainBowser at this point, because why not. Notice how the buttons all have a different color they change into on hover and how they all have a different pitch of sound. In my opinion this makes all the difference, and I feel quality UI stuff is something that you see a lot in jam games, which is a shame.

Sound

What I just said about UI also goes for sound, we figured we could get sound effects for free at sites like opengameart, but what fun would that be? Instead we recorded every single sound in the game (except for the music) by making the sound ourselves. The final product of the game now reminds me a lot of this video[http://www.youtube.com/watch?v=jwxN8sCIOOE].

We felt it added a bit of personality to the game, and we (probably just me actually) could not stop hovering over the different bodies to hear the silly sounds they make.

The rest of the night

Later that night I implemented simple following AI (using Unity's NavMesh Agents, which is in the free version since version 4.2) and I created the health/mana UI, and after that, I went to sleep (around 8AM). The reason I stopped was not so much because I was tired, but because my eyes were burning.

The next day

I woke up quite a bit later than what I had planned, I woke up around 4PM, but ah well, at least I was well rested. I quickly started working on more must-have features like attacking and taking damage. All this time, I had not received any art from my artist yet, despite asking many times for at least a screenshot of what he was working on so I could have an idea of what I would have to work with. And around an hour later, he came online (US timezone, where I am EU) and soon had a level I could throw into Unity. That's when I faced a big problem.

Big decision in movement

The simple movement code, that featured an actual physics body which sideways features were applied to, was totally unfit for the level. The level was not flat. If you have a cube, that wants to has to go up a small ledge and you only apply a sideways force, the cube will overcome this ledge by tipping over onto the higher surface, the cube however, is an avatar for the player and you usually don't want your player characters to rotate on the X or Z axis, but only on the Y axis (turning around horizontally), so the X and Z rotational axis were locked.

This resulted in the cube unable to cross the smallest of ledges. There were also other problems, such as the cube slowly sliding down the uneven terrain and more easily moving downhill than uphill.

I faced a big decision, did I want to limit the game to flat surfaces only, and by doing that limit the artist and possible game elements, or would I  rewrite the movement code?

I decided to do the latter, I rewrote movement code to work with a CharacterController[http://docs.unity3d.com/Documentation/ScriptReference/CharacterController.html].

Gameplay Elements

It was time to work on actual gameplay elements, as I was implementing the rotating arms, I had an epiphany. Instead of writing code like this for everything that needed some basic manipulations done (moving, rotating, scaling, color changing), I could use a system I had been using for the UI instead. UITweens is what they are called, they allow for easy basic manipulation of GameObjects in unity from code.

I would simply add a UITween to an object (in this case rotate to X degrees), and call it whenever an attack is made, and when it is done, I would have it play in reverse.

I could use this for many more elements, such as doors that would slide open in a smooth fasion. Here's an example build where I experimented a bit with this [https://dl.dropboxusercontent.com/u/43693599/BGJ6/8/Build.html].

Unscoping

Me and the artist discussed what we had done (which was quite a bit), and what had to be done. The artist told me what we had was already a lot, I felt the exact opposite. There was a lot to be done, we decided on (at least for the near future) skip on items that one could pick up and an exp system, and instead work with a few unlockable powers.

We also decided we would use the existing characters (cubes and the like) as we grew fond of them and felt they would have more character than any more realistic models.

I then took a break from development to eat and relax a bit (for about one  and a half hours).


I proceeded to create the spells UI (All the UI art was by the way done in  Inkscape by me, if you are a programmer who sucks at art (like me) this blog[http://2dgameartforprogrammers.blogspot.com/] will probably be of big help.). After that I implemented the first real spell, the blue projectile balls one could fire, the first implementation had some serious mistakes in it and resulted in an entertaining glitched build which you can find here[https://dl.dropboxusercontent.com/u/43693599/BGJ6/9/Build.html] (To glitch press 5 and left mouse button and move around with WASD).

I then implemented ranged attacking enemies and the other spells. I then found myself starved of new content to work with from the artist (levels/level parts) so I started polishing the spells up (light effects, scaling shield etc.) and the enemies when they take damage (scaled down using UITweens).  After this, it was time for me to go to sleep.

The next day

The next day I implemented some more basic stuff, such as checkpoints and spell unlocks. After that, around (Sunday) 4:30PM I (finally) received  more levels (the model for them). But the problem was, that I still had to give them actual functionality, something which took me longer than implementing the functionality behind them in code. I started adding rollable objects, trigger plates, gates, bridges, spawners and all the good stuff to the world and then exported a build that was almost done all the way through to the end of what the artist supplied.
Disaster

But then, disaster struck. After making this build the Unity Editor crashed. It had been a while since I saved (as it's counter-intuitive in the scene editor in Unity) I lost a lot of work. At this point, I felt like giving up.

This is where I had two options I discussed with the artist, either we could hand in the last build, which was full of bugs/faults (dying would mess up the unlocked spells, pushing a block off the level would make the game impossible to finish), or I could re-do most of my work of the past hours to get to a point where we originally work.

We decided to do the last, and to get rid of the blue level (unless we magically found time for it), and to add one final boss battle/arena at the end. Around 8:30PM, two and a half hours before the deadline, I was done redoing it all and the rest that we had, but some stuff still had to be fixed (such as dying messing up spells), so I decided to work on that instead.

Feeling bad

For the ending there was no time for something awesome such as a final battle where you had to make use of all your obtained spells, despite the artist having made a nice arena. I felt bad for not having saved in time, and as a result not having used a lot of the assets the artist provided for the game. I decided to quickly throw in a crown at the end, which rests on top of a scaled down version of the final rainbow arena :(.

I then submitted the game.

Post-submission

After the submission, someone decided to stream playing some of the jam games, including ours. This was great to watch, as it was the first real playtest. It quickly showed problems with the game, for instance, he could not figure out he would have to shoot some buttons in order to activate them, and it was painful yet humorous to see him attempt a leap of faith with the cube for it.
i took the packaging time to fix the most important bug in the game too, the final bridge leading up to what was to be the castle, was placed too low so the main character would get stuck, just before the end of the game.

I also extended one platform so the leap of faith would actually be a viable strategy.

What would I change

I would change quite a bit of things about the game, the first is the lack of effects for the violet spell. This spell pushes nearby enemies/rigibodies away and is easily the most awesome in the spell (Fus Ro Dah!), but it has no visual effects, so when people first try it they think it is broken if there is no enemy nearby.

The second change would be a reduction in push puzzles, there's quite a bit of pushing of blocks and the implementation of pushing things is not perfect at all (one of the side effects of using the CharacterController instead of a rigidbody).

The third change would be more content,a proper ending, more difficult fighting situations. I simply didn't have time for this in the end.



Thank you

Thanks for reading this all, I could write another 10 pages on choices that I made and why, and then another 10 for the actual implementation.  By the way, the code is all available here on Github [https://github.com/Rahazan/gamejam/tree/master/BGJ6/Assets/Scripts] . I feel it's quite   structured and readible, despite having been written in a gamejam, so if you are looking into jamming with Unity feel free to have a look at it.

I hope you enjoy the game, despite it's current state, you can find it here[http://bacongamejam.org/jams/bacongamejam-06/167/] by the way.