I entered a 48 hour solo game making competition this weekend called Ludum Dare. It was heaps of fun! This game is the result – it’s called “Gum Crisis in Pipe City”.

Play Gum Crisis in Pipe City!

Hope you enjoy!

Hey there! Like usual I haven’t updated this blog for ages, so I thought I’d do a post on the prototype I’m working on at the moment.

BUREAU is kind of similar to Civ, but with an tight focus on individual characters. You’re the leader of an secret society of magi in medieval France, and your task is to grow the Order as you see fit, while keeping out of the crosshairs of the Church, whose Knight Templars are completely immune to magic.

I’ve got several ideas for which direction to take it actually, and that describes one of them… I’m trying to focus on core gameplay and prototyping first, and then grow the game from there.

The gameplay will be management focused, as you train up apprentices into fully fledged magi, assign tasks to your magi (like enchantment, research or information gathering), and react to events like dragon attacks, rogue magi or plagues.

Visually it’ll be pretty abstracted, the idea being that the game gives you just enough information for your imagination to fill in the blanks. It won’t be completely text-based, but will probably be pretty text heavy. This is partly because I feel like that’s an interesting avenue for development, and partly to avoid having to make heaps of art.

I’m making it in OpenTK using C#, which means that I should theoretically be able to build it to PC, Mac and Linux, although so far I’ve only got a working PC build.

Where I’m at at the moment:

I’ve got the map working, and you can command the magi to go to different locations, and then hit the End Turn button (that weird square in the bottom right corner) to make them go there. Next up I think I’ve got to get some kind of “information card” working so that you can click on a magus and get their information. I also realised today that I haven’t actually planned out the system of magic, so I spent a bit of time on that, but will probably need to spend some more.

I’m working on this in my spare time, so no idea how long until I’ve got a playable build somewhere… it’s a project I started as a pure hobby/fun thing, but I am starting to get the feeling that I miiight actually be able to get it to the point that it’ll be playable.

It is pretty experimental, and there are a definitely a few obstacles that I’m going to hit – I still don’t really know what you’re going to be spending most of your time actually doing in the game, or what the flow is going to be like. It’s been fun so far though!

Download and play Faia

The Global Game Jam took place last weekend, an annual event where thousands of crazy people get together and attempt to create games within the space of 48 hours. This year I was one of those crazy people, and I dragged along three game dev friends to share in the madness.

To tell this story right I first need to introduce the rest of my team: Russell Dilley, another design-minded programmer, Alex Andreadis, our primary 3D artist, and Ban Ngo, another artist (and impromptu sound designer).

The team hard at work! From left: Ban, Alex, myself & Russell. Photograph by Elroy El

Okay!

After being innervated by the keynotes and hearing the Jam’s theme (Ouroboros, the symbol depicting a serpent eating its own tail), my team sped back to our computers and discussed what to do. We decided as per Harry Lee’s suggestion to separate for a few minutes and brainstorm, then to come together to discuss our ideas and see where we went from there.

Ouroborization

My personal brainstorming process was going through the wiki article on Ouroboros and writing down the main themes as I saw them:

• The cycle of life and death
• Eternity
• Self-sufficiency
• Circularity
• The phoenix
• A “made by god” perfection

Twenty years of writing left-handed and I still manage to smudge the ink.

I also had a few rough gameplay thoughts, but nothing cohesive. We reformed soon after, and went around the group, each person quickly describing an idea and then the team tossing the idea around, combining it with other ideas or throwing it on the scrapheap.

Hastily scribbled notes from the brainstorming process.

While several interesting ideas were mentioned (a population management sim, a four player side-scroller with dynamic terrain, an action game on top of a 3d orb where the world moves instead of you), we gravitated towards this idea of a survival game where you’re a phoenix flying around an infinitely repeating world, burning it to cause regrowth to occur.

Just in case we forgot.

We worked on this concept for about an hour over dinner, adding to it, cutting unnecessary fluff and trying to break down the development tasks as clearly as possible. There was a final moment of hesitation as we hovered on the brink of development – the fear that the idea wasn’t going to work and we would have to go back to the drawing board weighed heavily on each of our minds. However, we finally decided to just go ahead and build a prototype, fooling ourselves into believing that if it didn’t work out we’d have plenty of time to try something else.

We divided the tasks generally as such:

• Russell would focus on the core gameplay, the player character and its movement. This would come to include the camera and game states.
• Alex would create the models, animate them, and create the effects.
• Ban would assist Alex where needed, while focusing on texturing and 2D work such as the HUD. Ban also took on audio during development, collecting and re-sampling a few key sound effects.
• I would set up the tiling system, the regrowing world and implement the majority of the assets that were being created by the artists.

The actual development of the game is kind of a blur already, so I’ll pick out a few moments that stand out in my memory:

Unity

While it initially seemed like a clever idea, using an engine for the first time during a Jam (in this case Unity) caused us a lot of unnecessary headaches. Unity seems like a great tool, but figuring out how to perform simple tasks and understanding its idiosyncrasies took up a lot of the time that we could have spent building the game. One key example of this was getting stuck for about an hour on loading an object dynamically through a script, until I found out that what I needed to do beforehand was create a “Resources” folder and put the file within that, after which the object would load fine.

The Tiling System

Getting the tile system working and tiling infinitely was exciting, particularly in that we could see up in the Scene view exactly how everything was working – as the player moves around, the tiles from one side of the square are instantly move over to the opposite side. We almost wanted to show the game off with the Scene and Game view side by side.

Note the trail of sound objects left in the wake of your destruction... (they reset eventually, I promise!)

One particular point of contention on the Saturday was whether to leave the tiles as simple squares, or build in to the tiling system a connection manager that made sure all of the tiles connected in a more pleasing manner. I was initially against putting this in, due to worries about how much time it would take, but was gradually convinced by Alex and Ban that it would be worth it. It took up several nail-biting hours, but the feature made it in, and in the end I had to agree that the game looked way better for it.

This is me figuring out what tiles the system would need. We eventually discovered a four-corner technique that minimised the number of unique tiles required.

Before and after!

The Ground

Seeing the tile texture go in for the first time was pretty amazing. I think the game ended up looking fantastic, and a lot of that is to do with the style of the tile textures, which Ban told me is partly inspired by Pokemon and partly by Animal Crossing.

The tilesheet file for the grass that is used in game.

Animations & Effects

Many of the animations were put in as a last minute feature, so they had to be made very simply. During this process however, we figured out (or luckily discovered) ways to make them incredible effective at the same time. See below; when the grass is burnt it simply moves below the tile that it’s on, but from the surface, due to the layering of the fiery particle effects it actually looks like they’re being singed to nothingness from the bottom up.

One tile of grass, medium rare.

Rebirth

My favourite part of the game is when the camera zooms in to/out from the tiny phoenix egg. It gives the game such a sense of scale, and the cyclic nature of returning to that state after every death really makes the theme resonate for me. I didn’t even realise that Russell was putting this feature in at the time, and it’s probably the part of our game that I’m the most proud of.

Pheoeoenix

Never, ever make a game in 48 hours with a Phoenix in it. About halfway through the jam we discovered that we were spelling it wrong half the time, and even though I frantically rushed through our source files renaming everything, we still got caught up multiple times by trying to load a “PheonixScript” or trying to play a “PheonixSquawk”. Guh!

End Game

While the last couple of hours were stressful, we’d pushed the game to a point where it was playable, pretty, and potentially even fun. Notwithstanding a couple of minor bugs (such as the idle music being quieter each time the phoenix returns to the egg) or the fact that the average game takes about 3 minutes to play instead of the ideal 30 seconds, we were all pretty happy with the game, and even more so when people came around and seemed to be having a blast playing it.

 Final Thoughts

We’re a mostly professional team, with three of the four of us having quite a bit of industry experience, and we were floored by the quality of the games produced during the jam by teams that as far as I know have little to none. I feel that the Melbourne independent scene is filled to the brim with creative, talented developers, and I can’t wait to see what they’re able to make in longer periods of time.

Even though this is a massive post, I feel like there’s heaps more stuff I’m missing out on. It was an awesome weekend filled with awesome people making awesome things, and I can’t wait for next year!

You can download Faia from the Global Game Jam site to play on your home PC, or you can come along to the IGDA’s exhibition night and play it while making awkward conversation with us. (Bonus!)

—

Play BBQ Attack!

A couple of weekends ago, I participated in the Game/Play Jam at Melbourne’s NGV Studio, where local game developers were tasked with creating a game from a collection of drawings that had been made a day earlier, by participants who had visited the space.

It was inspired by Adam Saltsman’s Idea Bucket event, although luckily for us the collating and scanning process was undertaken by the Jam’s organizer, that indomitable champion of gaming Paul Callaghan.

It was an interesting day, and the first Jam of any kind that either I or my co-conspirator Russell Dilley had taken part in. While initially I was somewhat apprehensive due to my disbelief that anything could be made within such a short amount of time, I now feel it was a great experience, and one that I’d recommend to anyone interested in holistic game development.

Here’s a breakdown of the day from my perspective:

10:00 AM

Russell and I arrived, set up our laptops, and started working. We’d done a bit of preparation the previous day – creating a subversion repository for the project and making sure we could do some simple things in Flixel/AS3, such as rendering a sprite and loading+reading an XML file – but other than that, we were starting from scratch. While we chatted about what ideas we should pursue with the game, I began to convert the art to usable formats/sizes using the IrfanView batch utility, while Russell started working on the game states.

11:00 AM

After an hour we had the drawings rendering on the screen at the correct scale. When looking into scaling images in Flixel, we found that doing a dynamic scale (versus pre-scaling the image) was up to 10x slower. Even though we knew our game would probably not be an intensive program, we still decided to make sure everything was pre-scaled to the size we wanted.

We had decided to go with the idea of putting the characters in a bubble, and then having spiky things come at them from the side of the screen. Russell suggested we make it two player, and that a good way to use as many of the hand-drawn images as possible would be to allow the players to select their characters. This sounded good to me, so he began work on the character select screen state while I followed this tutorial and made a quick bubble in Inkscape.

12:00 PM

At this point Russell had added the intro screen and was partway into character select, while I had split the database into “hero” drawings and “enemy” drawings. As mid-day passed us by, we started to worry that we hadn’t started on the gameplay functionality yet, so that became my next focus.

1:00 PM

Nearing the halfway point, Russell had finished the first pass of character select and was moving on to the end-game states, while I got the player’s selected character and the bubble loading into the “play” state. During this time, I noticed that I’d incorrectly batched the images and they all had transparency issues, so I quickly went back, fixed the issue in the batch process and re-exported.

2:00 PM

After having ironed out the transparency issue, I grabbed Russell’s input code from the character select screen and got the player characters moving around in the play state. My next task was to get the bubble-like physics working and smoother character movement, while Russell implemented the second player and some game-specific input functionality.

3:00 PM

We now had input working and the players moving around in a bubble-y fashion, and bouncing off the edges of the playfield. With only two hours left, I began to look into getting the enemies in and working, while Russell started picking some sound effects out of Sound Librarian.

4:00 PM

After getting the first enemy in and flying across the screen, my next key task was to define a “collision area” for each enemy – we couldn’t simply use a big centre-oriented radius for the enemies like we had for the characters in the bubbles. I ended up doing this by defining a radius and offset for the collision within the XML files for each creature.

Having spent the previous hour preparing some great sound effects, Russell got to the point of putting them into the game and realised they weren’t in a format that Flixel/AS3 would play. We had a quick discussion about this, and decided his last hour would be better spent improving the 1-player win, 2-player win and intro screens, instead of hunting down a solution for the format issue.

5:00 PM

The last hour was a crazy rush of getting the rest of the enemies in, improving the timing for the enemy spawn speed and setting up the timing regarding when more difficult types of enemies would be spawned. At the last moment we decided to make the players collide, and to create a “bounce” effect that occurs when they touch – making the multi-player mode decidedly competitive, as players could now bounce each other into oncoming enemies.

Russell got the win states working for the single-player and multi-player states, and in a stroke of random luck found that he could place the characters on the win screen such that they look like they’re standing on the hill in the scene. We packed up and were ushered out before merging our final changes, but the game worked – we’d made a game in seven hours.

You can play a final version of BBQ Attack! here – it has had a couple of extra hours of work put in as we merged those last changes, tweaked the screens a little more and added a preloader, but we’ve made no fundamental changes to the build that we had at the end of the day.

As we travelled home that evening, revelling in the fact that we’d created a game in a day, we came up with three reasons why it was a worthwhile experience:

Possibility

All things considered, what we were able to achieve within those seven hours far exceeded our expectations. We now know that a prototype for any kind of (fairly simple) game should be no further than a few hours out of reach, and that knowledge is incredibly empowering for a game developer.

Cutting the Chaff

As a game programmer, especially when working on projects where you’re in charge, you can easily get caught up with developing the game how it “ought” to be developed, making sure each system you’re creating is modular, easily extensible and fully featured. This focus on excellence can be a great thing when working on projects for extended periods of time, but needs to be thrown out the window when prototyping.

We came a lot closer to distilling the process of game development down to exactly what is necessary, and realised that developing quick prototypes in an environment suited to it (such as Flixel or perhaps Unity) makes much more sense than developing them in other environments, particularly when you’re not familiar with that environment.

Bad Game Count ++

In any creative field, whether it be writing, painting, film-making or game development, there is a common mantra that is repeated as advice to aspiring creators – your first creations will be bad, but you have to push through and keep creating, and eventually you will have the experience and ability to make something good.

Regardless of your evaluation of BBQ Attack!, it’s probably not going to win any awards at the IGF (and not just because we didn’t submit it). But through making it we gained some measure of experience that will contribute to our next creation, and when we eventually do make something awesome, the experience of creating BBQ Attack! will have somehow informed that game’s development.

Thanks to Paul for organizing the event and inviting us to participate, our fellow Jammers, who were great to hang out with during the event, and the people of Melbourne who drew those sweet pictures that fill our game.

Before I became a programmer, I was an artist. From when I was six years old right through university, I was constantly writing, thinking up inventions or games, or trying to put my imagination to use in some other shape or form. I was full of ideas, wishing that I had the skills to bring those ideas to life, and slowly working towards that goal.

Now I see ideas for what they are. Ephemeral, transient wisps of thought winding their way through a single creative mind, before they evaporate into the atmosphere.

A common saying in the games industry is that an idea for a game, regardless of how good it is, is worthless.

The saying is true for the context that it is used in. People come to game studios believing that they have thought of the best game idea, an idea that’s going to revolutionize gaming. They expect that their idea is so good that we’ll drop what we’re doing and immediately start working on a realistic fire station simulator, or an MMO that where each player is a Greek god. The saying is used as a reality check – as if we don’t all have our own ideas for what would make great games?

It is also reflective of the level of craftsmanship that composes the art of game development. The process of taking a game from an idea to a reality is extremely in-depth, and 100% reliant on the skill and craft of those programmers, artists, designers and writers who are developing it. It feels, as a developer, that an accurate analogy for going from game idea to game actual is someone telling Steven Spielberg “Hey, a kids alien movie would be cool,” and him writing and directing E.T.

But the saying isn’t true in the context of being creative once you have spent time in the industry and made some games. If you have experience, if you intimately know the limitations of your platform, of your budget, of your team and your company, and have a game idea that is interesting, original, feasible and risk-averse within those constraints, that game idea is worth more than money, it’s worth making.

Further, anyone who has tried to develop a game from a bad idea knows that, while craftsmanship can turn a good idea into a great game, trying to make a bad idea into a good game is an up-hill battle (or at least, more of an up-hill battle than game development already is). The original idea for a game has knock-on effects throughout the entire process of development.

While the idea is for the most part a prokaryote from which the game evolves, many of the issues that arise throughout development and resulting ideas and design decisions would not exist without development being pointed along that track in the first place.

Unfortunately, thinking up ideas worth making is extremely difficult, and once you have that idea there are barriers to actually getting it made, such as convincing management it’s worth making over X license or Y sequel (often an impossible sell). But the toughest barrier lies before all that – the belief that ideas aren’t worth having, that it is impossible to have a good idea within the innumerable conflicting constraints that exists, that ideas are arbitrary.

A game idea is both a worthless wisp of thought in a creative mind, and a critical factor in a game’s development. We need to resolve this conflict, and realise the power of ideas, and how to wield them effectively.