SwiftThought.com

Archive for the ‘Games’ Category

So while it’s only 2 new tasks complete, there’s 2 more that are 80% there and others are planned out.

Here’s a recap of new stuff:

• PCs and monsters now shoot and damage each other with functioning ranged combat!
• PCs can die!
• Monsters can die!
• Monster spawner behavior is 90% there
• PC equip-able items / attacks are close to being there.
• New portraits are almost done.. then we’ll have 3 different PCs
• Project title finally announced:

• Project has it’s own Website http://www.irismel.com (granted for now it’s just an import of this swiftthought.com RSS feed.
• Irismel is listed over at http://www.indiedb.com/games/irismel-the-silverlake-chronicle
• Swiftthought etc has proper Desura / indieDb accounts made for eventual alpha release.

And Here’s a new Screenshot showing some of the things that you can see:

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.

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