Posts Tagged ‘game development’

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.

Enchanting Cadence launched for Slick contest!

The Must do’s got done.

Several of the ‘Wants’ got done.

However Mac support looks impossible.

However, at this time I’m proud to announce It’s live!!!


http://www.enchantingcadence.com

10 levels. Java applet w/ facebook integration.

It’s been on helluva learning experience.  Will digest a few things for a bit and have a postmortem up before too long.

Will update with a link for voting once voting begins next week.

 

Elements

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
  • SOUND!
  • LEVELS !!!!
  • 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.

 

We Have Gameplay

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.

Next up:

  • splitters.  gotta stop pushing that off.
  • rotator modifiers
  • 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.

Screenshot Saturday

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 :

  • applet -> javascript -> applet communications are now working.  Which is pretty awesome.  The biggest challenge was that sending outbound communications need to be triggered from a seperate thread to prevent the JVM from stopping and waiting for a response and that Inbound connections needed a custom version of appletGameContainer that exposes the StaeBasedGame object (more details on all of that can be found here).
  • 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.

Follow us on Facebook
Calendar
May 2012
S M T W T F S
« Apr    
 12345
6789101112
13141516171819
20212223242526
2728293031  
Archives