next »

[Dacke]

Oh, it's Java! Omnomnom! Then I should have absolutely no problem running it, don't even worry about it. Send me a PM if you need help testing/running it on Linux or if you need some Java help

[DeadPixel]

@Dacke, I definitely will, thanks.

07/18/2012

Coding last night was intentionally light as I've had too many 2am - 2:30am coding sessions in the past week.  Glad that fire is back in my belly, but I don't like suffering so much at work in the morning.

I spent most of the time refactoring the trap-adding code from the night before, cleaning it up, making it more presentable and maintainable.  I abstracted out the control listener from the game state class and cleaned up how the ghostly currently selected trap gets rendered.

I rewrote the castle renderer itself to make use of libgdx's SpriteCache class.  It's a really useful thing that let's you create a cache of static images, turn them into a single quad, and then save that directly onto the GPU.  So instead of each frame re-rendering 'width * height * numLayers' worth of tiles (which with current max level sizes could be up to 7200 tiles) I only render 'numLayers' worth of cached tiles (which, at the moment, is 3).

My goal for the coming weekend, other than seeing the new Dark Knight movie, is to get each current trap's activation code in, and to design 2-3 basic levels that are actually meant to be playable.  That'll put me on a solid foundation of code that I can begin iterating on to make it fun.

[DeadPixel]

7/25/2012

Been a slow week in progress due to the Guild Wars 2 beta weekend, Batman, and some personal issues that had me beyond stressed out.  Anyway I got back to work tonight and made some steady progress.

I moved all entity creation to use LibGDX's static reflection pool methods.  This way everything throughout the game will be pooled and give me less GC headache.  Not a big change, but something I needed to handle before moving further.

I spent most of the night implementing trap activation logic, and completed the basic stuff for the Bullet Bob launcher, Fireballs (in lava pits), Thwamps, Spikers, and Pipe Monsters.  They don't interact with the heroes yet, nor do they respect their cooldown timers, but they animate and go through their respective state machines (pretty much) correctly.  I'll add in the flamethrower tomorrow, then get them interacting with the heroes, killing them, and their respective death animations in.

After that I'll design a few basic progression levels and begin the long grind of iterative improvements.

[DeadPixel]

7/30/2012

Spent the better part of the weekend refactoring large swaths of code.  This mostly came about as a result of realizing that LibGDX's Stage class wasn't going to offer me the fine grained control of my entities that I needed.  Mostly with draw order, but with other things as well.  It'll work fine for UI still, but I had to spend a lot of time re-implementing exisiting code to get back to where I already was.  So that's slightly annoying.  Growing pains of using a new lib, I guess.

Re-writing the existing code gave me the opportunity to ensure that I'm properly pooling commonly re-used objects as well, which is good.  I was a little messy previously, so being able to catch myself in an impromptu code review was helpful.

I also started on an implementation of hero waves.  Currently the spawner just spits out a number of random heroes at a set interval.  Now I can assign a collection of waves, each with their own unique composition of heroes, to each spawner.  The castle level will track the current wave number, and at the beginning of each will check the spawners to see if they have an associated wave ID.  If so, heroes from that spawner will being to generate.  This way I can have multiple spawn points throughout the castle each with their own unique compositions.  I just have to figure out the format I want to represent this as in Ogmo Editor.