Sticky Knight - Development Diary 1

Saturday March 22 2014 - projects

Recycling code to make a new project.

My current main project Gunnihilation is quite some way along and it's hard to talk about what exactly is going on with it, since at this point it's building levels and fixing bugs. I started Gunnihilation (then just called Run N Gun) way back in late 2012 as an experiment in creating a platformer using Box2D, bringing over the blitting engine from my previous project 'Spike':

Spike was a rather dull and confusing shooter, however the code had some nice fundamentals:
> A fairly fast blitting engine supporting bitmap rotation and tile maps.
> A graphical effects system using simple recycled objects for speed.
> An xml based level loader for saving tilemaps and entities.
> The editor for creating the level xml.

I'd never used a physics library (or indeed any other library apart from built in flash functionality) before. But as it turns out, Run N Gun was a lot more fun, so work continued on it, on and off. I've since learnt a lot more, certainly about structure. With subsequent additions and refactoring Gunnihilations codebase is a bit of a mess, but the game has so far been stable and runs well. Bits of it's code are useful, but on the whole the structure is a mess and I know I could do far better.

So I've decided as a side project to create a new, smaller game, to create a brand new framework to build more of the ideas I have for prototypes. I also thought it would be an interesting exercise to document it's progress, since it involves creating two code bases: The library, designed to be generic for future use, and the concrete implementation of it in the game itself. I've decided to call it the Damp framework, because why not.

For now at least the game is called 'Sticky Knight', as the main mechanic is sticking to walls. I was going to call it Sticky Ninja, but we've got plenty of Ninjas at this point. I built a very primitive prototype of the concept sometime ago, and it looks like it'll be fun to revisit.

The game will continue to use Box2D, and I'm also going to use the Genome2D graphics library. Using Genome2D means that my previous Blitting code isn't very useful, and despite using Box2D, the system will still contain some of my own collision code for basic box, line and point tests used in graphical effects.

Ideally the framework will not require Box2D, and would be designed to work with other collision systems, but we shall.

How the library looks right now:

com.dampdogdev.app
DApp
DComponent
DComponentSet
DTick

com.dampdogdev.b2
b2TestMap.xml
DB2Factory
DB2Hitscan
DB2WorldLoader
DBox2DMaths
RayHitList
RayHitEvent

com.dampdogdev.data
DArrayInt2D
DDataPool
DEmbed
DPlaceholders
DSelectBitmap
DSelectTileCache
DSelectXML
DXML

com.dampdogdev.debug
DDebug

com.dampdogdev.display.g2d
DGDisplay
DGQuickDrawObj

com.dampdogdev.input
DInput
DKeyboard
DMouse

com.dampdogdev.maths
DAABB
DLineSeg
DMaths
DPseudoRandom
DVec2D

com.dampdogdev.services
DB2World

com.dampdogdev.state
DState
DSubState
IDState
StateManager

Blame Zqf only for this website