Whoa.. after what feels like an absolutely morale crushing infernal heat wave that has more or less sapped all willpower for the last several months… it’s time to get the show back on the road.
Here’s a peak at what’s been worked on. More details as soon as I get more gameplay things put in. And after a break to Javaland it’s back to good ol TGB. The upside is that things make so much more sense now. Many more thoughts on the matter later on.
Short post on progress things. Things have just been lots of grunt work and non pretty things.
Will have things to show real soon.
Honest.
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.
Assuming you’ve decided to build a 2d engine for a non side-scroller you quickly come face to face with one of the biggest decisions you’ve had to make so far. How are you going to represent the game world? Basically there’s two choices each with their own benefits and issues. There’s the ‘Walls are a block’ approach where everything is a block and the ‘Walls are an attribute’ approach where walls are things that are part of a tile and appear on the edge of a tile. Here’s a little Pro/Con info that I jotted down while deciding on which way to go for BSDDoD.
Example: minecraft, zelda This is probably the most obvious approach to building a 2d world. Everything about the world construction is handled in a simple array of blocks letting you quickly build a map.
It’s essentially a lardge 2d array that contains the structure of the world. With each location in the world represented by a number. For pathfinding you can easily implement floodfill tests and even weighting the passability of tiles is pretty trivial.
They’re easy to implement and fairly lightweight, make a whole bunch of visibility / raycasting real easy and fast.
Aesthetically they’re not as nice/real looking as what can be achieved with thin walls. Destructible walls are more unrealistic and the wall type is determined by the block that is the wall. So if you want blocks with different wall textures you have to create and track many more entities. Windows are pretty much out of the question and doors tend to look a bit odd.
Example: X-com, project Zomboid, old Gold box D&D games, the Sims
Every game tile has 4 flags associated with it used for indicating if there’s a wall. This means that there’s a bit of extra overhead but it comes at some interesting benefits.
Aesthetically having walls look like walls is a big bonus. Also the ability to do things like have windows, half height walls, one way doors and portals is nice too. Also the ability to have different textures for a wall regardless of whats in the neighboring tile is nice (but there’s workarounds for tile based maps for this as well).
Complexity. Pathfinding, line of sight and collision detection all become significantly more involved, not necessarily slower, just more complicated.
Well since I’ve got a bunch of the art assets already created for a straight on view, I eventually settled on the Block based walls with the Straight on view (right side of the image above). Really that was the deciding factor. The straight on Blocks as an Attribute would just wind up looking odd and I have no need for windows or doors since it’s essentially an arena based shooter.
For the next project I’m leaning toward an isometric Block based map, however with blocks being smaller than the characters, so that will give thinner walls and hopefully a more enjoyable dungeon building experience… but that’s still way off in the distance, percolating on the back burner.
Well… lots of stuff really.
I managed to turn a paper prototype into a fully functional game in two months. Overall, game play grew and changed organically through the development process as low hanging fruit features were revealed. Taking a project from A-Z in Slick was very educational (which was the primary reason for the whole thing).
The facebook integration worked (albeit their documentation leaves something to be desired) for the most part seamlessly.
The back-end level creation and management web tools worked and the general process of back and forth data between the webpage and applet worked as anticipated..
The multi threaded stuff to send and catch javascript communications works and once the basic process was understood was easy to implement.
Graphics and Music. Visually the game managed to capture the look and feel that I wanted. I was able to work out an efficient workflow to take concept /programmy placeholder art and iterate it to the final art. No assets were lost and not a lot of dead ends or un-used art was created. Overall the music worked nicely as well.
It was a nice first version, however not something I’d call mainstream release ready yet.
The first three weeks were spent having the enchantment process be based off of what visually was happening on the board, this caused massive issues as framerates turned out to be really unsteady once the game was in an applet form. The fix was to have a logical representation of the game board where the simulation was run and then just have the rendering update it’s assets from the virtual model.
It turned out that applets have a massive overhead when instantiating any sprite as they check the applet’s remote filesystem path for the files. This lead to the implementation of a boltManager object which pre-creates 500 bolts and tosses them to the game logic as needed and returns them to the source pool when taken off the board. This fixed the issue .. until I added particles.
Particle systems create an image loading hiccup as above even if it’s pre-created on their first .render call. The fix was to change the applet call to isolate the applet from the webpage with <param name=”codebase_lookup” value=”false”> .. The downside is.. this effectively killed the idea of loading level specific assets from the website.. so suddenly everything needed to be included in the jar file.
Java <–> Javascript communications are paaainfully slow.
Gameplay wise, it reaaaally needs a tutorial level, ease of use features, and a better dialog box system.
Level design really did not lend itself to the whole 1-3 stars for each level completion. Usually there was just ONE solution.
Not enough time to build good levels. By the time I’d gotten enough features to behave stably enough, I had to cut several features and wound up with still only a week and a half to build all the 10 levels. (remember there’s a fulltime job, consulting work and family with baby who all come first) As a result several of the levels are pretty shoddy.
Applet communications don’t work in Safari on mac, and the game rendering doesn’t work in other browser on mac (but the communications do)
The primary reason for making this was essentially a way to motivate myself to finish a project and learn a crash course in SLICK and java. In this sense, this was a roaring success.
Perhaps it was a bit much to take on as my first real Java application… naaah.. just because I spent 2 days wondering why my string comparisons never worked. (even went as far as building enums and value catalogs to avoid having to compare strings) … then I discovered ‘string1.equals(string2)’ … sigh..
Applets are too restrictive to be viable. Pretty much every benefit of having a web program work in java (other than the openGL) is overshadowed by a downside. Heck just getting it up on the user’s screen means they’ve clicked through several very scary warning prompts. And if you want to do any kind of network communications behind the scenes (bypassing javascript comms) means asking people to punch holes in their firewall rules. All of which make applets un-usable for general mass consumption. JNLP’s seem better but they’re not very user friendly.. (they don’t ask you where you want to install.. let you know you need to un-install etc..)
In the future I’m leaning towards wrapped jars into exe files for Slick and java applications.
Thank goodness this was a 2 month test project, eh?
SLICK is a lovely codebase and java really is a dream to work with. Any concerns I had about java being slow or whatnot really have been blown away. If I un-meter Enchanting Cadence it easily runs at several thousand FPS. Actually it runs so fast that the math behind the simulation can’t measure the time between cycles correctly and it all falls apart. (that’s pretty cool)
The SLICK community and the java-gaming.org guys are really helpful and there is a wealth of tutorials and training out there.
Full on crunch mode.
Progress was excellent this weekend and the core gameplay , saving scores, dialogs and all the ajaxy interactions are working. Bugs… however… bugs and edge cases abound..
Other than that, I’ve got a pile of assets to generate.
Add to that a bunch of actual gameplay tweaks.. It’s a bit too hard… and way too hard to determine what went wrong when you mess up the formula. I’m still not sure how to fix that yet…
Well Friday the 15th was the halfway mark in the Slick contest.
I was hoping to have a glorious screenshot bonanza after a few more hours of work showing the completion of the core mechanics. I’m that close to having the functional workings of the gameplay.
Then mother nature decided to throw a hissy fit and bounce the power to the house 20-30 times in about an hour. This, it turns out, is bad for hard drives. The surge protector did its job and the only damage was an irretrievably messed up FAT table on the primary drive.
So, time to re-install Vista… followed by 2 days of patching and re-installing applications and now I’m basically back to where I was before..
On the upside, it was a wonderful weekend of just chilling with the family and going to bed early, and I know for sure now that my Backups are working.
So here’s the short list of things for basic feature completeness:
Time for a little progress update, eh?
Ok so some more sheep have been done but it’s time to assess the situation and get a firm grasp of where exactly I stand. But first a picture of the prototype tuckbox that the game will be shipping with (some assembly required)
Why Include something as silly as a tuckbox, when it will surely impact the bottom line One might ask. Well the answer is simple, with the last couple playtests it’s become obvious that the system of green tokens to track the value of the current place is massively cumbersome. So I decided to put in a little track sheet that you can just put a couple counters on to track the value of the current place as it is eaten. And the price difference between a 4×4 board and a board big enough to have a tuckbox to be cut out is negligible. So the tuck box is almost free.
But anyway… back to the current state of the game development process. So it turns out that 85% of the time it’s taking is art. That’s right. It’s taking much much longer to draw silly sheep than it is to creating the game and the cards and exporting them and uploading them and writing / editing the rules etc. etc.
Crazy eh?
As of RIGHT NOW, I have Drawn and Painted 60 of 125 sheep. Of those 50 have been placed into their final art location in the inDesign files that are the decks.
I have 65 sheep left to Draw, ink, and paint. A happy estimate would be that if I totally buckle down I can probably do a sheep every 2 hours, maybe a bit more. So let’s call it 90 min. So that’s just a hair short of 100hrs of ART work left to do. Not too terribly bad.
Other than that I probably have 6 hours of editing and tweaking on the cards’ text to make sure they’re clear and are easier to understand.
Then toss in the other little things like re-writing the rules and finalizing the web and packaging art, realistically it’s probably closer to 120 hrs of work.
That’s some really long weekends in my immediate future if I’m to hit my goal of having it launched by my birthday.
Time to buckle up, it’s gonna be one helluva ride to see if I can do this.
Well, some development progress.
The in-game map now reflects a proper mow branching randomly generated maze based on Prim’s Algorithm, the trickiest bit was adapting it to do without proper arrays Toquescript is a bit funny about that. After that, I created a basic start for a tileset etc etc and got it rendering properly in the engine.
Tonight I got the tilesets to properly interpret the door and trigger tiles and render the proper animated tiles for them (after creating said animations of course). Spent a little time trying to figure out why shooting seems to crash the game on the tile based level but didn’t get much beyond making it not crash.. but not showing the shots either..
So that’s the next step, and after that activating the triggers and shutting the doors to indicate the start of a wave of enemies.
On the webby front, some minor tweaks galore to the theme with some more changes planned. Over the weekend I put up the site www.wenderflonia.com for GFW and she’s putting it to great use already.
Well the year sure went fast.
Been playing with some basic python and pygame stuff. Seems like a pretty easy to learn language and api, just havent gotten myself convinced for the need to learn yet another language… oh well Im sure I’ll think of something to use for an excuse.
But it probably wont be until Xmas. Letting the brain relax and just enjoying some neglected games and movies and such. blah blah blah blah..
Well things are now settling down here on our new server.
Got a handful of old and new domains consolidated across the board and some nre goodies lined up.
Most notably would be the start of development on the dream wars. Got a good start on the dsesign spec and some of the data modeling up and running. It’s an ooold idea I had a long time ago but with the new png support that’s universal plus a bunch of new nifty ajaxy2.0buzzwordladen tools at my disposal it actually might be doable now. The biggest concern is how browsers support 3-400 pngs with 8bit transparency. I hope pereformance doesnt just suck.
anyway.. more layout changes and general tweaking still needs to be done all over the place. But it’s a beginning.