next »

[candlite]

You are a hungry dragon. You are flying over green pastures when you spy some tasty treats. You land, scaring away some local fauna, and happily gorge on the leaves of a delicious holly tree. Peasants from the local village witness the livestock fleeing in terror and mistake you for a threat. Brandishing pitchforks and torches the villagers attack! You must defend yourself by hiring venal goblins and building cunning traps to deter the belligerent mob.


Misunderstood Dragon is a minimalist tower defense game I've been working on since early July, 2014. I've got a lot of work to do (art, music, animations, story) and I'm hoping that this resource will keep me honest. I've made some decent progress and I think I'm about ready for alpha. The game is playable but doesn't have much depth. I am making the game for my fiancé, who requested a tower defense game for her birthday and if/when it is completed it will be my second finished game. I intend to release it on Android and iOS. I'm using libgdx, so it's possible I may release it for desktop (with some additional UI work).

Current status:

[kraed]

Nice and fresh premise, keep to it. It's going well, the look is very appealing. My suggestion, spice up the tower defense gameplay, there's too many of those around, and the idea is very catchy to be just another tower defense. Very interested at what is to come, best of luck.

[Savick]

It looks nice so far (i like the colors), but maybe put the dragon in place of the white box at the end of the path you have there in the gif?

[candlite]

Nice and fresh premise, keep to it. It's going well, the look is very appealing. My suggestion, spice up the tower defense gameplay, there's too many of those around, and the idea is very catchy to be just another tower defense. Very interested at what is to come, best of luck.

Thanks! I'm not deeply versed in the genre, but I'll try to add my own take, starting with the off-beat story. Are there any pitfalls to avoid (i.e. overused tropes, mechanics)? Certain elements that define tower defense games are already implemented: resource collection; resource expenditure for defenses; set of known enemy paths; defense upgrades. The next game mechanic I intended to add was movable towers (i.e. goblins that can reposition).

It looks nice so far (i like the colors), but maybe put the dragon in place of the white box at the end of the path you have there in the gif?

Thank you! I'm working on landing, sitting, and fire-breathing sprites for the dragon (to replace the white box), as well as peasant and goblin sprites (attackers, towers, respectively).

[Sarge]

Caught the dragon sprite on reddit.

Cute concept.  Interested to see how it turns out.

[candlite]

Busy mid-week with family in from out of town, but as I mulled over design ideas and agonized over 32x32 pixel sprites, I decided I want the game to be non-violent; might be crazy of me. Goblins will be converted to cherubs! I made an idle animation for the cherub idea (I'm not 100% on non-violence yet but this was fun). The cherubs still shoot arrows, but I'm thinking of converting the arrows to little musical notes. Once a note hits a peasant three times, the peasant will become charmed! At that point, I might have them walk back to the village or just flicker out: quest for vengeance over. In the former case, I think it would be interesting to have advanced enemy units that can convert charmed peasants back into angry peasants.

There are some sheep; just working with ideas for the intro. The dragon is also permanently flying because I haven't made an idle animation yet.

Though little appears to have changed, I actually did a rework of the Underling class and extending classes (Cherub) to allow for animation (previously a placeholder texture). I also reworked menu options to allow for arbitrary extension of the Underling class, i.e. rather than explicitly creating, say, a RecruitCherubMenuOption, I now have a generic RecruitMenuOption that takes the Cherub.class as a parameter. I'm setting myself up to run on status effects (sleeping, charmed, muddy, etc.).

[Savick]

The drifting animation on the clouds look choppy, but it could be the gif. Otherwise nice style development.

[candlite]

The drifting animation on the clouds look choppy, but it could be the gif. Otherwise nice style development.

Thanks! I think it's the gif running at less than 60 fps. The choppiness is not present in the game.

[candlite]

This weekend I added a simple animation for peasants and the first status effect into the game, charmed. Cherubs/cupids charm peasants with their arrows. Charmed peasants stick around for a while and then vanish. I need to juice up the vanishing (with an alpha out or something...). I want to make them walk backwards, but I was having trouble reversing the dynamically assigned path and didn't want to rerun A* individually (instead of for the group) on each peasant; even on death that seems silly. Regardless of whether they path back or simply flicker out, there will be some enemy units that convert charmed peasants back into angry peasants.

I had a lot of fun creating the charmed hearts animation, and even a few mishaps along the way:

Regardless, I've got a system for animating and adding these status effects now. Sleeping, alarmed and confused are probably next up for addition, as well as a soldier enemy (who is resistant to charm, but not sleeping/confused).

[candlite]

More foundation changes this week. The desire (and repeated suggestions) to send a peasant home after it is charmed required that I find a way to reverse the peasant's generated path. Peasants were totally ignorant of their path except that on each update they move a little in some direction, so this required some [ultimately good] changes to the base Enemy.class. I am using libgdx's SequenceAction to walk each branch of the known path independently, between vertices generated by an A* algorithm. I update enemies so that each stores a references to the vertices and a counter of the number of vertices traversed. When charmed, enemies can now walk the path backwards. (In writing this, I thought of a better way to track the path without a counter... This is why we write, no? )

There were some tricky parts. I compress the generated A* path into vertices and a length property (i.e. NODE = {pos: (X₁, Y₁), len: 5}) to prevent generating MoveToActions for each tile. The duration on the MoveToAction is normally a function of that length (i.e. duration = NODE.len * enemy.speedFactor), but if an enemy is charmed half way through his travel between nodes, that length is inaccurate in reverse. Long story obvious, I had to calculate that partial length based on the sprites current position and its current destination node. Also, as shown in the image above, I wasn't reversing the sprite so it looked like they were backing away very slowly (until they hit a vertex). I also noticed/corrected a bug where walking animation frames were not affected by the speed modifier applied by the tar traps!

At the moment, militia don't do much except have extra health and deal more damage. Fun bugs in my first run revealed some hard-coded references to Peasant.class which caused traps and cherubs to ignore all enemies except peasants. I intend to make militia resistant to charm and weak against a different status effect, maybe intoxication. That's likely the next leg of development for me: damage types. I'll need to adjust levels so that each defines which enemies it can generate, too. Currently, levels randomly spawn a wave of either militia or peasants, but I want to graduate players through enemy types, rather than spawn a wave of bosses out of the gate 1/3rd of the time.

Current status:

[candlite]

I'm working on more and smaller levels, each ranging from 30-90 seconds, to gradually introduce new concepts (i.e. enemies avoiding defenses), defenses and enemies to players. No new images to show of the process (yet), but I spent the evening abstracting Level.class so that, rather than accept an array of bytes (byte[]) representing the open and closed tiles, it accepts a Map.class object that contains all the information about a map; the array of tiles, a maximum number of waves, and an array of valid enemy types. The last will let me accomplish enemy education. I'd like to do the same for available defense types (i.e. create an array of available traps and underlings)!

In regard to the game's narrative, I'm working on explain scene transitions during the dragon's flight from the angry villagers. Each scene's name will be displayed briefly at its onset. My ideas so far are a harried journey back towards your lair, each bullet represents a level transition here:

• Peasants from the village of swarm you as your presence is noticed. You flee
• across the farms of as night falls and villagers pour from their houses.
• Militia and peasants harry you across the plains of and
• nearly corner you at the river , but you manage to escape
• into the forest of , where militia and elves track you through the thick undergrowth...

Etc.. Each stage would introduce a one or more gameplay concepts:

• Peasants as enemies. Cherubs and mud as defenses.
• Multiple enemy sources, path forking
• Militia as enemies.
• Decoys as a deterrent.
• Elves as enemies, crazy path forking.

[candlite]

Implemented Bezier curve paths for enemies (first time using this method) that replaced a LibGDX SequenceAction of MoveToActions. In addition to finer control over movement around corners, Bezier curves will let each underling 'look ahead' on the enemy's path and lead the enemy with its fire. After playing with Bezier curves for most of the afternoon, I think I'll change the path of the arrows shot by cherubs to an arc, rather than the current straight line.

I also implemented beehives, which slowly spawn bees (up to a cap of three for a non-upgraded beehive). Bees currently sting peasants and militia for the same amount of damage as a cherub's arrow, but cause confusion rather than charm. Confused enemies will run home the same way charmed enemies do! Confusion will also be more effective against militia. No images for the beehives yet. I also intend to give the bees a 'homing' radius to make them a little bit more effective. As it stood, it was difficult to beat even the first level with only beehives.

[candlite]

Put some work into beehives after playing with mechanics. Beehives will have a significantly larger effect radius than cherubs (whose radius was reduced in this build), but a much slower [effective] rate of fire. Still haven't added homing to the bees, but following up on a suggestion from an early alpha tester I added a display for effect radii. These were set to always-on for debugging purposes; I'll show the effect only when the tower is selected. You can also see the prototype graphic for the Confused status at the end of the image!

Next up for me is the Decoy, a trap that lures attackers to it, potentially forcing them through defenses they might otherwise avoid. Torn between elves and wizards as the next implemented attackers. And then there are the bees.; busy busy!

[candlite]

Took the weekend off to... enter Ludum Dare 30. 



Yesterday and today I worked on something I've been thinking about for a few weeks: homing bees. It was a unique challenge for me, mostly because I've never done something similar. This is the short list of defining features for the Beehive:

• Generates bees at a fixed rate.
• A limited number of bees can be active at once.
• Bees patrol within a radius.
• If a bee spots an enemy, pursue and sting!

Generating bees at a fixed rate, with a limit on the number of bees, was easy. Additionally, it was a trivial (and unnecessary) optimization to recycle "used" bees into a pool of bees to prevent unnecessary Object creation. The radius was slightly trickier. I move the bees with a randomly generated Bezier curve: I pick a random pivot point in the quadrant clockwise from the bee, and an end point in the quadrant across the origin; simply repeat the process forever. The effect is roughly what I had in mind, though sometimes the random points create acute angles that, while closer approximations to bee movement, are difficult on the eye. Something (unknown bug) is causing the bees to roam outside of the Beehive's radius (you can see it right at the start of the image in SE quadrant of the right beehive), but I kind of like it, so... 



Bees now search for enemies in their targeting radius (solid circle). They lock on to first enemy they find* and move towards it. I made several attempts at moving the bee towards the enemy, some using LibGDX's Actions, others with my own terrible acceleration/positioning code, and struck on a pretty fun method: on the frame of target lock I create a new Bezier curve with the enemy's current position as the pivot and destination, and the bee's current position as the start. As frames update, I shift the position of the Bezier curve's end to match the enemy's new position, while keeping the pivot at its lock position. It creates a nice attack vector!

There are some problems with the velocity of the bee. Ideally, I'd like to have it accelerate into the sting, so that's what I'll tinker with the next time I touch beehives.

* This is naively determined by order in the scene graph. I'll likely change this to the enemy closest in position to the bee (in the target lock frame) to prevent bees from ganging up on one enemy in a cluster. Bees just shouldn't be that cunning.