Monday, November 19, 2007

Technically a game now.

A short update; didn't do much, so I won't say much. You can now "walk" around (as in, change your position; doesn't actually animate yet). A screenshot wouldn't show anything, so that's it. Yeah I suck.

Monday, November 12, 2007

Another lame pseudo-update.

Okay, okay. So I lose AGAIN. No big deal by now; practically everyone has lost at least once by now. It's the thing to do.

All the actual progress I got done this week was thinkin'... oh, and I fixed a little bug with the camera rotation and started moving code around, but that's not very excitin'. I did a few more lines of ability code before deciding to scrap it again, and I've thought of a million different ways to do it, before finally deciding to bite the bullet and code some nasty crappy code and just get it done.

So where did the time go? I spent 3 to 4 of these 7-ish days playing the newly released Metal Max Returns patch from Aeon Genesis, and I liked the game a bit so I played the whole thing. Then, I was still itching to play something so I spent a day on DeJap's Star Ocean translation, which for some reason I haven't started until now despite being a fan of the series. I'm also working on another thing that no one here would care about, so I spent another day on that.

Anyway I guess it would behoove me to make this an actual update instead of excuses, so I'll explain s'more about the game systems.

Exploration:

Walking around in towns and other non-hostile areas will be the same as it is in... well, hostile areas, except zoomed out a bit probably so that it looks a bit like a world map but still enough like the meat of the game. I might lock rotation, just because. I can't really explain why, but it creates a certain "transitional" vibe. Walking is tile-based, of course.

Can't decide about shops or whatever (or even if there'll BE shops; more on that later), whether to have it just switch to a menu when you walk in, or let you walk around inside the shop. The original plan was to make everything very interactive, but I'm rethinking it as it adds cruft and, for once, I don't want cruft. Items are going to be fairly secondary, at least compared to my original plan, which hinged on a complex crafting system.

Combat:

Once in a dungeon (or hostile area), you move around like normal. Enemies appear on the map as other entities, and only move when you do, like a rogue-like (OR AZURE DREAMS). When you are a certain range away from enemies, you can initiate combat mode (like Fallout), or just try to walk past an enemy. Depending on how hostile they are/their relative strength to you, they might initiate combat anyway and get a headstart.

Once in combat, things switch up a bit. It goes from strictly turn-based to real-time that pauses when you enter menus/active abilities activate (like Growlanser or my old compo entry, Commander Charisma). This MAY change in the future because one of the thoughts I had this week was that this system might not work. With the amount of tactics involved, there's probably going to be some trial and error and some completely ineffectual moves, and if you have to manage time along with all of that, things would get pretty annoying. I'll see how it works in practice before making a decision about this.

Abilities:

Abilities have two main properties: trigger method, and effect type. The two trigger methods are active and passive. Active abilities require you picking the ability from a menu; passive abilities are in effect by default, or happen in response to something else. What I've called effect types here relate to duration. An ability can either happen once and then end, get toggled on or off and have a persistent effect that may or may not run out (for example, something like an enchantment that doubles the strength of fire abilities), or be in effect only while the user is using it (traditionally called channeling). There are other catches, but these are the main factors.

Abilities will have all sorts of conditions that are required for execution or that raise/lower their effectiveness or change their parameters. To make this more complicated, just combine any two of the aforementioned types. An important idea in this system is that abilities are VERY effective, but only in certain situations, as opposed to the generic cover-all stuff we get in other tactics RPGs. (Why is it that when I use a fire spell on an ice monster, I only get a 25% boost? Lame.)

Say we have a hard-shelled monster, with a passive ability called Hard-Shelled. This ability reduces damage by 90% unless the attack is Piercing. Now we COULD give our hero a separate piercing attack, but that's not exactly strategy. The only factor to consider would be, which ability do we have to pick, every single time? Instead, we'll add a layer of complexity by giving a 2nd character a channeling ability called Pierce Through which gives the abilities used by its target the Piercing attribute. This is just a very simple example of what I'm talking about; things will likely be a lot more complicated. Keep in mind that conditions could also have to do with synergy between specific characters, distance, timing, effect patterns, height, walls, traps, arrangement of combatants, et cetera. The key word is tactics.

Let's say an enemy has an active ability called Sever Link that terminates any channeling abilities being used by its target. Another enemy could be laying in wait to deliver an attack between the time that channeling ability is severed and that character is able to get it running again (because of the slight cast delay). There are a lot of ways we could combat this. The character affected by the channeling ability could be waiting to unleash his attack until the channeling ability takes effect, preventing the enemy from having enough time to sever it. Or, use a repositioning ability to move the Sever Link enemy out of range. Or, use a status effect to prevent his casting. Or, use some other counter ability to penalize the enemy for Sever Link. Or, just bash the enemy's head in before all this happens-- oh wait, this isn't a standard tactics game, so that won't work.

A+!

I hope that's enough to make up for my failure. Unless Aeon Genesis patches another awesome game this week, I think my next update should be meatier.

Sunday, November 4, 2007

Ability inability.

Progress on the game's code has started. Whoooo!

The first thing I'm coding is the ability system because it's basically the crux of the game. As a tactics game that's trying to emphasize tactics, the abilities are extremely important. It took me a long time to figure out how to properly code the system to be as flexible as I need, but I think I've succeeded. The system itself is just starting, but I now have a clear idea of how to proceed.

I made the bold (read: stupid) decision to hard-code each ability since their effects will mostly be unique and very widely varying. I might reverse this in the future if I find a lot of overlap, but I don't see it happening.

Because I'm just learning ogre and I don't have a very easy way to do input parsing (I could just take keypresses or put some crappy GUI widgets up, but that's a hassle since I'm still shaky around ogre), I'm also writing a pseudo-battle-state-machine by which to test the interplay of abilities. It feels almost silly to be saying this since I can't really illustrate it, but I feel it necessary to report on my actions.

Here's a screenshot. It doesn't show much, because there's not much to show yet. Yes, that is the default ogre robot mesh. I've injected my own texture into a material and made the randomly generating tile map thing you see there. What's most important is that it illustrates how exploration will be tile-based, and the camera will be third-person at an angle (I totally didn't gank this from Azure Dreams. Really.)

(Also I didn't show the screenshot directly because I didn't want anyone jumping to it immediately and going WTF THIS SUCKS OMG. Read the post, goobers. And keep in mind I've just started the project.)