Since then it’s been rather quiet on here but that’s not because the project ended. If you are following me on Twitter then you will have spotted that work was still happening but the update posts had moved home to IndieDB. The even more astute will have spotted that I have created an alter-ego for my independent game developing known as Squid In A Box.

Well Squid In A Box finally has a site!

This will be the home of all future news on my games (although the posts will be mirrored on IndieDB still) so you should all bookmark it and such.

I’m going to try and increase the amount of general games designing posts on here but there are only so many hours in the day and what hours aren’t spent in my dayjob trying to ship Enslaved are usually spent trying to finish Waves but you can probably expect a few musings on Crackdown 2 in the next few weeks as it will no doubt steal some of my precious free time.

In the mean time here is the last video of Waves. As you can see it’s come on quite a long way since the last one I posted here.

However there is more recent footage on the interwebs than my youtubes contains thanks to Epics UDK trailer they made for GDC2010.

The good bit is around 2:37 the rest of the video is clearly rubbish.

So things that are new in this version:

Pickups!

These will home in on you once you get close and form the basis for just about all pickups and rewards that will be in the full game.

Slowmo!

Collect Pickups to recharge your Slowmo-o-meter and then hit the right mouse button to slow down time. Very useful when you get yourself surrounded.

New Spawning Code!

OK so this isn’t noticable or will affect gameplay but it was some much needed rework of the code that was really holding back further development until it was done. This also gave me an opportunity to do a quick revamp of the Wave structure. It’s still dead simple but now no longer dependent on you killing one wave before the next starts. Depending on how well you are doing you may get ambushed.

The Future!

The biggest thing to change so far is going to be the way the waves are structured and managed. I have an idea for a system that is semi-scripted so certain things can happen at certain points in gameplay but largely procedural based on how well you are playing. Hopefully this will mean that better players won’t get bored trudging through easier stuff. Unlike most “Dynamic Difficulty” systems though this will mostly worry about making the game harder rather than making it easier. The later tends to rely on things like the player dying over and over and getting frustrated until the game is finally easy enough for them to progress which sucks.

There are also plans for an early alpha release as a kind of demo but I’ll blog about that closer to the time.

This includes the UI, Scoring and Online Scoreboards.

I find procrastination tends to set in at the end of my projects because of these boring bits and because I don’t have any work left to look forwards to on the other side of them. Being able to implement some awesome stuff is a great motivator for implementing the boring but essential bits.

So with this in mind I am trying my hardest to get as much of this out of the way now so that when I come back to it again in future it’s just to tweak and bugfix it which is infinitely less dull.

However this doesn’t mean I’ve not done anything on the game itself. It’s just that most of what I’ve done are small tweaks that annoyed me and were easy to fix. Things like making the game work at resolutions other than 1280×720 or fudging the camera so you can see more of the arena when you are near the walls. That kind of thing.

I’ll be back soon with an update after I get the boring bits out of the way.

Lets start with the video:

The most notable addition this week is a new enemy called a “Bumble”. Bumbles are so named because they bumble around the arena in a pseudo random fashion bumping into each other and occasionally the player. I wanted an enemy that would be unpredictable and serve to reduce the amount of empty space in the arena which would make it more difficult to just kite the “Grunt” enemies.

The wandering behaviour is based on this article although since I don’t have an infinite playing field to work with I added in some code that pushes the steering force back towards the middle of the arena the closer to the edge they get (although it’s not so strong that they don’t sometimes just bounce off the arena wall).

I’m learning some things about shoot-em-ups that I never realised before but which tie in with Deathmatch style level design.

For example – Power-ups exist not to make the player more powerful but as a way to get the player to move somewhere specific rather than just moving into the space with the least enemies. As enemies often spawn a Power-Up when they die; and this is often in the middle of other enemies, this forces the player to make a risk-reward decision. This is exactly the same as placing Power-up in a Deathmatch level where the best weapons get put in the most exposed and least defensible places.

Finally if you want to read about the more technical work that went on this week (most of my time was spent refactoring code rather than adding new features) then check out this post on the UDK forums where I talk about Actor pools, memory fragmentation and Pawns being overweight.

So to update: I decided to ditch my efforts to make a physics based puzzle game for two reasons:

1. The cap on angular velocity.
2. I wanted to make a game where you get to blow things up.

If I’m honest it was mostly the blowing things up bit that turned me.

So using what I had already built as a base I started experimenting with making enemies that I could later shoot at. There was much messing around with navigation meshes and pathfinding before I eventually decided to ditch anything remotely complex and keep everything as simple as I could.

This resulted in an “Enemy” that looked exactly like the player and whose only behaviour was to roll towards them as fast as they could. Heck entire games have been sold that only have this behaviour.

With my simple enemy type I set about coding up a simple weapon class and targeting system. Bullets get shot towards the mouse. I used the basic Projectile class that is built into Unreal for my bullets and wrote a simple state machine for my gun that just spawned a bullet on a timer.

Behold!

This however was about from a week ago. This weekend I decided that it was time to give the game a full visual overhaul and get some sound up and running. You can see what the result of all that effort was beneath the cut:

I think it’s quite spiffy myself. The balls are still there but just hidden so the physics remains the same (although I’ve gone back to using impulses and not torque to avoid the angular velocity issue).

As well as giving the game a complete new look there were innumerable tweaks, bug fixes and indulgences that went on. Just getting the explosions to change hue over time was a couple of hours work alone and there was about 3 hours of completely failing to understand the math behind line-circle intersections in order to fix an issue with one of the enemy spawners (the friendly people in #Unrealscript will recall me appearing briefly just to rant about it last night).

Right now however I have a huge list of things to add, I have lots of different enemy types to add as well as more feedback and effects to implement and one game mechanic in particular that I think will be very interesting.

It’s been tentatively titled “Zero Point” by the way. It’s not a great name but I was tired of calling it “TestGame” feel free to leave suggestions in the comments thread.

They all then rushed to the forums to ask how you make a game.

Fortunately I’m an old hand with Unreal, starting back in 2000 modding Deus Ex and then progressing pretty much hand in hand with the engine through each version to the current one often being paid for the pleasure. I’m one of the few people in the world who can say they have worked with every version of Unreal that doesn’t work for Epic.

So rather than rush to forums asking how to make games I just made a game.

BEHOLD! One short weekend of fiddling with UDK later and I have something that can be very loosely called a game…

Ok so it’s a ball that rolls around a simple level collecting glowy yellow things.

More beneath the cut…

If I’m honest I spent more time fiddling with particle effects and lighting than I did actually writing code. Some people liken it to Pacman, other mention Marble Madness. At this point I didn’t really have any plans of what I was going to make and was really just poking the code to get something to happen with a minimum of effort.

However as more people encountered my little endeavour I was encouraged to maybe make something a bit more interesting.

Here is my list of restrictions that I’m bound by:

• Project can only use content that I can create myself.
• Project must support online multiplayer.
• Project should epitomise Systemic Game Design.

With this in mind I decided to expand on the physics theme and spent a few hours on monday and tuesday implementing support for buoyancy (which PhysX doesn’t support out of the box) and fiddling around with Fluid Surfaces.

It’s during this phase that I relise how lucky I am to be an Unreal Developer by day as I stumble across one of the more annoying features: The C++ Black Box.

UDK doesn’t give you the C++ source code. This means that there are times when the engine is doing something that doesn’t make sense and has disappeared into the Black Box of Native code. In this case it was the calculation of a physics objects mass.

This means that some constants and formulas are locked up beyond the prying eyes of the UDK programmer.

To cut a long story short however it turns out that Mass in Unreal is calculated as:

(Volume x Density)^0.75  x MassScale

The argument being that it reduces the difference between small and large objects because PhysX behaves funny when you have wildly different Masses involved.

Whatever the formula though so long as you know what it is you can at least be sure your simulation is internally consistent even if it isn’t a 100% accurate recreation of the real world.

With this version I change the Balls physics to apply Torque rather than an impulse which gives a more satisfying and “Physicsy” feel and even allows the ball to climb walls a little (hurrah for friction!).

So far however I’m still just playing around with tech and not really concentrating on the “Game” part. I have vague ideas involving fire, wind and fracture meshes. I also have an idea for making enemy cubes that stomp around the map but it’s early days yet.

Watch this space.