next »

[Craig Stern]

Thanks! From what I hear, Flash doesn't support peer-to-peer, which means I'm going to need to go the matchmaking server route.

[Contrary]

Sounds really interesting. What are you doing to keep the units from being homogeneous, though?

[Craig Stern]

Units all have different attacks, movement type, movement speed, strength, health, and elemental strengths and weaknesses that make them suited for different tasks. The Mechanic, for instance, is a mediocre fighter whose greatest utility is in his ability to assemble structures on the battlefield.

Psy Healers are resistant to mental attacks but somewhat weak to physical ones. Assassins, in turn, are extremely fast-moving units (up to nine spaces per turn) who deal relatively small amounts of physical damage, but who score a big backstab bonus if they hit a target from behind. An Assassin can easily kill an unprotected Psy Healer, but is itself vulnerable to other enemy units due to its relatively low health and lack of damage resistances. (They do have the unique ability to randomly dodge 10% of all attacks, however.)

Spirits are flying support units who are extremely resistant to physical damage, but vulnerable to psy attacks. Psy Fighters are effective against spirits and other units resistant to physical damage, but won't win in a toe-to-toe match-up with--for example--a Swordsman or a Golem.

This gives you the basic gist: any given unit matches up well against some units, poorly against others, or primarily fills a support role and needs to be protected.

[Craig Stern]

New stuff!

I've added in code that allows for attacks that move characters from one space to another. A couple of examples:
--assassins can now Leap over characters and battlefield obstacles onto an open space;
--stone golems can Shove or Smash enemies back a space.

I've also added in health draining attacks.

[RCIX]

Thanks! From what I hear, Flash doesn't support peer-to-peer, which means I'm going to need to go the matchmaking server route.

I'd recommand getting a Google App Engine app. You ought to be able to use it for matchmaking, and it's free up to quite a hefty bit of traffic (then it starts charging).

[Craig Stern]

Interesting. It looks like Google App Engine only supports Java and Python, though. I was thinking I'd probably go with SmartFoxServer.

[Craig Stern]

Coming back to work on this some more after a bit of time off. Damage numbers now pop up and float into the air, then fade out whenever a character takes damage or is healed.

[Christian Knudsen]

(Pssst, you "Sinister Design" link in your signature goes to indierpgs.com...)

[Craig Stern]

(Pssst, you "Sinister Design" link in your signature goes to indierpgs.com...)

Heh, thanks. Fixed!

I've been taking time off from this to work on TSoG (which has been in development for three years and desperately deserves to be finished), but I did do some coding on the train to work the other day that lays the groundwork for area-of-effect attacks.

This game may be on hold for the next few months, but rest assured, it's not even close to dead.

[Craig Stern]

I've had the urge to work on this some more since yesterday, so I've made some beneficial additions on the train ride to/from work:

--The big update: area attacks are now in the game! The way they work, when you select an attack, the game places down up to four red tiles to represent the epicenter of the attack in each of four directions. Mousing over one of them shows the attack's area of effect. Clicking launches the attack, affecting every character in its area of effect.



--On the more technical end: I fixed the Stone Golem's Shove and Smash attacks; these attacks now only push characters and certain movable objects (i.e. boulders or furniture, but not trees, bridges, or walls).

[Craig Stern]

--I've fixed a problem with the array rotator I was using to rotate all the AOE reticles. It apparently wasn't doing a very good job of accounting for asymmetrical AOE, so I rewrote the thing.

It's a standalone class that can rotate an array 90 or 180 degrees in any direction, and I figured I'd just release it to the community since it's been so useful to me and I imagine it would be useful to many of you. You can download the class, along with an explanation of how it works, right here.

--In other news, I've added in MP-gaining and -draining attacks to the game, along with a bunch of new AOE attacks taking advantage of the game's new AOE functionality.

[Craig Stern]

--I spent some time today finishing up XML parsing functionality for the game. It can now grab levels from an XML file and use the XML code to generate the level. This is exciting for me, though I somewhat doubt that players will care much one way or the other.

However, I expect that I can reuse these parsing functions to allow players to share custom-made levels by copy-pasting long strings of code. I'll have to add that at some point!

[Jetrel]

I realized the other day while I was thinking about how my engine handles movement that this game suffers from The Disgaea Exploit.

If you've played any Disgaea game, you probably know what I'm talking about: it's a feature of those games that a character can move, a second character can move, and the first character's move can be undone, meaning that you can move a bunch of characters into a formation conducive to a healing spell, or move them out of the way of friendly fire, have the spellcaster finish his turn, and then go back and undo the moves for every other character you moved and have them take their turns normally.

It's fun in a single-player game like Disgaea, but it would be fundamentally unbalancing and obnoxious in a multiplayer game like this. Accordingly, I've just gone through and added some code that prevents players from undoing a character's move after they've clicked on a second character. Problem solved.

Yeah, wesnoth also uses a stack, for precisely this reason.  Wesnoth also has optional fog-of-war, and when you do some move in MP that gives you additional info (e.g. moving forward and seeing into fogged territory, or moving next to and discovering a 'cloaked' unit), you lose the ability to undo past that.

1) don't wait until late before you start coding online multiplayer. that's exactly *not* the kind of thing you can add late in development, you need to take it into account from the start, it absolutely can't be added later on without re-writing most if not all of the code. i should know, i made exactly the same mistake with 'alphasix'. it's not coded like hotseat multiplayer at all, it's a completely different thing.

I strongly second this.

2) if possible try not to use the pure top-down perspective rather than some sort of isometric or projectional perspective, i think that makes most games look ugly; even computer chess games like chessmaster don't use purely top-down perspective anymore;

Also relatively strongly agree.  I've seen one good game done in it (an obscure ARPG called "prince of destruction"), but it's generally conducive to blah art.  It does have an upside of insanely low bang/buck for directional animations, since unlike nearly any other art style, you can mirror all animations in all 8 directions.

also i'd suggest not to re-use graphics from your old games (it tends to make all your games look the same), as much time as it saves i don't really think it's worth it to make someone think they're playing the same game with different text / slightly different rules and levels

Kind of a mixed bag - especially when something is a sequel, like FF=>FFetc, or secret of mana->seiken densetsu 3, you can in fact get away with it with it not only not looking cheap, but it helping establish inter-series continuity.

I do agree with the sentiment, though - reusing too much across completely different games would burn a bit.

[Craig Stern]

I've been working on making the Mechanic unit lay explosive charges that other characters can detonate using fire attacks (or, with more effort, using physical attacks). The charges will deal a lot of damage to characters on every space adjacent to and diagonal to it, but perhaps more importantly, explosive charges will be uber-effective at destroying bridges, demolishing walls, and just generally taking the piss out of destructible objects on the battlefield.

Stone Golems can already push the charges around, once they've been placed. To make this mechanic more viable, I've added a new Kinetic Gust attack to the Mentalist that lets him push charges (and other units, for that matter) around from a relatively safe distance. I envision players playing a dangerous game of hot potato in the middle of the battlefield, one (for instance) trying to destroy a bridge while the other tries to detonate it in the middle of enemy troops.

1) don't wait until late before you start coding online multiplayer. that's exactly *not* the kind of thing you can add late in development, you need to take it into account from the start, it absolutely can't be added later on without re-writing most if not all of the code. i should know, i made exactly the same mistake with 'alphasix'. it's not coded like hotseat multiplayer at all, it's a completely different thing.

I strongly second this.

I was thinking about this--I think I might decide to go the hotseat multiplayer route with this after all, and release it on the iPhone / Android / iPad for people who want a portable chess-style strategy game to play with (or against) friends. That would make it easier to parlay the engine into use for something single player, and would just generally be less of a pain in the ass all around. (The thought of having to maintain a server and fight hacking, all on its own, gives me a headache.) I might make a true multiplayer version of this game in future, however!

[Craig Stern]

Explosive charges are now in-game and working! Bring them to 0 health (easiest to do with fire attacks, naturally) and they explode, damaging everything in their immediate vicinity. They deal extra damage to destructible battlefield objects, making them ideal for destroying bridges, walls, boulders, etc.

Also now working: variable-range attacks. Bowmen, for instance, can now attack enemies from 2 to 4 spaces away using their basic Bow attack.

Self-targeting attacks and abilities are now working as well.

[Craig Stern]

Small update: you can now win a match by eliminating all opposing units.

[Craig Stern]

Less-small update: I've finally disposed of the engine's "hold your mouse over the edge of the playable area to pan the battle camera" feature. I don't even know why I added it, honestly. It's always been a clumsy, half-assed way to pan around battlefields. I remembered hating it in the Myth games, and it didn't take me long to start hating it in my own game as I unwittingly sailed halfway across the battlefield multiple times per play session. So, yeah: that is no longer in-game.

In its stead, I've added something much more tactile and user-friendly: click the battlefield to "grab" it and drag it around. This way of panning the camera feels good, it's predictable, it's precise, and most importantly, it doesn't cause you to zoom over the battlefield unintentionally. (As an added bonus, the system should prove useful when the time comes to port this thing to touchscreen devices.)

[Craig Stern]

I was productive today!

--Characters can now counterattack. Unlike my previous engines, counterattacking is not dependent on the counterattacker's directional facing; characters will automatically turn and attack an attacker who is in range of their particular counterattack.

--Counterattacking can also occur at multiple ranges. Bowmen, for example, have a Bow counterattack. The Bow attack can hit 2, 3, or 4 spaces away. Any attacker 2, 3, or 4 spaces away from a bowman who attacks and doesn't finish the job will be counterattacked. (Melee attackers, of course, will be able to avoid retaliation.)

--The engine is not only now set up to handle counterattacks, it is also now set up to handle multiple counterattackers at once. A poorly planned AOE attack will lead to immediate retaliation from numerous different characters, slamming the hapless AOE attacker one after another after another.

--A smaller fix: engineers can now no longer build bridges/place charges/set up barricades on top of other characters. (In other words, the target space needs to be empty of other characters.)

[Craig Stern]

I spent some time today improving the character pathfinding code and modularizing it in preparation for CPU-controlled players. The goal is to make game playable single player, multiplayer, or multiplayer with CPU allies/opponents thrown into the mix. (I expect this will have an added side benefit of making this engine more flexible for a variety of future projects.)

In the process, I also added some more interface niceties, in particular the ability to preview the step cost and path any particular move will invoke by mousing over a movement tile. Like so:

[Craig Stern]

I've decided to give the Shove ability to all physical melee units in order to increase opportunities for tactics involving the repositioning of friends, enemies, and moveable destructible objects.

Speaking of moveable destructible objects: I've fixed some nasty bugs that crept into the code for explosive Charges. They now work as advertised, triggering an omnidirectional Explode attack upon death that deals 20 damage to all characters and 100 damage to all destructible objects within its radius.

I've also tweaked the Assassin's Leap ability. The Assassin can now Leap onto the top of non-wall destructible objects like trees and boulders, meaning that the Assassin can now do things like leap from tree to tree or boulder to boulder in order to traverse otherwise impassable terrain.