Tag: game design

Quick project: Tetris

Occasionally I start Googling random collections of words related to video games — more usually, video game jobs, hoping some golden ticket is going to fall right out of Mountain View or something. I often end up reading lots of forum threads and blog posts about the topic and how to make yourself seem attractive to studios etc etc, and it was within one of these little quests that I read an idea that nagged me, “Just make something … Tetris or something, just show you know what you’re doing.”

So a few days later I got up and made Tetris.

 

dev3dev4
 

All told it was maybe 6-8 hours work split across two days: Mostly production, with the final couple of hours on day two dedicated to bug squashing. Anyway, it’s super simple but I think it’s kinda neat for what it is. As ever, this game is built with Haxe NME (3.5) – to compile the source you will also need the Actuate tween library installed. Download the source here.
Continue reading “Quick project: Tetris”

Hello again, today I bring you another lesson learnt.

When you choose Haxe for a project there are a wealth of 2D physics engines available, mostly ports of other popular engines, like Box2D. There are actually a few distinct ports to Haxe of various versions of B2D, but the most up-to-date and the one I’ve been using is Joshua Granick’s port of 2.1a. You can get it from Haxelib by opening a command prompt / terminal and running “haxelib install box2d”

In brief, it’s fantastic. Once you get a handle on how it works and where all the bits you want to use are it’s pretty simple, a far cry from the engine I initially experimented with – Physaxe – which was basically 20 pages of pure maths disguised as classes and functions! But there are some small issues I’ve run across while using it, and here comes the latest (and its solution, I wouldn’t leave you hanging!)

Continue reading “The intricacies of removing bodies in Box2D”

In my new tower defence project I need to know when certain things are touching, or when object A is within range of object B, and other nonsenses like that. It seems perverse now, but the first time I had to implement collision code a few years ago I didn’t know why the computer couldn’t TELL there was a collision: The blue circle is halfway-inside the red square, surely that’s obvious? But implement I did, and it was horrible and rough, but for that project it didn’t matter at all.

In the early days of this project I implemented a collision system again with just two shape types: Rectangle and circle. It worked well enough, but the performance was awful — I had time to knock together a few arrays and an update loop, but more advanced stuff like knowing which objects could be safely ignored to speed the whole process up takes time to write and test. Having experience with it previously, I ran back to Box2D, dropping the source in to my project so I could begin prodding.

Continue reading “Using Box2D as a collision system”

Pong project

Pong was a short project attempting to clean up my code base for Pinball, as well as rectify several nasty and hard-to-catch bugs who were only really present because Pinball was based directly on the first Haxe code I’d written which as you can guess, wasn’t totally solid. Eventually the need to rewrite a lot of my core code is what made me cease development on Pinball, although Pong did help resolve several issues. It was also built while Atari was running it’s Pong Indie Developer Challenge, so I wanted to experiment with some alternate game modes, hence the strange selection of gametypes on offer (multiball is still my favourite).

 


Continue reading “Pong project”

Pinball

Pinball was my first real project with NME, and influenced everything I’m doing with it now. It was very much an experimental project to gain understanding of how it all worked, and in retrospect, I wrote a lot of very heavy, slow code that was unnecessary.

 

lighting_05-02-12

Continue reading “Pinball”