Tag: games

Caaargh Game Development Blog #3 – Complexity from Simplicity

In my last post a few weeks back I was pondering whether to add more complex track segments to the game (Caaargh!) as a way to make more interesting tracks. It must have been a good question, as it’s kept me occupied for the best part of a month.

In the end, I found I was able to generate many more, more-interesting tracks by making the component pieces even smaller and simpler than they were before.

Example of old style track pieces
Example of old style track pieces above
new_style_pieces
New style track pieces are much smaller

As part of this process I updated the scripts that generate these tracks to work with arbitrary directions and angles which also freed me up to use vertical space as well as horizontal in the game. This means tracks can now cross over themselves in interesting ways.

Track's can now vary in height
Track’s can now vary in height

There was a bunch of new modelling work to-do, and I can’t overstate how much I’ve been enjoying using Sketch-up to make these. It’s such a human friendly piece of software given what it can do, and it exports nicely enough to .fbx files to work with in Unity.

sketch_up_deadend
Modelling a deadend segment in SketchUp

The new track modelling work has let me fix up the aesthetic and practical (in game physics) issues that were bugging me with the original track pieces, and at the same time make the track a bit narrower which better suits the single-player game-play.

Here's the car relative to the track
Here’s the size of the car relative to the track

Here’s a quick sample of generating a bunch of random tracks of a specific length.

track_generation

There’s still plenty to tweak in here, but the next design decisions about tracks can’t properly be evaluated until some of the other game mechanics are in place, and what’s here goes through some more play-testing.

Also, banked corners looked fun, but didn’t play well. Sorry banked corners.

banked_corners

Caaargh Game Development Blog #2

This week has only seen a little time spent on Caaargh, but I’m trying to keep this blog updated, so here goes.

This week I’ve mostly been thinking about the segments of road that make up the race track in the game. To prototype the game and get the development started, I’ve been working with a collection of models bought from the Unity Asset store.

capturea

These got me off to a quick start, but are actually causing some of my biggest gameplay bugs right now and visually I wasn’t totally happy with them.

Visually, I don’t like the fact that the track edges don’t have any depth to them. They end up looking like sheets of paper stuck on the edge of the road. Also, something about the way these were modeled means the road surface and the edge don’t join perfectly so you see a slither of light through the road, and it shows up annoyingly in the shadows these cast onto the ground below. See below.

capture

The road/track shadows might seem like a minor detail given the other major work this game needs, but in Caaargh these shadows are one of the few visual clues that help the player ‘see’ upcoming corners given the deliberately restricted camera view. They also help the player orient themselves in the world after turning many corners. So I decided I needed to fix or replace these track segments because the shadows are important.

From a gameplay point of view, the edges and angles of these tracks were also causing occasional physics based chaos with the car getting stuck, or flipping in ways that weren’t very satisfying for the player. By building new segments myself, I can tweak these until they work just right. Or at least take the blame if they don’t!

Now though, I have a new game design challenge to think about.

The size of these original segments were pretty uniform. E.g. the lengths and widths of each segment were always 16, 32 or 64 units and if they rotate it would be 90 degrees exactly. These could be combined in interesting ways, but essentially created a certain style of track.

E.g. here’s an example when I click the generate random track button…

track

Now that I’m building new segments myself, these can be any size or shape I might want. This could be a good thing, and more interesting segments might lead to more interesting tracks, but it might also be too much. In this game you rarely see the track ahead, and you learn it by failing over and over again. If most of the tracks existence is in the players mind rather than on the screen, simple segments might be the best after all. I don’t know if 29 degree turns are a good idea or not.

capture3

So I’m going to have to test this. I also have to be careful not to the let this opportunity to add more complexity to the game slow down the development overall.

My gut feeling is that the track can be interesting even if the segments are simple, and that that’s more important overall.

capture2

For now though, I’m enjoying this 3D modelling work. 10 years ago, I used to know my way around 3ds Max, but these days Sketchup is doing the job just fine.

Sign-up for my newsletter here.

Caaargh Game Development Blog #1

I’m making a game called Caaargh, and I thought it would be a good idea to write a bit about the development as I go along. This is the first blog post to get that ball rolling.

Caaargh is inspired by one of my favourite games from my childhood, Micro Machines Turbo Tournament. In particular the experience of playing a four-player race, where the winner drives right up against the leading edge of the screen and gets very limited visibility of the track ahead.

In Micro Machines, the difficulty this limited camera view caused the leader created a beautiful balance mechanic that made multiplayer games so tense and exciting, especially when combined with the crazy tracks with plenty of places to crash if you forgot about an upcoming corner.

If you’re not familiar with Micro Machines, it’s worth watching a recording of a four player race see how this works.

After playing a lot of Micro Machines, you eventually race the tracks by memory. You remember what turn is coming up after the spilled cereal or the red cue ball, and you begin to steer before you even see it so that you can take the corner at full speed.

It is this second implication of the limited camera view that I wanted to play with as the core mechanic for Caaargh.

In Caaargh, the tracks become a series of memory puzzles. A bit like that kids toy game Simon, with the primary colours. But instead of remembering a series of colours, you have to remember a series of corners. And instead of pressing you buttons you have to steer the car.

Playing this way is also a bit like racing a rally car without a co-driver.

I’ve been working on this game on and off for a few months now and I think I’ve tested enough of the concepts to want to push this through to be a real game. So as I do I’ll try and write something on this blog at least every couple of weeks.

The latest news (for those people who’ve seen a bit of this story on Twitter already) is that I’ve decided to target mobile for the initial game release.

In the long-run I’m really interested in making this a co-operative local multiplayer game for PC and console as I think there are some interesting dynamics that will come from the mechanics that I have planned in a co-op setting. But I can also see a much quicker route to completing a nice single player version of the game that would be well suited to mobile. So that’s what I’m working on now.

This week I’ve been getting placeholder screens in places to manage the player flow from title screen, to level select, to level results screen etc. These are not visually interesting to share at this stage, but I feel good seeing the prototype turning into something that feels more like a real product.

That’s it for today.

Also, you should sign-up for my newsletter about my game design projects here.

Concept Game – Simple Evolutionary Model

I’ve spent enough time on this now to submit it, even if it’s still a bit rough around the edges. I’ve included a bit of a write up below. This demo will run best in Chrome or Opera. Click to play.

I’ve built a simple ‘game’ called Digital Husbandry. It’s more of a time killer as it doesn’t have any serious game mechanics, but there is a visual reward to keep the user engaged.

It’s based on the idea of simulating progressive evolution through selective breeding. Much as generations of farmers have done with livestock. The player brings together critters on the screen based on visual qualities that appeal to them, and produces offspring that drive the overall appearance of the group closer to those qualities selected by the player. The ‘critters’ die when they reach the ‘deadzone’ at the bottom of the screen, freeing up space for new critters in the population. So choosing which critters to sacrifice is as important as choosing which ones to breed.

The critters are recursively drawn from a simplified ‘genetic’ code. This allows the game to have millions of possible variations of critters, and the longer you play, the more varied the critters will appear.

I ‘composed’ some music in http://www.beepbox.co (which is a hugely fun distraction from fixing bugs in code). The music gets more layered and complex in line with the number of critters in the population. The audio tracks aren’t perfectly synced, but I’m happy enough with the effect for now.

NOTE: I ran into problems publishing the sketch with audio and I’ve run out of time to do any more work on this, so I’ve had to submit this version without sound.

A quick review of the Coursera Creative Programming Course, and using Processing for this kind work:

  • It was nice to write some code that isn’t about capturing web form data or sanitizing user input!
  • The format of the course, and the challenge I set myself were a good way to revise some of the classic programming concepts I don’t actually have to use much these days
  • I was jumping between Java and JavaScript quite a bit – which is a good study exercise, especially when porting code from one to the other. My basic Java knowledge is rustier than I thought, but I got there in the end.
  • Processing isn’t quite right (yet) to take a project like this and polish it into a publishable product (which is partly why I haven’t worried too much about the finer details of this ‘game’)
  • Processing is excellent for teaching creative programming
  • It was a shame to loose the sound, I had a slightly mental retro game tune going by the end. This was the base tune, which built in complexity with each additional critter.
  • I wouldn’t want to put this project through a code review! But it does the job for this assignment.

 

Critters Sketch in Processing

If your browser is up to scratch, here’s a little JavaScript based sketch from a current personal project…


This is some early code for a simple game I’m working on for the Coursera Creative Programming course (it’s my first time building a game rather than regular software).

These shapes are generated from a limited range of numbers, which can later be turned into a simple genetic code to define these critters.

I’ve hosted this on OpenProcessing.org, so you can get to the source-code etc.

http://www.openprocessing.org/sketch/103410