Login to GGJ
Exient Ltd, 2-3 Cambridge Terrace, Oxford, Oxfordshire, United Kingdom, OX1 1RR
At Exient we started our Game Jam plans quite late, but we still came out with a strong core team.
1 Sound Engineer
My name is Tom, I am one of the General Coders for Project Moderately Magical as we are calling it.
We started by congregating in the Meeting room at the office and watching the GGJ13 keynote and theme videos, after which a hearty brainstorming session took place. Many ideas were thrown around but almost unanimously the team decided to target a mobile casual audience.
It took a long time but eventually we settled on a game concept, we took inspiration mainly from 2D games we have seen/played, including Geometry Wars, Flight Control, and Beat Hazard. Tower Defence and RTS were thrown around heavily, but these tend to be niche and we wanted something with a broader appeal, hopefully we have found it.
Once we had a concept setup we moved forwards with a critical part of the weekend, food, Pizza from Dominos was the popular choice for the first meal.
Over dinner we started to flesh out roles in the 2 major departments (Code & Art), after we quickly adjourned back to the main meeting room and organised a final vague idea of an art style and sorted our basic game mechanics so the coders could get moving. We all left the room.
Thats when our first problem struck, here at Exient we are using the proprietary XGS Tech that is available in our studio. It broke, in a big way, meaning it is 9:30pm and we still haven't actually put any code into the real project, Sion and Jim are busy trying to fix the problem, Liam has started on the heart of the gameplay in psuedo form and I have written this.
so hello #ggj13! Anyways, I should probably knock out some code, toodle-oo!
Hi, I'm Jim, I'm the organiser for this Game Jam and also a programmer.
This game jam team is a little unique in as much as we're all professional game developers working for Exient Ltd. (in Oxford), and this weekend we're all working from our office, by the grace of the company's managers who are all about driving innovation and creativity :) Also we're using Exient's own in-house game engine.
Hopefully over the next couple of days our team members will be writing some useful tips here for any young developers who wish to know more about how games are made, so stay tuned for that.
For my own part, I'm half programming, half project managing. The former is something I'm familiar with, the latter is new to me, but is something I've been keen to try out for a while! Obviously there was plenty to sort out before the Game Jam even began (advertising it to people, organising team meetings to discuss the schedule, getting hold of the keynote video and theme), and afterwards I became involved in keeping the brainstorming sessions on-topic, ordering in food, and updating the website with our team details. I'm also aiming to do mini-scrums (agile development technique of keeping up-to-date with what everyone has done and is doing) every 2-to-3 hours.
On the programming side, I'm currently specialising in audio. I play guitar as a hobby so it's nice to approach music from a slightly different angle. I'm working with the Wwise library, which is arguably the biggest and most popular music library used in professional game development (the others being FMOD and Scream). It's free for non-commercial use and there are lots of great sample projects on the main website.
So that's about it for now. I'll keep you updated with our progress as the weekend unfolds :)
Okay, so if you're an indie game dev working on your first ever project then you probably don't care too much about project templates. But if you're working on your second, third or fourth project then you might want to start thinking about keeping a template project which you can use a basis whenever you kick off something new. It's amazing how much time this can save you.
Imagine the case where you've just started out on a project, and you know there's a load of great functionality in your last project which you want to reuse, so you duplicate it, open it up, and start pruning back anything that was specific to your last game, until you get down to just the core classes. This is very tedious, and sometimes very difficult! Especially if your last project ended in a lot of crunch time and you started putting in hacks left, right and center! Chances are you dropped some very game-specific code inside your base classes, so now you've got the job on untangling it all! Nightmare.
So, keep templates. When you're working on a project and add some great new functionality which you think might be reusable, take some time you also drop it into your template project so it's ready for next time.
Hi everyone, just a quick update to let you all know the project is coming along well! We had a slightly shakey start on Friday evening as we all got to grips with the core features of Exient's game engine, but now we're able to quickly and effortlessly load models, apply animations, render 2D sprites, etc.
I've found that doing scrums around every 4 hours is about right for a project of this length, and it's also helped keep us awake furing the early hours!
Speaking of which, around half of our team decided to head home and get a good 6-8 hours sleep, while 3 of us remained in the office and kept working through the night. I actually recommend getting some sleep both nights if you can. I've done jams with no sleep before and honestly, it isn't worth it. By the end it takes twice as long to do something half as well as you can when you're well rested! I'm certainly aiming on getting some hours back tonight :)
Hi, my name is Siôn Carruthers and I'm one of the programmers who worked on Heart Attack. Here is a brief summary of my experience over the weekend.
At 5pm, after watching the keynote and theme videos, we had a lengthy brainstorming session. Lots of ideas were thrown around, but we settled on an action game for mobile platforms, with the main interaction being to swipe a touchscreen to place barriers, preventing waves of enemies from reaching the heart, which the player is protecting.
Once the idea was finalised, we programmers went aside to formulate a plan and split up tasks. First job was to get a framework set up which we could build on - Jim worked on that, Liam got started on some entity managers, and Tom and I discussed the breakdown of tasks. Tom was to work on interpreting the input to create barriers, Liam was to focus on the enemy spawning and movement, Jim worked on the audio middleware, and I was to set up the rendering of our 2D environment and the entities, which we wanted to be 3D models.
We had a bit of a bumpy start - getting our framework up and running took a few hours, and then I had difficulty getting any 3D rendering to work. The problem was caused by our shaders; it turned out, which had become corrupt somehow. They were fixed and we were able to render 3D models by Saturday afternoon (18 hours in), but before then we had decided to cut our losses and switch to 2D sprites.
I worked all of Friday night, getting through the stockpile of energy drinks, and using our debug 3D rendering tools to draw spheres where the heart and enemies would be positioned and rendered. I got a lot of stuff done, but a good chunk of time was spent figuring out the screenspace-worldspace transforms and camera position. By morning we had our background rendering, mouse input being detected, barriers being drawn, enemies spawning and moving directly towards the heart, which took damage, and a game over assert was thrown at the right time! We made good progress.
With morning came our decision to change to 2D sprites. Our framework nicely allowed us to load textures in from an atlas, and draw them at a given position with a given rotation. As soon as the first ship artwork Nick made was put in, it started to look like a proper game! Over the day we had the heart put in, which was then divided into segments which would turn off when the heart took damage, and with a glowing centre to represent the heartbeat theme. Enemies were spawning from all directions, and Liam was working on a second movement pattern. Jim unfortunately hadn't had much luck with the sound middleware, but otherwise things were coming along nicely!
By 6pm (25 hours in) I was exhausted, so I withdrew, and slept for 12 solid hours. I was back ready for more at 10am on Sunday (41 hours in). So much had happened over the night! All three enemy types were in, with two different movement patterns, we had a fancy barrier, scoring was implemented, along with title, help and game over screens! It seemed not much was left to be done!
One thing we had left was VFX. None of us were experienced with particle effects, and while our framework supported them, we didn't know where to start. We took inspiration from Geometry Wars, but knew we wouldn't be able to come up with anything like that in the remaining time. I was able to simply swap between textures quite quickly, so that's how I implemented explosions - an explosion entity would just flick through a sequence of textures and then mark itself for deletion. Ships which hit barriers would trigger different-coloured explosions, and a massive "shockwave" explosion was needed for when the "panic button" was pressed, which cleared the screen of all enemies.
In the final hours, I was adding a few final features and fixing some bugs, such as barriers fading out then re-appearing (due to an alpha value greater than 255 being passed to it, so it looped around). Tom was getting the high score to be saved, Jim had managed to get sound in and was working on that with Joe, and Liam was finalising the title screen buttons. Just before our 3pm deadline for submissions, everyone was trying to get a build running, while Nick and I tried to pin down the cause of a bug which was causing white lines to be drawn at the edge of the textures. The problem was caused by our sprite images being rather large, and we were downscaling them quite significantly. Shrinking most of the images and passing the 2D render function only integers fixed the issue sufficiently.
It was only when half of the team was out getting us our victory KFC when we realised - we hadn't added a credits screen! Nick, Tom and Liam whipped one up while I added the code to handle it, and it was done within 5 minutes. The GameJam website was really struggling, but our game was submitted via the FTP, and we were done!
In 48 hours, we made something brilliant. Fun and frantic gameplay, gorgeous 2D textures, and an amazing soundtrack! I'm really proud what we've achieved, and will definitely be doing it again!
Fantastic work team!
I thought it's time to share some of my programming experiences from this weekend. I should start off by saying that although I consider myself a general programmer, I tend to specialise in gameplay and audio.
So, for this game jam I wanted to try broadening my knowledge of audio libraries by trying to develop an interface between our game and the Wwise library. Let me come right out and say that this hasn't worked for us, but I don't think it's any fault of Audiokinetic (the producers of Wwise). To their credit, they provide fast and free (for non-commercial use) access to their software and bundle it with a lot of great sample projects. I actually believe our troubles have been to do with Wwise competing against the existing audio library within Exient's own game engine, which we're using on this project; I suspect the two are fighting for control of the game's output.
Obviously we're on a tight schedule here so we've had to make the decision to let go of Wwise and just use the existing audio library. However, this experience hasn't changed my outlook on Wwise and I still believe it's the way forward and I encourage other developers to give it a try sometime.
Okay so here we are, Sunday evening, everyone's longing for a solid night's sleep, but the feeling in the room is one of celebration; that sense of joy and relief when it all comes together and you step back and realise you've actually just built a really awesome game. I'm honestly very proud of everyone here, watching them come together as a team, put in a crazy number of hours, giving up their weekend. I feel lucky to have been a part of it.
On top of that I feel I've learned a lot this weekend. From a technical point of view (speaking as a programmer) I've learned a lot more about the game engine we've been using. It's got a pretty steep learning curve, and can be quite unforgiving when you get things wrong, but it's very powerful. I've also broadened my knowledge of the Wwise audio library, something I plan to use in my personal projects too.
From a production viewpoint I've learned a lot about what gets people going and what holds them up. Obviously developers get slowed down by bugs, but it also seems to happen when they're unsure about how their work will fit in with the rest of the game; it helps if everyone has at least a rough idea of what other people are working on, whether it depends on their work, whether it will assist their work, etc. I've also found it's important to remain very openly optimist and enthusiastic about the project, for the psychological benefit of the team. I fear that at several points during the weekend I allowed my own frustration at coding bugs to affect my duties as producer; I was late doing scrums and I made myself less available to answer questions. These were mistakes I will ensure don't happen again. In fact I'm reminded of a story I heard from the lead developer on Fable III (Lionhead Studios) in which he said that after being made lead he often felt overworked because he spent too much time answering questions from juniors and didn't have enough time to do his "real job" of programming, but then something clicked inside his head and he realised that as a lead helping his coders was his real job, and with that mentality he was a lot happier.
So all in all I've had a very enlightening weekend, and I think all of the guys here will take away valuable lessons too. On that note, I will (at some point over the next few days) conduct a Post-Mortem (industry term), a quick survey with a follow-up meeting where people can offer further discussion points, about the project - what worked, what didn't work. I think this is a crucial step in improving and you'll see it done in lots of major game projects.
I think that's about all from me, so I'll just finish by saying a big thank you to the whole team, and to the Global Game Jam organisers for providing this website and so much more. I hope to see you all again next year!