next »

[DeadPixel]

So this thing is alive.  No longer looking at the Xbox for it, though.  Kinda feel like desktops and phones fit our gameplay goals better.

Anyway, I'm doing this in Java/libgdx now for dat portability, son.  If you're interested you can watch progress happen (pretty much nightly at this point) over at the live devlog/changelog. 

You can play the latest build in-browser there.  Some people have reported issues with it, though.  I haven't looked into the problem too deeply yet as I'm not exactly an expert on libgdx applets yet.   Let me know if it won't load for you and in what browser, and I'll see what I can do.

I anticipate some traps will be in after tonight's coding session which means actual gameplay will begin taking shape.  Right now it's basically a running physics/AI test!

[Udderdude]

How are you planning on making the traps differ in terms of strategy/how they're used?  It seems like once the most effective trap is discovered, the player can just keep using those.

In fact, I can't really see any kind of strategy that could arise from this game.  You just put down traps in the long narrow corridors, and watch them die.  Just don't use them in vertical areas where they quickly fall.

[DeadPixel]

How are you planning on making the traps differ in terms of strategy/how they're used?  It seems like once the most effective trap is discovered, the player can just keep using those.

In fact, I can't really see any kind of strategy that could arise from this game.  You just put down traps in the long narrow corridors, and watch them die.  Just don't use them in vertical areas where they quickly fall.

Good question.  Primarily by working with the cost of traps vs money available for that level (ie, the easier to use traps could be more expensive, this limiting the number you can buy, or perhaps the more of the same trap you buy the more expensive they get), different hero types (shield dude could block projectiles, fire immune heroes, etc).  Specific traps could be disabled on a level by level basis though not preferable.

A less forceful approach could simply adjust the final score based on trap variety in the level.  Spamming a single trap would afford the lowest possible score for that level.

Smart level design on our part will come into play here, as well.

[DeadPixel]

So, last night I worked on two things: improving hero navigation AI, and implementing basic trap selection and placement.

Hero AI

In the previous iteration of the game all hero movement was controlled by AI triggers placed on the map by myself while designing it.  This time around I wanted to do it all progmatically, but I was having issues with a specific case where the hero needs to make a decision to either jump up onto a reachable ledge, or fall down onto a landing below:

The hero had no idea where he had been previously so it was possible for him to backtrack infinitely by choosing the already traveled path.  After a lot of toying around with it I settled on implementing a simple bread crumb system where each hero will mark a tile position as visited when passing through it.  They can then test against this when making a decision, and will always choose the untraveled path first.

Traps

Since the goal of this initial build is to test out the game play with players placing the traps I needed to implement placement rules for each trap type.  Each trap has it's own static canPlace() method that I pass in the castle and the potential placement position to.  It will then look at that placement in the castle and decide if that trap will work there.  For instance the flamethrower requires that it does not collide with another trap, is placed in an empty tile position, and has solid ground below it.  The fireball requires being placed in lava.  The pipe monster requires being placed on an exiting pipe, etc, etc.

Currently you can spam traps everywhere all willy nilly, but they will soon to be tied to a resource system (probably coins from the heroes), and certain traps will only be available based on level restriction (either arbitrary, or functional... ie, no lava = no fireballs).

I also need to think about how to handle traps placed in the path of a hero.  Currently the heroes will simply walk 'past' the trap, and I think that may be an ok solution for things like bullet launchers, flamethrowers, etc.  But what about the Thwamps or Spikers?  I don't know if I like the idea of heroes just slamming their faces into the side of a Thwamp and dying.

Player placement of traps leaves a lot of difficult questions to answer, I think.  Some of them can be solved with tight level design, some cannot.  I'm determined to get it working so I can see it in action and get feedback on it first.  I'm not against going a different route with it, though.

[Udderdude]

Ideas for making the game more fun than just "Place traps and watch stuff happen"

Traps must be activated manually.  This adds a timing element and makes the player feel like they're part of the game world more.

Traps eventually wear out/fall apart and must be replaced.  This will prevent the entire level from filling up with traps too easily.

Add superheroes that are not be affected by normal traps and must be destroyed with supertraps.  This gives the player something else to do when the superheroes show up.

[DeadPixel]

Manual activation of the traps is the current goal, ya.   I guess I wasn't clear on that, or muddled my words too much.  It's a setup phase where you place them, then the frantic phase where you try to squish everything.

I was considering a 'sapper' hero that will blow up your traps.  Falling apart on their own is a good idea, too.  Will look into this.

Super heroes and super traps is a good idea, too.  Thanks!

[Dacke]

If you want a more advanced bread-crumb system, that allows heroes to backtrack more intelligently, you could use Trémaux's algorithm. Just avoid making big assumptions when writing it, so that it doesn't break down if you add trapdoors/teleporters.

If you want to add proper strategy then look into how tower defence games do it. None of the things you listed would make for a fun game imho, except heroes having different abilities/strengths (but you shouldn't focus on complete immunities). Limiting traps and going by score will probably just feel cheap to the player.

I wouldn't go with manual trap activation either. But I prefer games based on strategy, so it's mostly a matter of taste.

Random examples of things that will add strategy:

• Different trap types:
  
  • Damage dealing traps focus on hurting heroes. They can be one-shot or damage over time (DoT)
  • Effect traps mess with the heroes more indirectly. Examples on effects are slow down, teleport, confuse (turn them around and make them loose their bread-crumbs?), stun, poison, trap door, etc.
  • Spawner traps generate monsters that the heroes must fight. Monsters have different strengths and weaknesses
    
    
• Make it possible to combine traps in clever ways:
  
  • A stun trap in front of an skeleton archer spawner. Heroes are stunned for a few seconds at which time the skeletons get in some free shots.
  • A slow-trap in front of a DoT trap. Heroes move slower through the DoT trap, taking more damage.
  • A trap-door trap over another trap. Heroes fall through the trap door to another level, for example into a lava-pit.
    
    
• Different hero types:
  
  • Fast heroes are harder to hit and are strong against DoT traps
  • Shielded heroes have a chance to block attacks, making them strong against powerful one-shot traps but not cost-effective against many small traps or DoT traps
  • Sneaky heroes have a chance to detect traps and avoid triggering them (if traps are auto-activated) or temporarily disable them (if traps are manually activated)
  • Fighter heroes (of different kinds) are good at killing monsters (of different kinds).
    
    
• Spending money should be interesting
  
  • The initial money on a level should only allow you to buy a few basic traps. You get to buy more as you go along.
  • Let traps be upgradable. Makes it harder to choose between having more traps or stronger traps.
  • Add interest to unused-money. Give the user interest on the money they don't spend, so that they feel like they should use as few traps as possible. This can be incredibly annoying in a game but also fun at times.

The list goes on. But as I mentioned before, play some good TD-games to get more ideas.

[DeadPixel]

@Dacke, great feedback, thanks.  Some of those things have been in the back of my mind already (spawners will exist, we have minion types setup for that, different hero types).  I hadn't put much through into status effect traps yet though, and that's a good thing to add, I think.  Mostly traps have all been one-shot kills, so adding some depth to that will be a goal.

Still on the fence about manual activation vs a trap AI approach.  I'll continue with prototyping the manual activation and see how it plays out.  Thanks for the input! 

[Dacke]

Thinking about it, TD-enemies are usually build from a set number of properties.

For example:

• HP, obviously
• Armour, usually subtracting a fix number of damage-points from each attack but not below 1 dmg/attack. So high-armour units are good against many small attacks.
• Speed, obviously
• Dodge/Block, a % chance to avoid/nullify an attack
• Strengths/Weaknesses, taking more or less damage from piercing/fire/physical/melee/etc. Sometimes even immunities, but usually only for very powerful units
• Attack. If the enemies have an attack they need Attackspeed/Damage/Damagetype/Special effects.

From these properties, you can build lots of different enemies. Also throwing in some unique abilities like "flying" if you want to.

If I were to generate a flood of heroes, I would probably build them from stats+components, like how you build your own heroes in RPGs. First select a race/class (which gives a basic looks/abilities/adeptness), then level them up to a wanted exp-level giving them a semi-random spread of str/dex/int/etc. Then give them some appropriate items, for example a shield that gives them a block-ability but slows them down. Or a pair of poison-resist-boots. From these properties you can figure out how the hero should look (i.e. dwarf + warrior + shield + green boots) and it's abilities/properties.

To add strategy, you should probably have different waves of similar enemies (like you get in your standard TD) so that the player can prepare itself against bulky warrior-dwarfs or fast thief-kobolds.

Now go build something fantastic and then make me a Linux build

[DeadPixel]

Hopefully it'll run fine on a Linux JVM with Gl2.   I'll have to get my Ubuntu distro up again to test when I get further along.

[Dacke]

Oh, it's Java! Omnomnom! Then I should have absolutely no problem running it, don't even worry about it. Send me a PM if you need help testing/running it on Linux or if you need some Java help

[DeadPixel]

@Dacke, I definitely will, thanks.

07/18/2012

Coding last night was intentionally light as I've had too many 2am - 2:30am coding sessions in the past week.  Glad that fire is back in my belly, but I don't like suffering so much at work in the morning.

I spent most of the time refactoring the trap-adding code from the night before, cleaning it up, making it more presentable and maintainable.  I abstracted out the control listener from the game state class and cleaned up how the ghostly currently selected trap gets rendered.

I rewrote the castle renderer itself to make use of libgdx's SpriteCache class.  It's a really useful thing that let's you create a cache of static images, turn them into a single quad, and then save that directly onto the GPU.  So instead of each frame re-rendering 'width * height * numLayers' worth of tiles (which with current max level sizes could be up to 7200 tiles) I only render 'numLayers' worth of cached tiles (which, at the moment, is 3).

My goal for the coming weekend, other than seeing the new Dark Knight movie, is to get each current trap's activation code in, and to design 2-3 basic levels that are actually meant to be playable.  That'll put me on a solid foundation of code that I can begin iterating on to make it fun.

[DeadPixel]

7/25/2012

Been a slow week in progress due to the Guild Wars 2 beta weekend, Batman, and some personal issues that had me beyond stressed out.  Anyway I got back to work tonight and made some steady progress.

I moved all entity creation to use LibGDX's static reflection pool methods.  This way everything throughout the game will be pooled and give me less GC headache.  Not a big change, but something I needed to handle before moving further.

I spent most of the night implementing trap activation logic, and completed the basic stuff for the Bullet Bob launcher, Fireballs (in lava pits), Thwamps, Spikers, and Pipe Monsters.  They don't interact with the heroes yet, nor do they respect their cooldown timers, but they animate and go through their respective state machines (pretty much) correctly.  I'll add in the flamethrower tomorrow, then get them interacting with the heroes, killing them, and their respective death animations in.

After that I'll design a few basic progression levels and begin the long grind of iterative improvements.

[DeadPixel]

7/30/2012

Spent the better part of the weekend refactoring large swaths of code.  This mostly came about as a result of realizing that LibGDX's Stage class wasn't going to offer me the fine grained control of my entities that I needed.  Mostly with draw order, but with other things as well.  It'll work fine for UI still, but I had to spend a lot of time re-implementing exisiting code to get back to where I already was.  So that's slightly annoying.  Growing pains of using a new lib, I guess.

Re-writing the existing code gave me the opportunity to ensure that I'm properly pooling commonly re-used objects as well, which is good.  I was a little messy previously, so being able to catch myself in an impromptu code review was helpful.

I also started on an implementation of hero waves.  Currently the spawner just spits out a number of random heroes at a set interval.  Now I can assign a collection of waves, each with their own unique composition of heroes, to each spawner.  The castle level will track the current wave number, and at the beginning of each will check the spawners to see if they have an associated wave ID.  If so, heroes from that spawner will being to generate.  This way I can have multiple spawn points throughout the castle each with their own unique compositions.  I just have to figure out the format I want to represent this as in Ogmo Editor.