Batteries Not Included - The GameCraft London 2015 event

On Saturday the 31st of October 2015 - Halloween 

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.

Thank You!

Physics Engines for things other than puzzles and explosions.

What's a Physics engine good for anyway?

I made my own Physics engine for Crashblock
 - cue rapturous applause - 
Thank you, it was hard work and there were times when I thought I couldn't resolve all of the issues, but I got there in the end. 
- applause intensifies -
It's main tasks were to prevent the player from passing through walls 
-hang on, that's a collision detection and resolution system - applause dies down slightly- 
and to simulate gravity 
- so it's basically, move everything down and use the collision detection and resolution system to stop things from falling off the level? - rapturous applause stops and crickets are heard -

Yup, that's basically all it did and it took a long time to get right; and isn't it basically what most games need?
So why do we keep re-writing the same code and why is it always hard?

I think it's because we re-write each game basically from scratch for a very specific idea.

If only there was some sort of library which could take the effort away and focus on the game...

Enter the Physics Engine

At it's heart a physics engine keeps track of entities, their energies and attributes and makes sure that changes in energy are correctly applied and objects don't move through other objects.
Come to think of it, that's quite a task.

Serious people spent serious time writing serious software to do all of this.

Something that can handle velocity, friction, acceleration, elasticity, gravity, mass and the resolution of collisions, calculating and transferring energies to other objects seems to be something that should only be used in serious games just to do it justice - anything else would be a waste right?

It is true, you can get a really good racing game written using a physics engine - but they're useful for other things too; and if you bear with me, I'll explain why I don't think it's overkill and actually very beneficial to even the simplest of games.

Most game requirements are the same

You see, the tricky parts to any game are simulating a world. Every 2D platform game does this.

Consider Mario:
Mario describes a world where a man runs along a blocky world jumping over obstacles and collecting gems. Mario must simply reach the end of each level to complete the game.

The world has physical attributes, gravity, collision detection and solid objects and destructible scenery when hit from underneath.

Consider Sonic the Hedgehog:
Sonic describes a world where a hedgehog runs at ridiculous speeds through a world filled with hazards to be jumped over, loop the loops and enemies to be killed. Sonic must reach the end of a set of levels and defeat a boss in various guises to complete the game.

The world has physical attributes, gravity, collision detection and solid objects. It also has things to increase velocity and destructible scenery when hit at a certain speed.

Consider Treasure Island Dizzy:
Dizzy describes a world with a cute egg who jumps over obstacles and tumbles when he lands. He avoids hazards and interacts with the environment. Dizzy must solve puzzles and collect items to unlock areas of the world to reach an island via a boat.

The world has physical attributes , gravity, collision detection and solid objects. It also has hidden objects to find and underwater sections.

With just these three different games, there are quite a lot of overlapping areas.

• Physical Attributes 
• Mass
• Friction
• Velocity
• Gravity
• Global
• Local
• Collision Detection
• Projectiles
• Hazards
• Hidden objects
• Zones
• Solid Objects
• Static
• Destructible
• Movable

For just these three games, the same problems were solved in different ways to simulate a world and to provide the game mechanics.

Back when these games were made, there really wasn't much of a choice; You made a game engine for a game or series of games and you optimized it to within an inch of it's life. 

Having a common system (if one existed) would have introduced inefficiencies. The simulations needed to be as bare bones as possible to be as fast as possible as every CPU cycle counted. That means bespoke code each time.

Those days are mostly gone. Processors are powerful and memory is plentiful. 

Games are often written in cross platform languages where you have little control over the actual implementation at the machine level. The chances are that a Physics System will be written in a more efficient way to any code you or I could write ('Serious People' remember)

So why do so many people still write their own physics simulations?

Well, It could be because it seems like overkill to use something so powerful for a simeple game. 

Or there's the challenge of rolling your own. There are a lot of interesting mathematical problems to get your head around. But for me, it's a distraction to the game. It's a problem someone else who is possibly much smarter than me and a whole lot more interested in solving said problems than I am.

I choose to use an engine.

This decision is fairly recent however. But now I've seen the light, I'm sold on the benefits. I'll never roll my own again.

What are the benefits of using a generic physics engine over rolling your own to your specific needs?

Collisions

Writing a collision detection system is to be fair - Tedious - and at it's most primitive, involves testing each object in your game with other objects in your game to check if they collide. 

The mechanism you use for this will have a massive impact on the performance of your game.

From the outside it seems simple enough so it's a common thing to write early on. 

The most common is a simple bounding box test.

You can do broad testing using rectangles to check if any corner of one object intersect with any other, hopefully this means that you've zoned your level otherwise you'll be checking a lot of objects. 

As you can see, the bounding box test is clearly not good enough to detect accurate collisions with the planes.

Then what happens when you collide? Do you need to do more granular collision checking? Pixel level? Polygonal? With each step comes more work. 

Pixel level checking is more accurate but old-school and was always CPU intensive. 

With more and more work being done on the graphics card, you don't have access to pixels these days. So you're more than likely looking at a collision mesh.

Then what happens when you've detected the collision? Do you let each object know about it and allow them to decide the outcome? Do to compute the energies exchanged as part of the collision and apply the resulting energies to the objects? 

What about really fast moving objects? Will you implement some form of ray-casting? Do you care about transferring rotational forces or velocities to your objects as a result of collision?

Are all objects Solid? Do you need sensors? Will you have Passive or Active checking?

Can all objects move or do you have static objects which cannot move no matter what?

Just this first part has uncovered a mountain of work. 

These decisions will need to be made before the game development can begin. or you can let a Physics engine do it for you.

X = X + 1 // Movement

Most early games have a section which reads something like this:

If Left is pressed Then Player.X = Player.X - 1

If Right is pressed Then Player.X = Player.X + 1

This code normally evolves to:

If Left is pressed Then Player.SpeedX = -1

ElseIf Right is pressed Then Player.SpeedX = 1

Else Player.SpeedX = 0

For each object in game

object.X = object.X + object.SpeedX

The origins of a physics system. You are tracking velocity in the X axis.

With a physics engine, you can apply an impulse to an object and have it calculate the energies appropriately.

Collisions Pt2 Sensors

The Physics Engine I wrote for Crashblock was also used in a game which was tragically shelved called Guns-Reloaded. 

The AI for enemies was assisted by attaching sensors around an enemy tank which could inform the tank's brain of things like incoming projectiles and dangerous terrain. This meant that the enemy flying tanks could in theory fly close to rocks but not close enough to become damaged by collisions. It also meant they could raise shields to save themselves. 

The data from these sensors was fed into an AI routine and appropriate behaviour was determined. All in all, it worked pretty well.  

Unfortunately, the game failed to mature but the lessons learned from that were carried on to a recent game which I did complete, called SchemeWars. 

In that game aliens were aware of their own positions and the position of the ground as well as dangerous objects flying towards them so they could defend themselves. They also used other collision objects to keep each-other a nice distance from other aliens.

This behaviour was much easier to code that with Guns-Reloaded as I was using a Physics Engine.

Box2D is fast and awesome, you should use it.

http://box2d.org/

I first heard about Box2D when I first saw a game called Crayon Physics. A simple game where you draw objects in order to get a ball from one place to another. 

It was very clever and used the majority of Box2D's features.

http://www.crayonphysics.com/

I seemed to be a perfect fit for that game, but it never occurred to me to use it in a platform game.

I started building the Reversion Bureau (working title) and again, I rolled my own physics and collision detection within the MOAI framework early on; not giving a second thought to the Box2D implementation already built in. My collision code sucked. It was buggy and it was inflexible.

www.getmoai.com

So one day after reading a book from the writers of MOAI, I gutted my game and implemented everything using Box2D. Suddenly, I had perfect collision detection, silky smooth movement and slopes (gasp!). The previous collision code used the tile set and slopes would have required specialised code.

 

This is a screenshot from a very early build of the game with a debug layer showing the collision rectangles. Anything collidable has a green hue and 2 lines (green and red ) showing it's orientation. 

As you can see if you look closely, there is a rectangle around the red guy on the right. That's his collision rectangle. 

There's also a little block underneath him, intersecting the floor. This little block is a sensor attached to the sprite to detect the floor so that the sprite can see whether it is falling or standing; very useful.

There's a block to the left over a door, this is an interaction sensor.

So in this one screenshot you can see Rectangular collisions blocks, polygonal collision blocks, sprite collision blocks and sensors; and it's FAST!.

This does involve a bit more work building your maps in such a way as to provide an object layer to create the collision blocks and polygons. 

Tiled does this very nicely.

http://www.mapeditor.org/

The end result being a smooth and reliable collision resolution system, far better than anything the average developer could write as well as accurate simulations of bounce, torque, friction, gravity.. pretty much anything you need to build a game world - realistic or cartoon.

In Closing

Physics Engines are amazing and useful, they're not just for realistic simulation games and you should absolutely consider using one if you're serious about making any game.. spend your energy wisely and don't reinvent the wheel... literally.

Wow that was a long blog post.