Author: Simon Jensen

Posted on by

Daily Progress update.

I know… updates two days in a row??!  What madness..

Manged to get A* following objects to automatically turn and adjust their facing while maintaing their portrait’s orientation.   Also increased the basic map tile size by one so things aren’t as cramped.  The remainder of the evening was spend working on the following Mocup UI:

As you can tell I’m targeting a baseline 1280×768 resolution.  (obviously.. doesn’t everyone count the pixels on every image they see?)  The different thing is that designing for widescreen (6:9 / 6:10) and then making it work in old school 4×5 instead of doing it the other way around, lets you make some design decisions that you usually probably wouldn’t do.   With Widescreen you can essentially forgo the old L shaped UI frame and just settle for a thicker | shaped sidebar.. and still have plenty room left over.

I think we’ll be seeing more and more of this as the old 4×5 proportion fades into obsolescence. ..

Posted on by

The Fall Season!

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.

Posted on by

Not Dead

Nope not dead, or forgotten.. just trying to survive the heat.
As it turns out, today, the day when the temps didn’t reach 100 for the first time in 40 days I finally get the initial map renderer working.. and it’s very good news.. The FPS hit on rendering even in full 1920 x 1280 is almost negligible.
So to celebrate.. here’s a screenshot!

Posted on by

Bits N Bobbins

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.

  • 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.
and damnit .. http://www.garagegames.com/products/torque-3d the introductory price will be ending soon.
So I’ve got to grab that soon.
Posted on by

Building Better Tools

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)

 

Posted on by

Setting sail against the winds of whim and staying the course

Wooosh… that’s the sound of another gale force great idea blowing around.
Yup, they’re pretty much everywhere at this time of year. Annoying, persistent, unformed, and generally really exciting!

The thing is, they’re always much more exciting and enticing than what you’re doing ‘now’. Especially if what you’re doing now is rewriting something you’ve done before, in a new engine. In the last 3 weeks I must have changed my mental description of what I’m working on half a dozen times. Each new project, idea, or whim is a terrible distraction that’s so much fun to just dive into.

Because for me the best part is the initial rush of putting ideas and framework into place and start various parts gestating. So when I haev nothing but a couple months of grunt work (asset managers, re-inputing pathfinding algorithems, importing graphics, dealing with text input etc) it is so easy to want to start over and tackle an enticing problem and find out how various systems would interact.

Hell, at this point I’ve practically convinced myself to ditch BSDDoD! and hop into making ‘Irismel’ – the fantasy village simulator instead.  I’ve even started making some basic tiles and mock screenshots.

That’s gotta stop.

It’s time to get excited about BSDDoD! again.  So I’m laying off the big coding for a bit and painting some assets, concept art and visually interesting things.

The upside is that I’ll have things to show before too long and I can get the show back on track.

I am, however, thinking of changing the title from Blood Soaked Deadly Dungeons of Doom! to something more palatable and url worthy.

 

Posted on by

Tech Choices: Walls

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.

Walls are a block.

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.

Basic implementation:

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.

Upside:

They’re easy to implement and fairly lightweight, make a whole bunch of visibility / raycasting real easy and fast.

Downside:

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.

Walls are an attribute

Example:  X-com, project Zomboid, old Gold box D&D games, the Sims

Basic implementation:

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.

Upside:

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).

Downside:

Complexity.  Pathfinding, line of sight and collision detection all become significantly more involved, not necessarily slower,  just more complicated.

What did I choose?

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.

Posted on by

Four indie things you should be playing

in addition to Minecraft.  There’s a whole bunch of really cool indie stuff that’s coming out.  Here’s four alpha/beta state games that are available for play now.  These are all fairly early in development (Terraria and SP&Z being the most polished) and if you’re interested in watching something awesome come out of the development process and getting to watch things turn into a finished game, warts and all, then these are all excellent examples and well worth your time.

Project Zomboid

 

http://projectzomboid.com/blog/ Isometric Zombie Apocalypse survival game.  As in, really surviving.  Health, hunger, exhaustion & boarding up the windows while scavenging for supplies in a neighborhood infested with the undead.  Really this is going to be very very tense.  The initial version available is still early alpha and manages to do so many things right.

Space Pirates & Zombies

 

http://www.spacepiratesandzombies.com/ Aims to go back to classic space combat and exploration with gameplay like Star Control 2.  You fly around various sectors and perform missions between rival factions to gain favor and unlock blueprints for new ships and weapons.  And then there’s the zombies and an overall massive plot and stuff. Available on impulse only for now.. but Steam is coming as well.

 

Terraria

http://www.terrariaonline.com It’s superficially like a 2D minecraft.. however once you spend a while with it it opens up to be much more.  It has a much higher emphasis on exploring the world, fighting monsters, summoning boss monsters and crafting all sorts of weaponry.  Oh and it has multiplayer support.

Starfarer

http://fractalsoftworks.com/ On the surface it might remind you of SP&Z above.. however gameplay is much slower and strategic. Feeling more like you’re flying large capital ships. At this point it’s a collection of fleet battles but the promise of an open universish campaign mode has lots of promise.  oh and it’s absolutely beautiful and has incredible ships.

Posted on by — 2 Comments

Enchanting Cadence post launch retrospective

What went right?

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.

What went wrong?

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)

Considerations general thoughts?

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.

The future?

For Enchanting Cadence

  • facebook integration will go away, hell, the whole applet thing was a mistake
  • it will be a standalone application
  • the first level in each levelgroup will get a real tutorial. (introducing mirrors, introducing prisms…etc)
  • there will be help indicators showing the path and time bolts travel when hovering over a launcher
  • the enchantment track will show what bolts hit and failed on the last attempted enchant.  This will help you find out what went wrong
  • infinite loops will not be allowed
  • the dialog engine will be changed for better and prettier dialog boxes allowing for more narrative and flavor text to come through
  • more levels and assets etc.

In General

  • I’m building a group of tools to use in the standalone EC version that will also be useful in other projects
  • Blood Soaked Deadly Dungeons of Doom! is coming.  Much as I love TGB it looks like you always wind up needing to do some core C++ tweaks and thats beyond what I’ve been able to wrap my head around.. so I’m exploring basic things and techniques to get the new isometric view working in slick… (repeat after me… I will not try and go 3d… I Will not try and go 3d!… )
  • Mutant Sheep Eat the Earth! need some loving too…
  • Swiftthought Consulting work, of course, trumps all of the above.  🙂
So, lots of projects to keep the summer interesting.  Lets see how it goes.


Posted on by

Crunch Time

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.

  • tons of level objectives (2 img each per level)
  • Bolt particles and effects and images
  • tutorial images
  • levels
  • better sounds… more bg music..

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…

Posted on by

Screenshot Saturday Delayed.

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:

  • smooth interpolation of the tick based movement.. there’s hiccup in it currently
  • add dialogs for succeeding and failing enchants
  • get the ‘record’ mode of the solution to not mis time the first bolts
  • add splitters
Time to get to work!  well.. after work work that is..