THIS SITE HAS MOVED

http://blog.ncotsoftware.co.uk

This month I deviated from my usual “move things around and shoot at them” game style and tried a more strategic game.

So, this month’s game is a kind of stats driven battle type game. You’re a robot, there’s an opponent. Some stats happen and there’s a winner at the end. Then to make it less of a “press button, watch numbers change” game I added a way to earn “credits” that can be spent to upgrade or repair your robot, or to gamble on the outcome of the next battle. Maybe you’ll win lots of credits so you can win the battles better.

This is the first game I’ve made where there’s an actual flow to the game rather than “game starts and stuff happens randomly until someone dies”. So naturally, code like this sprouted out of my brain…

When your code starts to look like this… YOU’RE DOING IT WRONG.

and yeah… got a bit complicated to deal with. If the player is fighting and then they choose to give up, go into the flee state, but if they choose to upgrade then go into the OH MY GOD MY STATE DIAGRAM HAS A KNOT IN IT!

State diagrams might be useful, but not for everything. Certainly not complex game logic control. I finally settled on an idea that I nicked from Windows programming and created the concept of “game panels” that can be shown and hidden. Each panel does a specific thing – show some instructions, make the fighting work, create a new enemy, etc.

And after making this, it became quite easy to add some logic to make text fly in and out of the screen.

And you thought it was only good for making boring graphs…

Yeah… err this is sounding a bit like PowerPoint, isn’t it? So… how about some Excel? Handy for working out the maths behind the fight logic.

Probably could have written this game using MS Office and some macros

It was annoying me slightly that these games never end up as finished or polished as I’d like them to be – this one needs balancing and tidying up, last month’s needs a bit more depth… and so on. However instead of having a load of crappy half working games, what I’ve actually got is a load of prototypes that I can come back to later and improve upon.

Yes, these are prototypes. Instead of keeping half baked ideas in my head or a notebook they’re now playable things.

Oh, the game is here… http://www.ncotsoftware.co.uk/12/

This month’s theme is “the fair” and maybe I’ll remember to write something about it at the end of this month.

Oops, I finished early. Is that bad?

If you like it, or if you don’t, feel free to bother me on Twitter.

It’s a short month, and in that short month I think I’ve achieved a fair amount. Originally, inspired by the #1GAM theme of “loops” I was going to do some sort of Roller Derby game that had multiple AI characters, potentially two players and sounded quite fun in my head. Meanwhile all the kids at school started going crazy over some crappy little game with a bird in it. Silly crappy one-button games, they’re not real games are they? You can bodge one of those together in two days surely?

Then the Internet went crazy, like it does. The poor developer behind it went crazy and removed Flappy Bird from the world. And in the strange way the Internet works, someone decided “let’s make a game jam and encourage people to make Flappy Bird inspired games”.

Last month my game was an entry for the CandyJam  and it was quite fun and amusing creating something with a certain theme and purpose. I wonder if someone’ll make another up next month. I like the focus, it stops me fiddling away making a load of crap. So I stopped my complicated sounding game and thought “let’s see how easy it is to make a Flappy Bird type game”.

It’s not hard making a functional game – I had “bouncy squares avoiding other squares” working in an afternoon, but making it look worth playing is really tricky. Think I need to work on that some more.

I’m not just having fun mashing out simplistic games that I could complete in a day if this were a real job, I’m also trying to improve my general development system and its tools. My half-working projects last year let me learn HaxeFlixel and from that I created a nice little project template. Last month I worked on creating all the “stuff” that surrounds the main game – menus, fading screen effects, bleepy noises when you select menu items and so on. This month I expanded by resurrecting my Mac Mini and seeing if code worked properly on that too.

And then I went through some very specific and time consuming hoops figuring out how to put something on the OUYA store. It’s a simple sounding process that ends up with you trawling Google for an hour trying to work out why your large app icon isn’t working and why your game is called “com.example.myApp” instead of something more sensible. I think I might add some touchscreen code and see if I can put this on the Google Play Store too. I’m sure I’ll waste a day trying to figure out how to do that.

Next month all this effort will become part of the dev process and won’t take half a day to complete. I like this part of doing #1gam – repeatedly practising the whole process of creating a working game and becoming better at it. This month, because of what I did in January, I spent much more time on the actual gameplay than on the code.

What’s this? Software released on time? An entire playable game finished within one month? What kind of crazy world are we living in?

Yes, I am also equally amazed I managed to finish this inside the allocated time.

How did I get from this…

From this…

To this?

Yes, yes I can!

In just 31 days, without using a 3D engine… actually… how did I manage to force a 2D rendering system to draw 3D? That sounds like a more interesting topic.

Worried you’re working for too long without a break? Get a cat…

You see, I’m using a pretty good programming language called Haxe which has the benefit of being cross-platform. Added to this is a 2D game library called HaxeFlixel (yes, it’s that Flixel) which makes creating 2D games easy. Everything is represented by squares and rectangles and the built in collision detection is efficient and easy to use.

So along I come and think “3D game!”.

It’s kind of hard trying to draw 3D when your basic graphical shape is a 2D square – you can set the width, height and a position on the screen. There are no line drawing routines, no shape drawing commands. You can just put squares on the screen. The squares can contain images though, and can be any rectangular shape you like.

You can also scale them, which is the trick. The Internet is littered with examples of how to quickly convert and project a 3D point into 2D. My notes are now littered with scribble, food stains and cat-prints explaining how to butcher rectangles so they scale cleverly to look as if they’re moving within a 3D volume.

Something is very wrong here…

The striped grass was difficult. It’s a “wide enough” one pixel tall rectangle that is then scaled in the Y axis. The amount it is scaled is calculated from a 3D point describing where the “bottom” of the stripe needs to be. They all then “slide forwards” as if on a conveyor belt to create a convincing motion effect.

Collision detection was an utter nightmare (and still is… that’s why nothing can shoot at you – it doesn’t work!). I tried all sorts of crazy 3D collision routines – they all either didn’t work, or were too unreliable to make a fun game. In the end I settled for a total hack which went like this

If objectA's Z position is "close enough" to objectB's Z position
    Do a 2D overlap test on their scaled images
        If they overlap, they're probably touching so deal with it

It’s so … dirty but it works well enough. Finding sprites took too much time – I wasted a good few hours on that. I found lots of ripped sprites from Space Harrier, Outrun and other fake-3D games. They showed me a bit of insight – my code is probably a horrible hacked idea but the real games probably are too. The Space Harrier sprites – for example – are not scaled as they move towards the screen. There’s just different sized ones that get drawn appropriately. Space Harrier’s collision is also not that tight and because you’re looking at the player’s arse all game it’s impossible to aim properly.

It all looks like this…

I couldn’t manage floor shadows though, I don’t have enough control of the screen to force those out, so judging your relation to things is difficult (another reason why your player doesn’t actually collide with stuff).

My game is awesome, you should go and visit its webpage and download the thing. Grab an XBox controller and shoot at stuff!

So, 20 days into January and only 11 left before the first #1gam entry is due how am I doing?

I started my #1gam entry with the simple idea of “Make DotShooter, but a bit better” but decided that creating a basic 2D shooter wasn’t really pushing my ability to make a game. Creating “Dotshooter version 2” isn’t the reason I’m in this, I’m taking part in the One Game a Month competition to try and improve my ability to make games… and I think I’ll impose a new rule – games that aren’t simple 2D shooters.

I’m working on what appears to have become called “Space Harriet” (why?) which started off as an attempt at making an old ZX Spectrum game called Glass. Faking 3D is not as difficult as it seems (and it seems quite easy compared to teaching yourself OpenGL) and after a week or so of trying things I produced a rudimentary 3D effect

People immediately started saying it looked a bit like Sega’s Space Harrier, so I’ve kind of gone from there.

I’m not trying to make anything too fantastic – it took over a week of messing around to get the collision detection working so I’ve only got time left to add some enemies to shoot at and tidy up the user-interface, etc. No doubt I’ll come across some more bugs that absorb too much time.

I have a simple plan though – every day I at least do something. Yesterday I fixed collision detection, the day before I sorted out a small but irritating problem with the game not always being full-screen when you load it up. There’s always something to do. Some days I’ll be able to spend hours adding massive chunks of functionality to the game, other nights I’ll be incapable of creating a line of sane code but drawing a few terrible looking sprites is mindless enough to be doable. Today I’ve not had much time so I’m writing this.

Once the game is done I’ll do a small write-up about how it works. There’s some fun parts where I take a 2D game engine – HaxeFlixel – and carefully abuse it so I can draw “3D”. HaxeFlixel is a modern 2D game engine so really its underlying graphics routines create textured 2D shapes that are sent off to OpenGL for drawing. I love the idea that I’m making a 3D game in a 2D engine that itself uses 3D for drawing. Especially when you realise HaxeFlixel can only draw rectangular shapes and your only manipulations are to move them about the screen or scale them. It has similar feeling limits that the Sega Mastersystem version of SpaceHarrier clearly has.

Limits are good, they force you to be creative and to take shortcuts because the end is more important than the means. Bit like the competition itself.

(maths came from http://codeincomplete.com/posts/2012/6/23/javascript_racer_v1_straight/ )

Let’s look back at the last year and see what I did. Did I manage to meet those two simple goals from 2012’s review?

No. Did I balls. Sold my iPad and bought a Nexus 7 instead though, then work gave me an iPad which I kept for about two months before giving back. Then I bought a Windows 8 tablet and a PS Vita. Some of my friends seemed to have fun doing that One Game A Month competition.

• Mr Beerman created some fun games
• As did Jayenkai
• And Andy from TCKSoft has managed to consistently create 12 new games this year

So after battling away with my game for a few months and moving house in February, and then spending most of March unpacking I decided “bugger it, I want to have fun too”. I’m doing this gamedev stuff for fun, and spending hours working away on the same game for over a year doesn’t feel like fun. It feels like a job. That I’m not being paid for.

Bugger that, you’re daft if you’re going to waste years of your life on one single game that will be forgotten about after a week. Especially when you’re making it on iOS and have to play the tedious “Pay Apple £60 and constantly update XCode to support devices you don’t own and can’t afford” game.

No, sod that, the #1gam thing looks fun. One game, every month, short, simple… make things, stop farting around half-making things.

That’s what I’m doing this year. Last year I decided I wanted to find a simple, easy to use SDK of some sort that let me make games not tied to any particular device or operating system. I don’t want to be throwing away months of experience just because Apple, Google or whoever decide “Yeah, that thing you use? We’re upgrading it to version 6.66 and you need to buy some more hardware because yours isn’t good enough”.

So first I found Monkey which was the start of HTML 5 becoming good enough to make games in, and also the start of cross-platform dev environments. It was good, but the free version was limited to HTML 5 output only. Then I found a thing called NME that later turned into a thing called OpenFL (which Google consistently tries to correct to “OpenGL”). I also found the Flash game engine Flixel had been ported to it, resulting in the wonderful blend known as HaxeFlixel. And it’s really good.

So I set about learning how to use it. I didn’t manage 12 games in a year, but I did manage a good double-handful of games, game ideas and things-that-got-out-of-control. Enough that if you go to my other website I actually have something to show for my efforts beyond a load of screenshots of the same thing.

So, this year’s aim?

Bonus points for making some of them good enough to be worth selling, even if all I make is 99p.

Can I do it? Who knows… we’ll see in 365 days time.

(PS: The date is a lie, it’s really the 20th of December, 19:50 and I’ve just finished work for two weeks)

This month’s 1Gam theme is “change”. I’m not currently taking part in that competition, but I’ll borrow their theme all the same

So there I was, merrily making some sort of shooter game, getting lots of exciting code written that lets me script enemy movements and AI without having to write loads of code. This ended up with me inventing my own mini scripting language, which was interesting, time consuming and quite fun.

Something wasn’t right though. I don’t think I want to make a shooter game, they get a bit samey after a few minutes of playing. There’s no surprises. Enemies move down the screen, you shoot them and try not to die – it’s a fairly well used pattern that’s worked for over 30 years. Nothing leaps out at you and makes the player go “argh!”, it’s like the appeal is the sameyness.

Then, on the way to work this morning, after discovering this little bastard had appeared on the Google Play Store I had an idea.

My game doesn’t like you very much…

In fact it positively hates you… It wants you to lose and quit playing…

So far I’ve figured out 8 fun ways to really piss you off when playing. This is a short taster of the first idea

Click here to view the embedded video.

After all, the point of playing a game against the computer is to beat the game. If I can make you quit in frustration, then the game has won