So, got married, moved house, started an EPIC BIG GAME ™ (http://www.legendsoffore.com) and then realised I don’t have time at the moment to do it justice (of course I’ll be doing it). So I’m building a little game to test a bunch of stuff for the big game!

To the topic of the post, I’m building a game with levels, and monsters and all that good stuff, but a problem I always have is determining whats “hard enough” (fnarr). Balancing levels is always difficult especially when you’re appealing to wide range of players – if only there was a way to statistically define the difficulty of of a level?

For once, this time, I’ve designed my AI suitably generically – ok I didn’t mean to but I just spent a bit more time on it than before. The side effect is that the AI is smart enough to play for the monsters OR the players. So the first thing I did was make the game play itself. Brilliant to watch and found me a tonne of bugs straight away.

That was good, but then what – I mean I don’t want to take ages getting out the difficulty information and can’t really tell anything without a lot of runs.

Next step, make it run “headless” (for those who don’t know, that means without a display). Unfortunately a bunch of the data code I’m using from LibGDX actually depends on OpenGL (i.e. Tiled Map support). So – how to make LibGDX work in headless mode. First:

Yes, I could have had the “headless backend” but its an awful lot to bring it for this.

So, now Gdx is initialised by whats MockGL20? I thought I’d have to bring in a Mocking library (like Mockito) but turns out all I needed to do was have Eclipse generate an empty shell implementing the GL20 interface. Boom! It’s done.

Now I can run a complete quest at top speed having it playing itself and evaluate the outcome. The output looks like this:

Excellent, I can now determine the first level is pretty easy – 100% wins from the player AI. Note thought that most of the time one of the heroes died – so not quite simple!

Hopefully this will help to balance out the levels and get their difficulty just right. Of course player feedback will help tune my understanding of the statistics coming out – assuming you guys play it!

Last friday, I got married, to the wonderful Kayla! She’s so awesome and the day was absolutely incredible. Sorry for interrupting the game development flow (which will now start to be more regular) but I’m so terribly in love with my new wife! (yes, soppy, once in a while)

I get a few emails each month asking me about what process I took to get “so good” at coding. It’s really appreciated but doesn’t really make sense if you take a look at my code.

Here’s today’s response:

Dude, Mr Glass is my father, I’m Kev

I’m really not that skilled at coding, I’ve just been doing it a long time. Like you I started young (I was about 5) and now I’m 37. So I’ve been coding about 30 years. It’s mostly about the amount of time you spend doing it, but it’s not a short process at all.

A few things I’ve found over the years:

1) Morale – theres only one way to keep going, because you enjoy it. If you don’t stop. If you do, you’ll keep going rain or shine.

2) English – make sure your english is good, having a good vocabulary and knowing how to abuse the language makes coding easier. It also makes it easier to read later.

3) Technology – pick one and stick with it. There’s always another technology coming out and by all means play and learn – but take the decision to change your main technology very very seriously.

4) Learn by doing – don’t be afraid to swap projects, to experiment to learn. The fastest and best way to learn anything is to sit there and “just do it”.

5) Respect – always respect everyone you interact with. There are many many bright people out there that will help you if you ask nicely. Don’t expect them to, and don’t get mad if they don’t, but you’ll get much further faster if you keep respecting everyone.

6) Life – don’t let code be the only thing in your life. Without all the other things going on you don’t get stimulated for innovation. You need to expose your mind to other things in the world to be able to see where technology fits in.

Just very very very busy with day to day things. Legends 2 is ticking along but as always I got obsessed with a smaller game that I might have a chance of implementing with my spare time at the moment.

So I guess it’s official, I’m starting to work on Legends of Yore 2 – which I’m subtitling Rise of the Darklings. I’ll post some concept shots etc in a minute but I’d like to talk about the process I’ve been taking during the interim for a minute.

As you’ve seen if you read my blog or follow on twitter I’ve been knocking out lots of little game demos, this is how I work. I try stuff, lots of stuff, over and over again until I feel comfortable I’ve got everything down. In this case the projects were:

Voxel Based Engine – Experimenting with different graphical styles

Carubloc – Looking at LibGDX across platforms

Matchnik – To look a procedural puzzle generation

Turn Based Platformer – To look at turn based mechanics with a bit more action

Mega Melon Adventure – To play with gamepads and the OUYA

Sub-pixel Sprite Animation – Obviously more tailored towards Legends, just needed to find a way to generate enough graphics.

There’s actually been a few others that never saw the light of day, including a very random bouncing game. This is I’ve come to understand my process. I experiment a lot before I actually go anywhere. It’s not intentional but I can see the pattern looking back. I’m hoping this is going to make Legends of Yore 2 a better game.

So, enough waffle, Legends of Yore 2 – so far I’m coding and spriting like crazy. Here’s the concept art that I’m currently working for. This time it’s all my own art – I intend to license some music/sounds but everything else should be from me:

The plan for the game is do something similar to last time while fixing as many of the things that I learnt along the way. So the game is intended to be epic in size and scope – hopefully bigger than last time. Things I liked last time:

No level cap – keep going as long as you like

Yore – the world, it’ll be set here again though maybe many years on

Diversity – the varied landscape and characters

Procedural – the dungeons kept changing but the world above was the same. People seemed to love that

Items/Armor/Weapons – a huge wealth of things to collect and apply

Class upgrades – this was a late add but once that I absolutely loved.

The Second Stat – Wizards got Health and Mana as always, but why couldn’t Warriors and Archers have something special too – Rage and Zen were added. Very neat (thanks to PuppyGames for the original thought on this)

So there were a bunch of things that I did last time but I want to be better this time:

Magic – last time it was too hap hazard, designing a spells tree with different schools of magic before we get started.

Skills – as with magic, way to random. Again skill tree designed before hand this time.

Pets – I always felt like they could have been so much more. I was losing steam with the game when I added them so they came out partially done. Fix them this time.

Quests – I liked the quests system in Legends, it added a lot. This time I want quests to be richer and more varied.

Save Games – they will be keyed against an email you provide. Last time it was just too half assed. This time it’s going to be cleanly done with a web portal to support your character.

So, I love pixelly graphics. It’s pretty obvious from my games that not only is it the only thing I can draw it’s also the main thing I like to use. I always scale them up 3 or 4 times and get that big clunky retro feel.

However, I’ve never really been happy with the movement in the sprites – specially how long it takes me to do animations. I was looking at Cube World and thinking about the difference in resolution of the character voxels to the rest of the world. Just because you’re working in a theme doesn’t mean you can’t bend it to suit what you want!!!

At that point I’m starting to think above my pixel creations, what if I applied the same logic there. When I scale up my sprites each pixel has 3×3 actual pixels so in the animation there’s room to move parts of the sprite at a higher resolution – neato! Hmm, but how to do I allow myself one resolution for animation and one resolution for pixels? (I want to clamp myself to the right retro feel). Skeletal Animation!

So I rapidly take my existing sprites, rip them into separate limbs and body parts and re-spritesheet them up. A little bit of coding later and I have a skeletal model that allows me to rig them all together!

So now I’m back to my original sprites only with them being built out of smaller pieces. That in itself is awesome since it means I can create lots of variations for a game I’m planning on writing shortly.

Next, what about animation? Once the links between bones are defined and the skins attached all I need to do is apply transforms. Excellent! I can even rotate tiny pixelly weapons to give nice stylistic effects! Me being me, the next think I do is build a Java Swing based tool to support test out different configurations and animations:

So, having defined animations against the bones, I try out a few skin combinations and what do I end up with? Well, awesomeness thats what!

Here’s some tips if you want to write a Java API thats really hard work to use. Doubly so if you want to hit it with the “object oriented for evar!” ugly stick.

Hide everything! – even the stuff that doesn’t make sense and is guaranteed to be there. Make the user jump through as many levels of indirection as possible to access anything.

Require Casts! – make sure you use has to cast everything from an interface to a real class before they can do anything. Double points for not making it guaranteed that the objects you’re casting will always be what you’re casting them to.

Make everything an interface! – always always make everything an interface. Ideally a hierarchy of interfaces that don’t add more than one or two features at each level. Especially good for misleading your user.

Wrap everything! – related to 3, make sure you’ve wrapped even the simplest of data types in an object – thats always good for memory consumption and is extra effective if you use non-standard naming.

Runtime Analysis! – while it’s important to wrap anything and everything in an object, don’t make fields visible. Ideally put them in a generic map even at the lowest most specific level of your ornate object tree. Thats reusable and meta right? Make sure the user has to either read the source or use a debugger to determine what the fields are called.

More code is better! – make sure your user has to write as much code as possible even for the most common use cases. The more code they have to write the more they’ll appreciate the beauty of your API.

We all love object structures and we all love “beautiful” code. However when you’re writing an API it’s about matching the use cases and make the developer productive. Please don’t make them jump through hoops for the sake of your “elegance”.

Another game experiment starting with me wanting to try out turn based platformers. Could you write a game that was platform based but had the turn based nature of Legends of Yore. So I set to work:

The other thing that I wanted to try out was procedural generation for platformer levels – this turns out to be reasonable to implement once you represent everything as a graph. The significant difference between platform generation and dungeon generation is that links between nodes/rooms/platforms aren’t always bi-directional – i.e. you can fall from a platform to another but that doesn’t guarantee you can jump back up. I’ll probably write a blog entry about that later.

Anyway, heres the current state as a web based games (required WebGL), infinite exploration – not much gameplay at the moment:

I’ve started a little indie game review site over at Mash the Pad. The intention is to review games from a developer/cynic point of view and keep things honest and constructive. If you have any games you’d like to get reviewed or previewed just send a contact over from the site.

So, still waiting on my OUYA but decided to improve the instructions on using a MOGA game pad in Legends of Yore. You can now get an image depicting controls for both types of pad by pushing the MOGA labelled button in the game.