OK, Here it is in it's raw unadulterated awesomeness.
The aim of the game is to race around the track in your little solar powered race car. You have no battery, only a small capacitor which charges when in the sun and loses charge when load is places on it. Beware of the clouds, they will block the sun and your internal systems will quickly discharge the capacitor. Beware of hammering the accelerator, while this gives a boost, it quickly uses charge.
While at speed, using the brakes will replenish some charge with regen-braking.
You can only steer while moving, you can reverse if stuck.
Please bear in mind the following:
This game was made in 8 hours - expect bugs.
This game is unpolished - expect roughness
You can play this game forever, even though a winner is declared - you can still race around. This however turned out to be a lot of fun as people seem to be mostly interested in ramming each-other.
What you will need.
Windows ( We may upload the mac version in the future and update this post )
2 Joypads. There is no keyboard support in this version.
A friend. This is a 2 player game, designed to be played side by side for shouts like "In Your Face Loser!" to have full effect. Also, so the meta cheat codes can work (i.e. hitting your competitor with a pillow or pushing them off the sofa.
Of course, this game comes completely and utterly without warranty of any kind. Although the machines used to build the game are virus free (according to Avast) there are no guarantees in this world. All we can say is that the game does nothing intentionally malicious - unless pitting 2 competitive players against each-other in a race/fight to the finish/death can be called malicious.
Our merry group of developers took a trip to London with one purpose. To make a game in a day. We had no idea what the theme for the game would be, it's always a closely guarded secret until the morning of the event.
With no way of knowing the subject, it was impossible to predict what kind of game we would be creating. So we pondered this for a while.
We arrived in London to nice weather, the streets were dry and it wasn't cold. Just the type of weather needed for sitting inside all day and writing games.
We'd not been to the location of the GameJam before so it took a little time to get our bearings and find the place.
After a little time spent looking for the new (and amazing) SkillsMatter building "CodeNode" we arrived with a little time to spare, got ourselves signed in and joined everyone in a large room where the plan for the day was given to everyone. There were people from various sponsors there, a group from Audi were there as well as a team developing devices for an "Internet of things". It was all very cool.
GameCraft London 2015
There were actually 3 events going on on the same day, such is the massiveness of the SkillsMatter building and how much in awe I am of it and grateful for their kind hospitality - You guys rock! People were encouraged to mingle and to see what others were working on. It's great to meet people who share a passion for development, no matter what the subject is.
11:00
It came time for the brief for our event. Batteries not included.
The irony being that the majority of the machines being used to develop needed batteries to function.
With 8 hours to go, we had to come up with a design pretty quickly. Dean came up with an idea in a eureka moment and suggested a top down racing game where the cars operate on power from the sun. I'm a big fan of alternative energy and electric cars so I was all in. I also used to love the old top down racers on the Spectrum.
Within a short amount of time we had a very detailed design on paper and coding the game could begin proper.
Detailed and comprehensive design.
Design is everything.
We took graph paper and pens to work out our design first before touching any code. It's probably a good rule of thumb that if the design is too complex to fit on a side of paper, it probably can't be made in a single day. Skillsmatter also provided graph paper - great minds think alike, but it's always best to come prepared.
With the design agreed, I set about designing the cars while Dean put the Farseer physics system into our framework. We'd set up a git repo the evening before so we could easily share code without stepping on eachother's feet.
Once again we would use our familiar tools of MonoGame and Xamarin studio with Spine, Mixcraft, Audacity. However this time, I thought I'd try to use Adobe Illustrator and Photoshop instead of my normal Xara.
The more we use these tools, the faster we become at producing content. But also it means that with MonoGame and Xamarin studio, we don't have to worry about trivial details like Operating Systems and hardware.
Dean used a Macbook pro and I used a Windows 10 laptop. A few years ago, this would have been almost impossible to share any kind of coding tasks between us - delegating one of us to graphics while the other gets on with code... thankfully this was not the case.
Although I did do a lot of the graphics...
The game started to take shape once I got the basic graphics to Dean so that he could animate them in Spine. He's getting rather good at it too and it wasn't long before we had a working race car.
I got to work making the track. I used Illustrator and Photoshop to put the basic track together.
13:Once I had the basic track, I sent that to Dean who then placed the bounding boxes for the physics system to use to contain the cars on the track. He did this also using Spine.
MUSIC!
While he was doing that, I got to work on the music. A racing game needs music to set the mood and to keep the adrenaline flowing, but we didn't have much time to spend writing a magnum opus. So I fired up my trusty Mixcraft and started to layer some of the samples in the library.
The results of this can be heard on our Soundcloud.
With this done, I mixed it down to an mp3 and added it to the MonoGame content pipeline for inclusion into the game. Very Easy!
Then it came time for the game's title. Dean had the track and cars loading and was working on getting the collision detection working, so we took a short break and came up with a name. Both Harvey and Dom (a visiting old friend) came up with the idea of Solar Race Cars, shortened to Solar RC and then turned into a logo.
Following that, Harvey got to reprise his role of voice actor to give us the announcer sounds which we recorded using a RockBand microphone and processed in Audacity.
For the final push, once all of the assets had been created, Dean and I shared the remainder of the programming, tweaking the physics and getting the gameplay working as it should... finally resulting in a multi-player top down racing game.
Harvey liked it, we were on to a winner.
With very little time remaining, we had to polish the game into a game which others would enjoy. A few things were required, braking and reverse - We'd not added those initially, but it became apparent once cars started ramming into walls that brakes were probably a good idea.
19:00
Finally, the time was up and we had to down tools and let people play our games.
Not all entries could be completed unfortunately, but there were some decent games on display - one of which was a card game using NFC chips as part of the game mechanics - very interesting stuff.
Play time!
Things were getting very competitive on our table, once people got the hang of managing their power levels, they quickly learned how to defeat each-other, taking advantage of the sweet-spot on the controller where power output was balanced with the energy intake from the sun. Then they did what all people do in driving games, rammed each-other out of the way to get to the finish line first.
Finally, it came time for the voting to end and the judging began.
In 3rd Place
, was a game by Ross McKinlay who single handedly wrote another racing game with a different take on things - as well as a very impressive tunnel effect made entirely using trig.
In 2nd place
was the NFC card game, lots of people enjoyed playing that game - although I didn't personally get a chance to play :-(
and finally in 1st place....
in case you were wondering, it was SolaRC
In closing
Everyone had a great time, we played some great new games which in the morning of the day didn't even exist as an idea in the developer's heads. They were born on the day.
It's always amazing to me how much people can create in such a short amount of time and how warm and kind everyone is even while working under such time constraints..
Thanks again to Skill Matter for hosting the event and thanks to GameCraft for organizing an amazing day.
...or how to build a game without p!$$ing off the missus.
Using a Game Jam as a tool to kick an idea into action. All while being fair to those who share our lives.
Face it, we're all busy people.
Modern life is filled with distractions. Some more deserving of our time than others, some are essential and spending time on other things could be seen as neglect - but we won't dwell on those things. The distractions are there whether we like it or not.
Here's a few of the most common ones. Although it's not an exhaustive list. See if any of this rings true for you...
Most aspiring app or game developers have a day job.
This takes between 7.5 to 8 hours a day from the pool of available hours, OK - it pays the bills, but it's not the ideal use of that time. Unfortunately, unless we catch a break, we cannot ditch the job. Most of the time the job is in a similar field as the idea (e.g. Software engineering) and when we return home after a grueling day of meetings, code and stress - there's not a lot of mojo remaining for that million dollar idea.
Some have partners.
Significant others who rightfully demand time. They too feel the hours taken by the day job and are often reluctant to allow or simply can't understand why there is a desire to put additional hours into a similar thing that their loved one was just complaining about five minutes ago - but has some idea they want to try which means more time alone. This one is the most tricky to deal with because partners are usually very forgiving and will tolerate a little time - but it's easy for this to become unbearable and they quickly put their foot down. This can lead to a lot of friction. (been there, got the tee-shirt)
Some have children.
Similar in a way to the demands of a partner, children absolutely need time and don't like it when they don't get that time. Although, children can make good assistants if the game or app is written with them in mind. They make good testers and sometimes can provide their talents too. (Sounds, art etc)
Then there are competing hobbies.
like sports, going to the gym, the cinema, bowling with friends, parties.
These are the activities of a healthy life and a sign of a well rounded individual (apparently).
They're also a massive time sink leaving very little time to develop that killer app.
So how can we proceed? Most of these activities are essential or not easily avoided, so they take their price in hours, leaving very few hours remaining to get any work done and often leaving the developer very tired afterwards.
There are three options.
1. Abandon the idea.
Knowing that there will never be enough time to devote to the idea to allow it to grow enough to see whether it would be worth extra development or not - may as well give up.
2. Steal a few hours from here and there.
Hoping that a few hours will be enough to get into the zone, to focus for long enough without interruptions to make sound design ideas. Stealing a few hours makes the project take a very long time to get into a place where a clear path to completion becomes apparent.
3. Have a Jam.
Book some time with your significant other, have a party and invite like minded friends to help - make an event of it. Brainstorm and see what you can produce in a few hours. This allows you to put the idea to the test very quickly. If you have helpers they can get parts of the application or game built while you focus on other parts. Setting goals to meet will keep you on track and at the end of the session, you'll have something to show for your efforts. Further more, you'll have had an entire day of uninterrupted work, you'll also have cleared it with your partner who will most likely use the time and have fun - all while knowing that they'll get you for the rest of the time.
It's also a great way to get the prototype ready so that you can demonstrate it - often buying more time to work on it.
Jams are worth their time investment a hundred fold.
Dean and I gave a talk about this very subject on the 1st of October 2015 at the Just Eat HQ in London.
We discussed our experiences in trying to get projects off the ground, the obstacles we'd come up against and our attempts to solve them.
One of these attempts being the Game In a Month initiative. A very strict set of rules which if followed will produce a game in a month, but it may take several iterations before it comes out.
Dean did produce a game using the system though, although he did stress that it was exhausting.
Then we discussed the tools we used during the process. Note the prominent placement of git. Having a source control system is essential in any project. We've lost far too many projects to the failings of hard drives and when working in a team, it is essential to have the ability to share and modify code without stepping on each-other's feet.
Most of the tools on the list are free or very reasonably priced.
So in summary:
A GameJam lets you focus your attention on the idea guilt free. It lets you collaborate or compete with others and gives you the opportunity to see if the idea bouncing around in your head is actually worth pursuing. Afterall, if the idea isn't worth it, it's best to know quickly before pulling all-nighters to get it polished and released.
London GameCraft 2014 Part Deux
Last year Dean and I attended the London GameCraft jam.
It was in an assisting capacity - providing video and effects support to any developer who wanted them.
This year, we're going again. Only this time, we're taking part!
We will be making a game in around 10 hours based on a brief that no-one will know until the morning.
It's going to be a blast and if last year is anything to go by, there'll be some amazing games made.
I've read that you should make 10 games before you reach success in game development.
This isn't a strict value I'm guessing or any kind of hard and fast rule. However, I do feel that it's in a game developer's best interests to make as many games as possible. Partly to hone one's coding skills but mostly to understand what makes a game interesting and fun. It's also an important journey of self discovery, to understand one's talents and limitations.
I wrote many games on the spectrum, however none of them were what I would call "Finished" apart from the game I've listed here. Unfortunately, nothing remains of any of them, it was over 20 years ago. The rest of the games were for the PC platform and more recently for mobile devices..
So here's my list.
Treasure Caves
ZX Spectrum. A platform game where you collect treasure in a scrolling maze like level to activate an exit which would appear after you'd collected enough treasure, all while avoiding traps and using teleports to move you to the next platform above. Perilous spike pits would plague your every fall.
The game included an editor where I would challenge a friend with a cunning level and he'd return the favour with an even more cunning level. This game was memorable to me because of the large levels, the large sprites. I had to write a Run Length Encoding compression system in Z80 (before I knew what RLE was) to fit the levels into memory. The game was fast and allowed for very devious traps. Even though the gameplay was simple, it was a lot of fun.
Language: Z80 Assembler, Basic
Status: Completed, Lost
SUOF: Subtle Use of Force
A vertically scrolling shooter where you must defeat an invading alien force using a previously mothballed fighter. You could collect weapons dropped from dead enemies, it had a variety of different aliens, each with their own abilities and tricks. There were also Bosses to defeat who also had their own patterns and abilities.
Language: Borland C
OS: PC MSDos.
Status: Completed - Unreleased
CHAOS: Battle of the Wizards - Remake.
A remake of the classic gameby Julian Gollop. Chaos pits 2 or more wizards against each-other in a last man standing battle to the death.
It was abandoned due to really difficult to track down issues in the code which would take a massive amount of work to fix. However the gameplay was faithful to the original with every spell and monster re-created.
Language: VB6
OS: Windows
Status: Incomplete - Abandoned
GUNS: A DelphiX example.
A turn based projectile warfare tank game where you control a squad of flying tanks who must fire at the opponents flying tanks on opposing mountain sides across a valley. AI behaviour aimed the turrets of the enemy tanks and raised shields. Limited fuel reserves and accurate aiming of the AI opponent meant that battles were usually quick and devastating -often needing quick reflexes and tactical uses of the shield. The terrain was fully destructible and this was the first game I'd written with a floating camera which worked independently of the player's control. It moved to focus on the selected tank and would also follow projectiles through the air to see where they landed - allowing the player to adjust their aim. All in real time. The game was published as a demonstration of how to make games using the DelphiX component set.
Language: Object Pascal
Framework: DelphiX
OS: Windows
Status: Completed - Released for free
Anomalous
A rip in space has occurred following an unexpected situation during a science experiment trying to find a new source of energy to save our world from environmental disaster. The device causing the rip has fallen through the rift, it's up to you to retrieve it before the earth and the alien world perishes. An entire story arc was planned involving alien civilizations and a civil war which would complicate your efforts.
It was a 2D platformer with skeletal animation - built from the ground up using a home grown engine called the CBCFoundation. An entire toolchain was developed to work alongside the engine including a level editor, skeletal animation editor and animator.
Unfortunately, a hard disk failure meant that I'd lost the source files for the majority of the art assets. It was an event which the project never recovered from.
Language: Object Pascal.
Framework: CBCFoundation, SDL
OS: Windows, Linux
Status: Incomplete - Abandoned due to hardware failure.
Lander
A variant on the old Lunar Lander game with a twist. You're in charge of a rocket which has to pickup and ferry spacemen from one part of the moon to another. Instead of using retro thrusters to control your descent, you have your main rocket which you must rotate around to move and slow down. Landing on the pad was tricky, you had to land at just the right speed and at the correct angle or Kaboom, however you could take some damage by hitting the mountains - making a horrible metal scraping sound as the rocket takes a pounding. I just couldn't get this game working as well as I wanted. The framerate suffered due to software rendering and the engine did not allow for the level of fidelity in the terrain I wanted.
I would later rebuild this in Unity as an example, however it wasn't as good or as much fun as I'd hoped and was ditched.
Language: Object Pascal.
Framework: CBCFoundation, SDL
OS: Windows, Linux
Status: Incomplete - Abandoned
Anomalous
A 3D version of Anomalous written using the Torque engine. This game was going to be the version of Anomalous it was meant to be. The earlier version being abandoned following a horrific hard drive failure. I created a lot of art assets however it seemed that no matter how many assets I created, I always needed more and the better I got at creating 3D assets, the worse my earlier work looked in comparison and my animation was horrible. Compared to professional offerings, I couldn't seem to compete. I needed to rethink this game. However I had a story fleshed out - just like the original attempt. It was just too big for a single person to build.
Language: C++
Engine: Torque Engine
OS: Windows
Status: Incomplete - Abandoned
Tetris
An example of how to build a tetris game, built in a weekend and offered on-line as an example. It was fully functional and surprisingly addictive, which I suppose goes to show how close I was to the original. It is an exercise that every game developer should do.
Language: VB6
OS: Windows
Status: Complete - Released for free.
GUNS
A 3D version of GUNS written using the Torque engine. A fully 3D version of the original game complete with a story about aliens using the Earth as a kind of courtroom to settle petty disputes with squad based tank combat. The human race being powerless to stop them, but the aliens appear oblivious to their plight although seem to have no designs on taking over the world. Abandoned due to complexities with the Torque engine in making it do what was needed for this game and because 3D games need a lot of good art assets in order to look even nearly nice. It became obvious that alone I wouldn't be able to make this game no matter how much work I put into it.
Language: C++ and TorqueScript
Engine: Torque Engine.
OS: Windows
Status: Incomplete - Abandoned
GUNS:Reloaded.
A back to basics reboot of GUNS with the intent to turn it into a completed game for sale. As the original however with the inclusion of multiple environments, better AI, refuel dropships, different turrets, friendly AI behaviour, A roster of pilots and a plot involving rival factions who do battle on the earth as their chosen combat zone.It even had a tutorial. It was abandoned due to the realisation that the CBCFoundation's inability to use hardware rendering had made it effectively obsolete. I'd also come to the conclusion that it wasn't that much fun to play.
Language: Object Pascal
Framework: CBCFoundation, SDL
OS: Windows, Linux
Status: Incomplete - Abandoned
Crashblock
Control a person inside a game of Tetris. The person clambers and vaults over the blocks in the arena to get into positions and calls the blocks into position and rotates them. The blocks are held by a chain of increasing fragility - it will eventually snap sending the block crashing down. The player can also request the drop however in either case, it's best to be out of the way when they fall or you'll get squashed. Multiple levels, 4 environments, power-ups. Character graphics were captured from real-time video and roto-scoped. Winner of the Pascal Game Development group's 2007 competition. Published in 2008. This was the last game I wrote using the CBCFoundation and Pascal for that matter. The CBCFoundation's inability to handle hardware rendering without a massive upgrade almost killed it, but it was the advent of C# and pascal's descent into obscurity which finished it off.
Language: Object Pascal
Framework: CBCFoundation, SDL
OS: Windows
Status: Complete - Released for sale.
SUOF: Subtle Use of Force - Mobile
A conversion of the DOS based vertically scrolling shooter. I started it as an exercise in getting a mobile game developed, to understand the technical requirements as well as the development process. I hooked in the tilt controls to act as steering and on screen buttons for firing. Unfortunately, it was slow and clunky requiring far more work than I had time for at the time. It also ran differently on different phones. It served as a insightful prototyle.
Language: Java
OS: PC MSDos.
Status: Incomplete - Abandoned
Reversion Bureau
A science experiment has gone horribly wrong and you are called in to make it all better. Effectively a spiritual reboot of Anomalous. A platform puzzle game using live action footage captured against a greenscreen. Multiple characters and a story. This game is still in development but features physics as well as logical puzzles. A key feature of the game is that the main character does not resort to violence - instead solves problems using intelligence, the environment and science.
Language: LUA
Framework: MOAI
OS: Windows, OSx, OUYA
Status: In Progress
SchemeWars
Control a person inside a game of Galaga. The live action greenscreen captured person fires energy bolts from their hands at increasingly difficult waves of enemies. Complete with Boss creatures, all aliens have their own set of abilities and tricks. Completed and presented at an Insurance trade show.
Language: LUA
Framework: MOAI
OS: Windows, OSx, OUYA
Status: Complete - Released for Trade show.
ROO!
An endless runner where you have to rescue little Timmy from the well. Designed to be completely cross platform and created during a GameJam in January 2015. The game is notable for it's responsive controls, Spine animation and speed.The game was polished up over a period of 3 months and released on Android, OUYA and iOS.
Language: C#
Framework: Monogame
OS: Android, iOS, OUYA, Windows
Status: Complete - Released for sale.
Untitled Block Puzzle
We have a project on the go at the moment, which we'll announce shortly. The result of the second Songbird Creations Game Jam.
This weekend, we had ourselves another GameJam. The aim of which to create a game in 24 hours and to later polish it with the view to it becoming one of our products. It worked really well with ROO! and given that we had an extra programmer this time, we thought we'd up the ante a little.
We'd stream the whole event on twitch.tv
We recorded a short video, complete with special effects and announced the event on twitter.
But the mission was simple.
Keep it Simple! Don't over-complicate it! Make it in 24 hours! Make it fun!
Friday evening arrived and it was time to get started on the first task.
What type of game to build?
The last gamejam back in January saw ROO as the result. A fast paced endless runner with simple controls. This time, we'd choose completely different genre and style.
We each sat down and came up with 2 ideas each, discussed the merits and downsides of each and chose a starting game.
After a decent discussion out of the ideas we'd had, We had a choice between:
A physics based space game,
A Zombie game,
A pinball game,
A beach game,
A puzzle game.
We ranked them based on fun, complexity and the amount of effort required. We will probably attempt each of these games in time however we decided to go with the puzzle. We probably had a good shot of getting it running within the time we'd allocated.
So the first thing to do was to determine the rules of the puzzle. A fairly simple block based puzzle where you rotate blocks to solve a problem.
We gave ourselves tasks. UI, Rules and gameplay.
We also decided to stay with Monogame and also pick up from the framework we'd built for ROO!
Obviously being a phone based project, we opted to develop for iPhone and Android simultaneously (Thanks to Xamarin Studio and Monogame, this is entirely feasible). We did however neglect to include a DirectX project - something which would bite us unexpectedly later on.
Roll Cameras
We started filming at 10am BST (9GMT) as scheduled, the stream was good - a little lag on the sound from the web cams, but that was to be expected. We don't have a studio for this stuff yet.
We had 2 cameras for viewing the team, one placed above and one from the side - these were running constantly. We then had TeamViewer running on each of our laptops in a shared meeting to allow us to see the desktops - we would switch presenter so that the stream could see what we were working on. (when we remembered)
It turned out that TeamViewer was perhaps not the best desktop sharing solution. It would end the meeting after a time - perhaps after a network glitch, it also meant that each of us were viewing the desktops using the external IP address, which quadrupled our bandwidth.
Sound was provided by TeamSpeak. The steaming machine ran a TeamSpeak server and each laptop ran the client. We'd mute and unmute microphones as needed (push to talk isn't great while programming and voice activated in such close proximity activated all microphones and gave an echo effect)
Dean gave presentations on installing Xamarin and Monogame on a Mac as well as an introduction to Spine.
We will be looking through the footage soon to make tutorials from the footage where possible. If not, we'll probably make some separate video tutorials later using the footage as a reference.
The Wrath of the Internet Gods
Everything went well up until around 5:30pm when the internet died. We'd been streaming for just over 7 and a half hours by this point. We tried to get the feed back up and running, but we failed. So instead, we took a break and grilled some food on the BBQ.
The internet was back, the Gods were appeased with the sacrifice of Burgers and Sausages on the altar of BBQ.
Afterwards, we got the stream started again and it ran well for another hour and 20 mins. Then it died completely and we couldn't get it going again.
Obviously our offering was found wanting.
This was incredibly frustrating. Furthermore, we were wasting a lot of time sorting out the feed when we could have been working on the game.
Ultimately, We took the sad decision at this point cease streaming for the evening - even if the internet came back up again. This was a real shame as we were beginning to make some real progress.
The internet was up and down for the rest of the evening which severely impacted our performance.
Everything we needed seemed to be on-line. Xamarin's Android player installer and most importantly - Git, our Repository.
Eventually it came back up and we were able to continue. Towards the end of the night, we managed to get a working prototype running - We'd achieved First Light.
Unfortunately, the gameplay screen wasn't very pretty so no screenshots so far. Dean and Jason had done a great job with the menu system though.
The next morning
Jason, Dean and I continued with development - sans livestream, we needed to get the prototype completed, at least playable enough.
Again, the internet connection could not be relied upon and getting the Android player to work now seemed to be causing problems. Also- once installed we found it to be much too slow to debug. A real Android device was required to get any decent performance. (although the iPhone simulator seemed to be fine).
We seemed to be cursed. We eventually put the DirectX project into the game and enabled mouse control so that it behaved as screen touches for testing purposes.
This turned out to be one of the smartest decisions we made all weekend. Debugging sped up significantly - instead of waiting for the APK to compile and transfer to a phone or to an emulator - install and then run. With that we were able to quickly code changes and debug the results.
It seems silly now that we neglected the DirectX project. ROO used it. I guess we thought we were making a pure mobile app so DirectX support wasn't required. Still this was one of many lessons learned.
At the end of the day, we had a working prototype and we could see immediately that the game was going to be addictive. You're going to love it.
A bit of reflection:
What went wrong?
Well, even with 3 programmers, writing a game in 24 hours is hard.
We did a significant amount of work on seemingly a simple game concept and we still couldn't finish it. We weren't trying to write a WOW clone or a MMORPG, this was a puzzle game. We kept it simple, we didn't go crazy with features.
However puzzle games are deceptively difficult to code. The game pieces have to work seamlessly together. It's actually simpler to create a shoot-em-up.
Puzzle games have their own managerial problems too, With a puzzle game, the core of the work can really only be done by a single person so that person becomes a blocker. Given that the majority of the gameplay is the puzzle iteself, there isn't a lot anyone else can help with. If the puzzle isn't working - you just have to knuckle down and get on with it. With a shooter, a lot of the game can be handed to other developers to work in parallel.
Basically, We underestimated how much time we'd need to make a puzzle game.
The internet connection caused delays with more attention being spent on fixing it than there should have been.
We could have used someone managing the stream, switching views and monitoring the chat a bit more closely.
I wouldn't say that we failed to reach our goals however. We did stream the day, we made a game prototype in the weekend and we had a good time. I just wish we'd achieved more - or rather that I'd achieved more as I was the blocker.
What went right?
We streamed for 9 hours in total. Not bad considering that we'd never livestreamed before, everyone was connecting to the OBS machine wirelessly and disparate applications were providing the components, each with their own requirements. Next time we'll have a much better idea of what's required.
We got a lot of framework code done. We now have a cool animated UI system which will make the game look very nice. It uses spine so we can program some really intricate transitions. This can be used in future games too.
So what comes next and when can we see something?
Now we're fairly sure that the game is going to be worth developing (It's OK to kill a prototype - they don't feel pain ), we will be putting more time into the game to develop it beyond it's current primitive state. We can use this time to test out variations on the theme.
We'll release screen-shots as we go when we're happy that they show something cool.
We don't have a name for the game yet, but stick around, follow me on twitter @thecacktus for the news from the trenches and check in here from time to time, you'll see the game as it progresses.
We may also do more livestreams as the project takes shape. Shorter ones though showing a focussed piece of work.
I write this with the sun beaming through the office window, more than a little tired from having very little sleep last night as I Tweeted to the world and generally shouted from the rooftops a very exciting piece of news.
Firstly, We're on the App store for iPhone and the iPad, the most difficult store to get into with the highest barrier to entry; Firstly there's a hardware requirement, then the build and certification process was intensive and then it's followed by a 2 week period of uncertainty where we wait for Apple to review ROO! where it could be rejected for any reason. Thankfully it sailed through first time. I put this down the the sheer amount of work we put into it beforehand. ROO Might be a simple game, but a lot of attention has gone into it.
Everything from the screen sizing, object placement and controls have been tweaked and polished to make sure ROO is the most fun it could possibly be.
Secondly, ROO! is not written using Objective C, It's using C# and Mono; all made possible by Xamarin. They truly have achieved the holy grail of software development - a tool which allows for realistic "Write Once, Deploy anywhere".
ROO was a test case for us; make a responsive and fun game which can be enjoyed by anyone, make it as efficiently as possible and release it onto Google Play and the App store.
I say efficient because as a small Indie developer, we have very limited resources. Time is just as expensive a resource as money so we really could not afford to spend time porting or re-writing ROO! for each platform.
Having the shared code project with a project for each build target has been amazing. It allowed us to focus on the core of the game and worry about the platform specifics later.
Coupled with Xamarin's debugging tools and simulators, we were able to test on Windows, Android and iOS with ease. Even connecting an OUYA or a phone was easy; We were able to deploy, debug and get on with the more interesting parts of development - writing the code to make the game.
Responsive and Fun
When I say ROO is responsive and fun, they are not my words. This is what I've picked up from the many people who I've spoken to about the game. Our goal was to make it Fun and as I stated in a previous blog post covering the development of ROO!, responsiveness would be key to achieving this. A game lives or dies on how well it controls. The developers of Super Meatboy focussed intensely on getting the "Feel" of the controls just right. It worked out well for them.
There have been games I've played throughout my life which look amazing from screenshots and then disappoint when it comes to the gameplay because of a lack of responsiveness. Typically older games with limited hardware - (but not always), but there have been a couple on the OUYA which prevented me from purchasing them.
What do I mean by this? Well, when you press the screen or the controller button on ROO! He jumps immediately. There is no lag, no delay.
We made ROO's agency the most important thing in his universe. He has a mission, to save little Timmy and nothing apart from his own lack of ability will stop him.
The trick to this we employed was to make the inner game loop as quick as possible and to collect user input first of all before any other processing. This meant that in the fraction of a second between game updates, controller inputs could be queued and acted upon immediately when the update happens - affecting the game processing which followed it. Keeping the inner loop fast meant that it didn't miss frames so ROO was always responsive on every frame update.
No Distractions.
We wanted the player to become ROO and zone out of the real world into an almost Zen-like state, so this meant reducing the distractions. This is why there are no collectables or monsters to avoid in ROO! It's all about the run. Don't get me wrong, the temptation was certainly there to add them but thankfully we resisted to keep the gamplay as pure as possible. There are a finite number of shapes to learn to avoid and a pattern to get into and once you've mastered those, the only thing stopping you from getting a great high score is well.. erm.. You..
The levels are random but you can really focus and get in the zone. Occasionally you will fall down a hole, hit a rock or faceplant a cactus, but you get another chance for every perfect landing you make.
The perfect landing and recovery mechanic was added in the second half of development after players became frustrated with their good run being cut short by a single mistake.
The perfect landings were in there from the beginning but they were effectively used to get achievements. By hooking them to the recovery system, the player was actively rewarded for good play and could use these later on to get even higher scores to beat their friends. You see, every life in ROO is earned.
ROO starts the game with only a single chance. As he gets perfect landings, he earns extra chances. They're not strictly lives as ROO doesn't technically ever die. He may fall or trip, but he bounces back.
So what's next?
Well, we've still got Windows Phone and Windows Store to go, it's delayed partly because of the extra development we needed to support an achievement system on the platform. As soon as this is complete, we'll be getting it to Windows phones.
It was Easter, so therefore in the UK, we had Friday and Monday as national holidays. So we used this time to launch ROO on the OUYA and to prepare for the iOS release.
ROO is currently (as of the 9th of April) waiting for Review. This apparently could take a little time so we all have to be patient. It will be really nice though when it's released as we've done a load of work to make it look nice on the iPad and iPhone with that lovely Retina screen.
Preparation is key
Of all the stores we've released on, the App store is probably the most difficult to get going with. There are many aspects of the store which take some research in order to get right. Luckily for us, Dean knew what he was doing and was able to steer our wayward ship through any potential rocks to get us out to sea. It's also the 3rd time I've had to fill out a Tax form. As Songbird Creations is a Limited UK company, we don't pay US taxes (instead we pay UK taxes) but Uncle Sam needs to be reassured that we're not trying to get away with his money, so we fill in a W-8BEN form and sign it.
For the OUYA I had to print it, physically sign it, scan it and send it back to them. Amazon had a version online and a handy helper, which while was handy could have used a "We're a UK company, just fill it in for me" button like Google does.
Confirmation is key
While Preparation was certainly important, I've never had to confirm as many things in my life as I did getting the more legal aspects of the store running. Phew, glad that part is over is all I can say.
Customization is key
Phones typically have a slimline aspect ratio some are 1080p others a variation of, however for a landscape game, you're typically looking at most of the action being towards the bottom of the screen, certainly for ROO this was the case. Pretty clouds, blue skies and mountains cover the top to middle and give the illusion of distance and speed while the foreground and character reside towards the bottom to ground the action.
For the OUYA, we needed to move things up a little otherwise the player is bombarded with a TV image made entirely of sky, for iPad it was worse as the aspect ratio is different again.
So we had to work out how much space was required to keep ROO in pretty much the optimal place while filling the rest of the screen with interesting but not too distracting detail. We had to make some more graphics to place at the bottom of the level.
Once we we done however, it looked and played really nicely. We also had to add an Achievement Toast system to complement the Game Center achievements which you can see in this video.
Feedback is key
On Friday evening, I went out around Cambridge and introduced a few people to ROO, one of the bits of feedback was to do with the Perfect Landing / Resurrection system. It waited for 2 seconds after ROOs failure and used a perfect landing token to burst back into the game (basically a lives system) however it turned out that people were becoming frustrated with the way it was implemented. Often they would reappear only to hit a cactus, a rock or worse - fall directly into a ravine. So something had to be done because while funny, I don't want unhappy players. So now there's a system where you're prompted to tap the screen to reappear when you want to or wait the full 2 seconds. Play testing this feature made it obvious that it was the correct solution. It makes failure your own fault as opposed to the game punishing you randomly.
A Happy Easter
It was really nice to see ROO on the OUYA store so I documented it with a little video. So you can see me install ROO for the first time on the OUYA as well as see how to get those pesky perfect landings. Stick around to the end for a little discussion in difficulty, game dev principles and a personal message from me.
So there you have it. ROO is on the OUYA market as well as Google Play store and the Amazon App store and we're awaiting our entry to the App store.
If you'd like to know more, why not follow me on twitter @thecacktus
Back in January of 2013, I was procrastinating on the Escapist Magazine website and I came across an incredibly good idea. A micro console which takes advantage of the recent surge in phone processing power and the Android Operating System; all combined within a tiny stylishly designed box which wouldn't look out of place next to the nicest TV. A full HD 1080p console from the outset with it's own games market with games which must be free to try.
Kickstarter had shaken up the games industry and it seemed that the reported stranglehold publishers had over the various software houses would be weakened and it would usher in a new age of the bedroom coder.
Well, that happened somewhat; The bedroom coder did emerge and a lot of them released games; and some of them were really good. Kickstarter became the go-to place to get funding for the more adventurous or ambitious. There were a few bad apples of course but the net feeling was positive. There are debates as to whether Kickstarter has been over saturated with games and that it's become more difficult to be noticed among the crowd, but that discussion is for another day.
Mr Schafer I presume?
Anyway, I'd been following the antics of the people at Double Fine and backed their kickstarter for the game which would later be known as Broken Age.
Their kickstarter went on to demolish their originally requested amount to the tune of $3.3 million dollars. The internet went bananas.
As part of the deal, they would document everything and the documentaries would turn out to be really insightful to watch.
It reminded me that Game developers, those people who create these amazing experiences that we love are regular people with hopes and dreams. They weren't too dissimilar to me, they had the same drive and passion as I did - just better funding.
A large dose of gasoline was poured onto my previously thought to be extinguished candle.
So with both DoubleFine and the OUYA breaking records on Kickstarter, it seemed like the perfect time to get back into games... and the OUYA seemed to be the perfect platform to release it on with it's almost guaranteed success and it's open - yet moderated - marketplace.
I missed the Kickstarter for the OUYA however I did pre-purchase one in January and it arrived in July while I was in the USA - I wouldn't be able to get my mitts on it for another 2 weeks. The plane didn't get home faster because of tail-winds, it was by the sheer force of my will! :-)
I remember being surprised at how small and shiny it was and how the controllers felt really nice and solid. It was simple enough to set up and with it's online market and free to play nature was instantly appealing. I soon found myself purchasing many games.
The biggest question became, what kind of game do I want to write? Platformer? RPG? Adventure? The ideas flowed fast and strong and eventually I settled on the game currently known as the Reversion Bureau, a puzzle platformer - which has had 2 years of development time spent on it. However more on that game later.
Fast forward to now.
It's April 2015 and we now have a game released on the Android platforms. It's not the Reversion Bureau, ( that game will come ). Instead, it's a cool little endless runner where a kangaroo named ROO! must race across the Australian outback to rescue his best friend Timmy from a well he fell into.
We've already released it onto Google Play, Amazon App store and now (pending) the OUYA. On top of this, we're putting a lot of work into preparing for the iOS release, as well as a Windows Phone release.
The OUYA is still going in spite of 2 difficult years in the industry which saw the launch of the new XBox One, the WiiU and the Playstation 4. OUYA have altered the rules a little in response to that; games no longer have to be free to try as long as they have a video to show the gameplay. So we've released our game for a very small fee.
To get this far it has taken a lot of work covering many aspects of the game development process.
Game Design
Lots of coding
Graphics creation
Rigging and Animation
Assets pipelines
Music authoring
Sound design
Video editing
Storefront management
Device Testing
Play Testing
Focus Testing
Project Management
Marketing
If it seems like a lot of work, that's because it is.
Most of it goes unnoticed as it's mostly not fun or glamorous.
For instance, Project Management and Marketing are incredibly taxing to do correctly and are utterly vital if the project is to have any chance of commercial success - or even being released as a product. Each market place has it's own store-front with it's own way of handling things. Marketing is hard work, even for something you love. It often feels like climbing to the top of every building in the city so you can shout from the rooftops. Those with money or sense employ others to climb the buildings for them, or employ those already positioned to shout.
So here's what I'm hoping for: That the OUYA can fulfil it's promise, that games made independently by small teams can reach those who want to have some fun, kick back on the couch and play games on their TV made by people who care.
But no matter what happens,
I'm grateful for that glorious moment where the stars seemed to align, the rebirth of the bedroom coder and the infinite possibilities which they could bring.. that and flappy bird, mostly flappy bird :-)
A plug for the cool little box
The OUYA is being sold online at http://shop.ouya.tv/ as well as on Amazon and in Target stores in the USA. If you don't have one already, you should pick one up. There's a lot to be said for the games available and playing with the controller is great.
A note to travelling executives:
The OUYA packs away nicely into a travel bag and given that most hotel TVs have a HDMI socket, and there's rarely anything on the TV anyway, it makes a great travel gaming system. Something else to do on those long business trips.
Also, a note to parents:
There are no disks, so no expensive games to break or scratch or leave cluttered all over the place. Kids can start the game they want, they're mostly for free and those which aren't are inexpensive. It supports up to 4 controllers, it's cheaper than an XBox, a Playstation and a Wii and it's still totally worth the money.
Thursday 26 March 2015
Making a trailer
So we put a trailer together for ROO. It took a couple of days to do and was a lot of fun. But why is this news-worthy? Well, apart from the fact that Roo is a fun game and shouting about it increases the chances of someone else having some fun (which is always a good thing) - I actually used some new video editing techniques in putting the trailer together which might be interesting for some people to read about.
Putting a trailer together looks really simple - and ROO being a very simple game, appears that it should be a very easy thing to do. Well, in a way it was a lot easier than putting a trailer for perhaps a movie or a show. (I've not edited a movie or show trailer - but after editing the London Part Deux game jam video, I can only imagine the difficulty involved).
Even though ROO is a simple and fun game, it's not enough to just capture footage and slap it into a video. When you consider it, you have more time in-game to enjoy the everything the game has to offer but only a tiny amount of time in a trailer video to show the goods and hook a potential player.
Before I start, I'll admit - I'm not an expert (watching the trailer will attest to that) but as with most Indy developers, I don't have a marketing department (or a budget for that matter) to give the task to, who can spend their considerable skills and experience putting something amazing together.
Unfortunately, until Songbird-Creations becomes somewhat bigger, everything is in-house by those who wear many many hats.
So this Trailer, how was it made?
Well, just like any other task in game development, you need to have the right tools for the job. I'll be putting some articles together over the coming months describing the tools we use and why we use them. But for video editing, we use Adobe After Effects.
Now, Adobe After Effects is a professional level tool which can accomplish a devastatingly overwhelming number of things. It's so powerful that most people will only ever scratch the surface of its potential and it used to have a price tag to match - which was normally sidestepped by pirates - however, through some amazing vision, Adobe have licensed their entire suite of software on a subscription basis, so it's not expensive any more. So there's no longer any justification in pirating (to learn it) and you get the added bonus of Photoshop and Illustrator (amongst others) included too.
The trailer is broken down into 4 main sections.
Introduction,
Story hook
Gameplay
Call to Action.
Introduction
The introduction shows our company logo and the Game's title. This is important to get right as it's the first thing the viewer sees. It has to get them interested enough to want to watch the rest. Viewers have a lot of content they can watch instead, so a video has to be worth it and someone making a video has to respect that time.
So I open up with the Songbird creations logo, some clouds and a Balloon. This is supposed to set up the viewer with the company signature and they follow the balloon towards the game's title when it appears. The balloon appears in the game in the distance. The balloon itself is from a game which was never completed which starred a cartoon version of my Wife, meaning that She's in every game I make in some way - kind-of like Stan Lee in all Marvel movies.
The screen then changes to show something similar to the in-game titles. All of this should only take a few seconds.
Story Hook
Then we need to get the viewer right into the story. ROO! has a very simple story where little Timmy has fallen down a well (again!) and it's up to Roo to get help. To do this, I wanted to have a scene I could move around in. This meant setting up a 3D scene so that I could have proper Parallax backgrounds to add a sense of depth to it. I could have done this by panning from left to right in a 2D scene, but it would have actually meant more work. After Effects has everything you need to manipulate a 3D scene; you can place cameras, manipulate them with dummy objects, alter their positions, rotations (and pretty much any property they have) all smoothly using key frames.
So I built the scene using real assets from the game and animated the camera to tell the story.
Roo and Timmy are in the outback (although Timmy is never shown) Timmy sees a well, and falls in - the camera pans and zooms in on the well. Following the splash, the camera quickly pans to Roo who looks suitably concerned.
Cue the game!
Gameplay
This is the part where we let the potential player know what the game is all about, what to expect and why they should play the game. ROO! is a very simple game, it starts out easy enough and gets progressively more difficult as it becomes faster and have less time to react. Eventually the player will succumb as their reactions become less able to dodge the oncoming obstacles - ROO moves at a fair lick of speed when he gets going.
The game is a mobile game for the most part, so to get the footage, I recorded the PC version using Fraps and ran through the game many times. My hope was to get a high enough score to show the game running a breakneck speed as well as record some amusing failures. The resulting movie file was 7.8gb - I'd have to edit it... a lot.
Roo is a game which can't really be shown off in static images, they don't do it any justice so hopefully the video does the trick. I cut several failures back to back for laughs, then did a run as far as I could get. The entire section is about 50 seconds long and basically shows the game in it's entirety. It sounds a little sad when said like that, but it's strange how something so simple can keep people engrossed for so long.
At the end of the gameplay section, is the Noooo section which normally greets every failure.
Call to Action
A trailer is after-all a marketing video so there needs to be something which informs the potential customer where to go next to find out more and potentially buy the game.
On this part of the video I wanted to show where the customer could get the game from - in this case the Google Play store as well as the Amazon App store. Later we'll have the App Store, Windows store and quite probably the OUYA market place. As these become available, we'll have to upload other videos - potentially replacing this one.
I didn't want to put a Coming Soon part on the video as I wanted it to be Factual, to 'close the deal' right now. When we're on the other stores, we'll be factual about that too.
The entire video is just short of 1:27 and is accompanied with the opening titles music for the game.
Although it is tricky, I tried to keep as much of the video in time with the music to keep them from feeling disconnected. I even make the Google Play and Amazon store logos dance to the music towards the end of the video.
As I said, putting a trailer together is Marketing, you have to try to get people interested in your product. Without marketing, a game is a fun programming exercise. If you want people to play your game, you need to let them know about it and a trailer is a good starting point.
