Short post on progress things. Things have just been lots of grunt work and non pretty things.
Will have things to show real soon.
basic player object ..er.. exists and rotates properly.. mostly. need to knock out some better test sprites and stuff to be able to make things actually ‘work’ together, but the fundamental concept of 8 direction independently moving head, torso, arms, lowerbody seems to work and will look pretty cool.
monster entities can be spawned and basically kept track of.. no AI or whatnot but still it’s a start.
Implemented basic box2d physics for player and monsters. this will have all sorts of fun payoff later I hope. Force waves, shapnel etc 🙂
Got the macro tiles wired for a* pathfinding.
Got the World generating a Maze and then replacing it with matching macrotiles that randomly match the exits of the cell.
started on map rendering
camera instance screen objects so I can have a smooth moving controllable camera that chases the player.
See.. lots of neat stuff… however nothing that you can actually look at other than a bunch of diagnostic log output.
Performance wise it seems to be running at ~240 fps on the low end test machine and ~somewhere over 3,000 fps on the new machine.
So I might need to add in a ‘laptop’ mode which disables the whiz bang pretty stuff I hope to get put in.
So, basic progress is in swing. There’s a bunch of stuff I can port over from the GarageGames Torque Game Builder version that I was working on, however, there are a bunch of things that I didn’t need then or just do not have access to in Java or just don’t integrate with Slick very well. So with that in mind.. I’ve been digging into Pre-Pre-Production.
To that end I’ve stated building a toolbox. Figuratively, of course. Here’s a few of the silly things that are a pain to write but very useful to have.
AssetLoader – based on the slick tutorial this little thing lets me have a loading bar on a title screen while the game loads every asset it needs.
OptionsController – manage loading and saving user settings and profiles for resolution, sound, and player name.
InternetFile / InternetString – for pulling a string (current version) or file (updated assets) This makes keeping the user informed of latest news/ updated versions a snap. Since Minecraft came out with an auto updater, it’s been glaringly obvious that at minimum having a latest version check is a MUST Have feature.
Movement Library – a pile of functions to take two points, and interpolate between them,given a method speed and time elapsed and whatever else that comes up. I expect this to grow for some time.
ImageCounter widget – display a number with a series of images. Like hearts in zelda. Supports horizontal and vertical orientation, whole and partial increments etc.
Basic Image Button – yup it’s a simple little button made out of a bunch of images, it’s self contained and easy to use and change.
State Based Button – also called a modal button. Essentially displays several options on a button bar and you can select one.
Text Block – an angelfont based text block widget , hand it a block of text, an AngelFont, and give it a max size. It auto animates the display, pagination etc.
Text Entry – an angelfont text entry widget. easy and simple..
and as I find things that would be handy in future projects I’m adding them to it.
So it turns out that making little widgets is actually really kind of fun. Much like building the IrisEdit level builder tool that I’m using to build the levels.
And with those tools in hand, I’ve created the game Launcher / Version Checker, Here’s what it looks like without the Launch Game button (it goes in the middle)
Whoo.. what a week.. not very much dev time, unfortunately.
I’m beat so I’m going to keep it to a short what got done list.. followed by a screenshot..
Bolt splitters are in and work.. (except for the rotation is a bit wonky)
the Level editor and Level group editors are almost done
The core applet is almost ready to parse all data from external sources.
Tweaks to some particles.
all the Elemental nodes now are renderable in-game and have their proper graphics.
Here’s a screenshot of where things are.
And here’s the list of priorites for the week:
All the ajaxy and facebook <–> applet communications need to get wrapped up asap.
Player object for storing scores
back to level select button
more particle effects
and so much more!!! Yikes!
At this point I’m getting pretty nervous weather or not I’ll even make it to complete by the contest end. Its looking like Some things are going to have to wait to be finished afterward.. Yeesh.. well. hopefully the baby will cooperate and I’ll be able to get stuff done in the evenings this next week or two.. cross yer fingers.
A couple of days late but much the wiser 🙂
Gameplay is now functional.. in that.. you can start a level and win it.
Here’a quick rundown of some of the new features.
The most important (that you cant see) is the new background simulation of the gameplay. This ensures that bolts and enchantments are registered properly.. even if the framerate goes to hell.
Items are now fully enchantable. They have a start and end state with misc metadata for use later on down the line.
The formula track represents the bolts needed to enchant properly.
We have a speed selector, this was a nice ‘free’ bonus of separating out the logic from the display.
Levels have names, a constructor and can be passed from state to state.
We have a text writer with a nice font.
Oh yeah more final artwork is falling into place.
splitters. gotta stop pushing that off.
sound for bolts when they hit enchantable object. and to add a playback button on the formula. So you can hear the CADENCE of the ENCHANTABLE item.. get it? I thought this stuff through eh? That and it makes troubleshooting your placement easier.
The toolbox area needs graphics.
The dialogs need graphics.
placeables need graphics.
particles need gra… well you get the drift.
oh yeah.. more levels.
Wish I could take a week sabbatical to do nothing but this.. but for now a couple hours here and there is all I’ve got.
We’re halfway through the contest… and I’ve just now got the essentials done.. Looks like there may be some long nights ahead.
Good week! Lots of nerdy stuff fixed and resolved. Here’s the picture and more details in extremely nerdy speak below.
The biggest things that got done this week are :
More per puzzle gameboard abstraction, so now the gameboard knows what things are where on the board, this made implementing a board rendering based on the Y coordinates a snap, so things now appear in front of the things they need to.
The beginnings of a more robust image/particle manager system.
A passable Level Manifest. A game Level can now be passed between the different Game States and (eventually) populated from the database via JSON jquery calls.
The biggest problem that popped up has definatly been the particle systems. The slick ParticleIO.load(xmlfile) works great locally however on a deployed Jar it really grinds things to a halt. This lead me down the path of trying .duplicate() on a set of master particles.. to no avail.. I also tried just loading them all at startup into a great big MagicBoltBucket… that worked but the applet startup went to ~2min …
What I’m winding up doing (still in the process of) is a) have an image manager that loads all the images needed ONE time at init and passes them out as needed. b) a great big bucket of pre-made Magic bolts that I can take and put from. c) Create all the particle emitters programatically.
Not entirely done with that, but the intial tests have the Initial filling of the BoltBucket down to about 2 seconds for 120 bolts. Eventually There’ll be about 400 bolts in the bucket at level init.
So I guess that’s that. Now I’ve got a pile of consulting work to get wrapped up by contest start of the 15th so that should work out just fine. But I’ve gone ahead and started thinking and planning a bit last night, which is what the paper prototype is all about.
I have a couple family things to do this weekend but other than that it’s crank out website goodness 🙂 Pretty proud of it actually..