• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Dan's missives on jamming, game development, coding and QA.

Entries in this blog

Another week of development has come and gone with a bit less overt productivity but a much more game-like product. So far the game is coming together decently and has a "has potential" feel in my opinion. I've not spent much time on getting the pacing right and, without music, the game is lacking in atmosphere. However shooting feels good and I feel that the scoring mechanic gives just enough impetus for the player to be aggressive to keep the pace up.

What we did last week

Day 1 was finishing up what was started at the end of last week. When the player is hit the screen shakes and fades out. If the player is out of lives the game ends, if not the player respawns after a brief delay. Also set up a proper model for the player's gun.


Day 2 was unable to work due to personal commitments

Day 3 created models for different shots and a model for the player character.

Day 4 added scoring mechanics and got the status bar working completely.


Day 5 rigged the player character and got some really minimal inverse kinematics going. Looks janky but it's a start.  


Day 6 not visibly productive. Animated the player character then ran into tons of issues with importing the animations causing, among other issues, the player model to embed itself in the floor.

Day 7 resolved the import issues by moving the player model in Blender so its median is at the origin. This stopped the model from jumping around so I could place it accurately. I suspect it's due to parenting issues which are discussed in the final paragraphs of this article

In Ontario the Toronto indie scene gets most of the attention with megahits like Cuphead. Though most of the attention is on the biggest city in the country smaller communities also have burgeoning development scenes of their own. If you're in the Kitchener/Waterloo & Cambridge area there's a month long game jam, called MoLoGa jam, going on for the duration of February. Anybody that's interested can participate.

Since the jam is more sedately paced I'm going to try to post weekly updates about what me and my friend are doing as a project.

What is the project?

For MoLoGa we're building a manic arena shooter in the vein of Serious Sam. The twist is that instead of dealing with hordes of enemies mixing ranged, melee and kamikaze attackers for challenge this game will pit the player against enemies that spew tons of bullets. The intention is to have the challenge be based on navigation and positioning so that you kill enemies in a way that gives the highest score.

In short, it's meant to combine scoring and movement mechanics common to bullet hell shooters with first person gunplay.

Some design details

The biggest potential pitfall in the game concept that we anticipated is the player being unfairly shot from behind. In order to mitigate this the game is going to have a few assists. The biggest one is the creation of the jumbotron. The jumbotron is a big screen showing a birds eye view of a large portion of the map. It's meant to provide a way for the player to quickly check the entire area around them without having to spin around.

The jumbotron is also a deciding factor in the visual theme of the game. Since I wanted the presence of huge TVs in highly visible locations to actually make sense I decided the game will take place in a literal arena. While I'm not going to include any explicit narrative the game will hopefully evoke some kind of fantastic sport or TV show.

The game will also have a few other assists to make it feel fairer. They are going to be more subtle. Bullets that are approaching from behind in a way that could hit the player will have an aura showing vaguely where they are. Nearby bullets will produce a noise.

What did we do last week?

MoLoGa jam kicked off with a brief presentation at the UW Games Institute (formerly known as RIM 1 for some of us :p) last Tuesday. Day 1 was dedicated entirely to hammering out the game concept and what needed to be done by each of us.

Day 2 I built a model for the arena the game takes place in. Not much to look at but it does the job. In order to save time I didn't model the full arena. Instead I made a model of the northwest corner then duplicated it in Unity to create the full arena.

Day 3 was dedicated to setting up some of the game's infrastructure and getting basic movement working.jumbo1.gif.5b57af599ef8ef9014406bf2cebd4fc4.gif

Day 4 basic shooting controls. In theory the player has both a primary and secondary fire but only the main weapon is functional since I haven't decided whether the secondary fire will be a big laser or a rocket launcher.

Day 5 enemy spawning and killing. With this the game finally resembles a gameenemy2.gif.dd88dd6dfbe5532de0808e3fea1c7c3d.gif

Day 6 I got together with my teammate and we put some work into getting the music he'd been working on sounding good. I gave enemies the ability to shoot their own bullets.


Day 7 set up some in game UI bits and got player death detection working. This was not a productive day unfortunately.

Stay tuned... next devlog will be coming, hopefully, next Tuesday/Wednesday

The Toronto Game Jam is opening for registration later this year. I'm hoping to participate again since it's been a great experience every time. As of last year myself and a friend have participated in the Toronto Game Jam three times. The event, also known as TOJam, has developers come together at George Brown College for three days of manic development of crazy game ideas.

Participating in a jam can be overwhelming but also rewarding and fun as hell. Over the last few events I've had things go right and things go wrong. Here are some tips to help avoid some of the worse pitfalls that you can hit during a jam.

Tip 1: Know what you're going to make in advance

At TOJam you have from Friday at 10:00AM until Sunday at 6:00PM to create your game. While you don't need things to be set in stone you should know that you're making a puzzle game and if will be based on sliding tiles or stacking blocks. If you don't know what you want to make then you'll be using up your time figuring out what to do instead of doing it.

The week before the game jam we take our one or two paragraph "elevator pitch" and write a simple list of what needs to exist to fulfill that pitch. We then refine that list into a detailed set of tasks we want to complete on each day of the jam. With the list we can grab work as it's ready and keep dead time minimal.

Tip 2: Know what features you can drop

Murphy's law always strikes. Something goes wrong and suddenly the deadline is looming. When figuring out what to do for the game you should have some idea of what features you can drop without ruining it. Generally this list will be very short but it's always handy to have if you fall behind schedule.

Making a list of optional features is also a good gut-check on whether you've got a realistic schedule. If the list is long then your project is probably too large. A schedule that feels like it has too little work on each day is better than one with too much. You can always add work and scope to a project while you're working on it. It's much harder to cut scope down when you're running out of time.

Tip 3: Balance your workload between team members

If you're jamming solo you don't have to worry about this. If not it's critical that everyone has something to do. One trick is to have broad but shallow task trees. If C depends on B which depends on A then they can only be done by one person. Sure you could work on A then your partner can work on B but you can't work on C while your partner works on B. A way of fixing this is adjusting your design so B and C depend on A but not on each other. From a coding perspective using interfaces and loose coupling helps a lot.

In our latest jam, TOJam 12, we had a number of lethal hazards which could be activated by a button. In the bad case character death would depend on development of some arbitrary hazard which would depend on implementing the button to activate it. To avoid this we set up the button with two observable events, OnPressed and OnReleased and gave the player character a "Killed" method. By having a simple interface everything that was activated by the button could be developed independently. By having the "Killed" method player death could be written independently from any specific way of killing the player.

Another trick is to group your tasks into distinct streams. During the start of TOJam 12 I developed the base skeleton of the game while my team mate whiteboxed levels. The only dependency here was that I needed at least one level to load to start the game which was done well before I needed it. Later on I worked on handling player death while my teammate composed the title theme song for the game. 

Tip 4: Have a library of game creation tools in advance

When jamming it's important to always be working on the game you want to make. The last thing you should be doing during a game jam is building a tile map editor. In TOJam 11 we lost about four hours to writing input handling code for a twin stick shooter. That took away time from more important tasks like generating bullet patterns, spawning enemies and so on.

Tip 5: Minimize the number of variables the game's design

I'm not a professional game designer so I'm not sure if "variable" is the right word. What I refer to is a thing that can be changed to alter the feel and balance of a game. The speed of a character, enemy hit points, number of enemies, how often they shoot, how often you shoot and so on. All of these variables add complexity to the process of making a game "feel" the way it should. Having lots of low hitpoint enemies could make you feel powerful. Having a few high hitpoint enemies would feel quite different. Having lots of high hitpoint enemies could make the game feel dangerous, scary or simply unfair. In all these cases I'm only changing two variables, the number of enemies and their hitpoints.

At TOJam 11 we produced a twin stick shooter called MANT: The Man Ant. The twist is that the bullet patterns would be generated procedurally. This also was the biggest headache. Pattern generation worked but it was extremely unbalanced. Sometimes patterns would be pathetically easy. Sometimes the game would produce enormous unavoidable walls of gigantic bullets. We burned up at least half a day trying to get a consistent and fun difficulty curve but still had huge differences between sessions. The game was a "finished" working product but it wasn't very fun.

Our next project was a puzzle platformer built around using dead bodies left behind when your character dies to reach different goals. Variables are generally level specific and mostly independent. Things like how quickly a door should close or how often a gun should fire. Tweaking still took around half a day but we stopped tweaking because we were done rather than being out of time.

ToJam Specific Extra

If you're driving from another city don't forget to take traffic into account. The 401 and Gardiner Expressway are infamous for a reason.

Related Links

Toronto Game Jam website
Our TOJam 11 project (not a great game in my opinion)
Our TOJam 12 project (you can find more details on how the jam went in the development log)

Sign in to follow this  
  • Advertisement