Week 24 -- Basic fighting and more

I have a longer post to make at some point, but for today it's past my bedtime. This last week I got obstacles to block you and created a test enemy for you to bounce off of.


This dialogue window looks cooler than it is -- it's totally hacked together and hard-coded. Just a prototype.

I'm thinking about changing my concept for the battle system significantly. This is mostly because I've been on a kick with the old Ys games lately, and I'm intrigued by the idea of running into enemies to attack them. (But I'm not going to use the Ys combat rule of off-center = you win, head-on = you lose. I suppose that's a decent player skill mechanic, but it's just zonky.) I have a couple of ideas that I'm waffling over that I'll post more about soon.

(Digression: I can't believe that I've gone all this time without playing the Ys series. Oh wait, I remember why: My only previous experience with it was with renting Wanderers from Ys on the SNES, which by all accounts is the black sheep of the series. I quickly decided it was insanely difficult and not that much fun and resorted to a cheat code to plow through it. I did try Ys I briefly, but I think I ran directly out of town, died immediately because I didn't know the zonky combat rule, said, "Wow, this sucks," and forgot about it. Oh, little did I know!)

Coming as soon as I'm not too sleepy to write about it: New plot, new title, battle system ideas, and the lesson I learned recently. And a video, if I can get a decent one captured.

Week 23 -- First look (ahem)

Brief and belated post from last week here. I've started on the game proper, and so far have the player running around and facing four directions. Woo! She's not bumping into trees yet, though; I'm missing something with the tiles.

More news to follow soon. For now, I'll leave you with the very exciting very first screenshot of the real game, with very pretty stick-figure/scribble placeholder art.

Week 22 -- Nothing, nada, nashi

Nothing happened last week. Too busy.

Well, I did have a general idea that I'm liking a lot. I may put my Last Ancient story idea on the back burner for now and instead make a game with a much simpler plot, in the same world and setting. Same gameplay design, but a smaller scope that I'll be more likely to actually finish for the contest (without having to totally butcher the story idea that I've gotten attached to).

Week, er, 21 -- More more TGB

Wow, I totally forgot to blog last week. Huh.

The last two weeks, I studied behaviors and tile maps, which both look like they'll be extremely useful. Behaviors let you conveniently attach a set of properties and callback handlers to any scene object. The main benefit seems to be the callbacks. The behavior namespace can implement lots of the normal scene object callbacks, so you can have a bunch of different handler functions all getting called, one for each behavior and one for the object itself. The upshot is kind of like multiple inheritance.

Tile maps are for creating levels that are built of lots of repeating grid squares (think Mario or any other older game). Just got started with them, but they already look very useful. You can assign various properties to each tile beyond just the image, which has interesting possibilities.

Anyhow, these last two weeks were good in that I felt that my TGB study was actually worth the delay. But it's high time to start putting the actual game together. Tile maps are the last main feature I wanted to study, so I'll study a few miscellaneous classes briefly and then get on with the main project.

Week 19 -- More Torque

Cruising along on learning TGB. I learned GUIs pretty well, and I think they'll probably be useful for the game. The highlight was learning a neat trick to show any scene objects as part of a GUI, which at first I didn't think you could do. You create a t2dSceneWindow in your GUI the size of whatever scene elements you want to display. Then you create a new scenegraph (or I suppose you could use part of your main level), arrange your elements, and set your mini-window's camera to cover what you want to show. This is the detailed tutorial where I found this.

I also covered some smaller things: mouse handling, mounting objects, timers, and paths. Everything's going well. Paths took some trial and error to figure out, as the included documentation says nothing about the path functions. Eventually I found a better reference on the TGB wiki.

Indeed, the biggest frustration for me has been that it's hard to find materials for learning TGB as a beginner. I've found a lot of good things by now, but it's often been just chance browsing on the forums or searching on the wiki. There are several different "reference" sections that all have varying information. I'm happy figuring things out through experimentation, but I wish it were easier to find basic information for getting started. Maybe that'll be my next GarageGames post.

Week 18 (!) -- Torquey Torque

Regular posting resuming in 3 ... 2 ... 1 ....

And we're back. I've been getting a bit of work in learning my way around TGB better. Did some with changing levels and controlling the camera. I found that you can make several distinct areas in the same level file and set camera limits so the camera doesn't slide over to the next area. I'm not sure whether it's better to make one big level for all similar areas or to make a separate level file for each area.

A bit of study on object layering. Figured out how to set up the layer sorting so that it'll come out right for a three-quarters view (meaning that objects in front are drawn in front).

And am currently learning TGB GUIs and the GUI Builder. This part is going better than I expected from my initial experience. It seems pretty powerful and usable so far.

I'll probably skip some of my planned study topics and return to the main project sooner than planned to help out the schedule.

I don't want to go in the cart

No, I'm not dead, and neither is the project. However, between family matters, busyness, and general lack of motivation, I haven't gotten anything done lately. I hope to have better news soon.

Week 12 -- Be more studious!

Nothing interesting to report this week. Just working on learning TGB and TorqueScript as planned. I've been somewhat unmotivated (and distracted by Puzzle Pirates), but it's going OK. I think I understand datablocks now. It seems that they may be useful for making a class hierarchy of enemies, for example, but only for data. There doesn't seem to be full class polymorphism in Torque, unless I'm missing something; you can assign a class and a superclass to each object, but can't actually define a class hierarchy.

So things aren't very exciting right now, but I think it's a good step to take. I'm basically learning how to use my toolbox before I try to build the house.

Week 11 -- Regrouping

That's me regrouping, not something happening in the game. Between being very busy at work and some family matters, I did very little on the project over the last week.

I've realized that it would be very easy for me to spend an endless amount of time learning TGB, and let the project die without even realizing it. "It's OK, I'm learning Torque. I can get back to work on the main project any time." So to avoid that, I'm going to follow a strict schedule and list of what I'm going to learn, and it's focused on the most important things that I'll need to know.

And I'm going to post it right here to help hold myself accountable (and it may be interesting for anyone else in a similar situation):

	Est. hours	Task	Notes
2		datablocks
2		moving between levels
2		layers	and getting objects to sort well in a three-quarters view
1		object groups
4		GUIs and GUI Builder
2		object pathing
2		camera movement	and following an object
2		behaviors
2		mounting objects
1		timers
1		mouse input
1		t2dSceneObject
2		tile maps
1		SimObject
1		SimSet
1		t2dPath
1		t2dSceneGraph
1		t2dTextObject
4		Misc class/function experimentation

(Sorry for the ugly formatting on the tables, can't take time to fix it.)

And the upcoming part of my schedule, for good measure:

Start date	End date	Hours	Task	Notes
09/19/2007	10/13/2007	33	learn TorqueScript/TGB
10/14/2007	10/28/2007	24	core battle system	attack, magic, tech, shield, knock-back, wait time
10/29/2007	11/02/2007	6	basic navigation	move b/w areas
11/03/2007	11/13/2007	16	dialogue/narration and events
08/21/2007	11/15/2007	24	all content for intro	introductory area / “first five minutes”
11/16/2007	11/28/2007	16	character ability up, change equipment
11/29/2007	12/06/2007	11	allies + basic AI
12/07/2007	12/09/2007	4	passive abilities
12/10/2007	12/13/2007	8	enchantments	basic/instant only for now
12/14/2007	12/17/2007	6	generate enemy groups
11/16/2007	12/20/2007	24	content for first major area

Between falling behind and adding time for studying TGB/TorqueScript, my schedule has slipped about 6 weeks from the original plan. That's sobering. It looks likely that my final product for the contest will have to be only part of the full plan for the game. If so, I'll definitely go for a more polished but shorter portion rather than longer but unpolished. We'll see how it goes from here.

Week 10 -- Special attacks, varied enemies

Last week: Lots of fun with my battle system prototype, and a change of plans.

I added two special attacks (you build up to a special attack by hitting the enemies with normal attacks or your fire spell) and a couple of small touches (enemies bounce back when they run into you, etc.).

So I was finished with my originally planned features for the prototype, but not satisfied. I decided that I need to make it more interesting to be able to evaluate whether the ideas are really going to work. So I added multiple enemy types. We now have: normal, physical (resists physical attacks), spitting (fires projectiles, which you can block with your shield -- oh yeah, I added that too), magical (resists magic, fires spells at you), and tough (fast, hits harder). This was a lot of fun. My eventual goal here is to test out throwing a variety of battle situations at the player and hopefully require different approaches.


(Illustration: special attack 1, which knocks the enemies way back. You can also see a brown enemy shot and the end of a dead-enemy-go-poof animation, which was one of the details I added mostly for fun. Remember: placeholder art!)

I've added a couple of things that are more polished than what you might expect from a prototype, but they're all things that I'll need to do eventually and wanted to learn. For instance, I added a charge-up meter for spellcasting, which was fun -- and helpful for verifying that the spellcasting state handling was working properly. And now that I have multiple enemy types, I need to make it pick a group of opponents to meet a given total "challenge level," which is something I'll need to do in the real game too.

I continue to feel that I don't know TGB and TorqueScript nearly as well as I need to, so I'm rethinking my schedule. I'm afraid that if I try to start on the full game now, I'll make bad design decisions and waste a lot of time. I strongly suspect that I implemented the multiple enemy types prototype poorly. So I've decided to step back and take a couple of weeks to learn TGB better, the various builders and key features such as datablocks. I'll probably try to incorporate the things I learn into the battle prototype or other mini-prototypes to keep my morale up. My hope is that the time I spend on this now will pay for itself in faster and more maintainable development in the end.

Week 9 -- Magic prototyping

Well, I'd hoped to finish my battle system prototype for this weekly update, but I have to admit defeat on that. I spent the last week adding spell-casting. (Just one fire-thingy spell. The point is to try out the casting system, not the spell itself.) The first steps went fine. But then I decided to try making it so that you can move, pausing your spell preparation, then resume when you stop. The state handling involved there is much more complicated than I'd realized, and I foolishly charged ahead instead of stopping to analyze it properly. The result still mostly works, and is kind of cool, but weird things happen. (Casting resumes when it shouldn't, sometimes it suddenly indicates that a spell is instantly ready and will cost -4 MP....)

But in the larger perspective, the prototyping is going well and is definitely successful. Just today I discovered that it's probably a bad idea to make you stuck in place while casting, which was my original thought for the most basic casting ability. Too annoying when the enemies are coming for you, especially if getting hit cancels your cast, which I think I do want to do.

I think I should go ahead and prototype all three main options for movement and spell-casting:

1. Cannot move while preparing spell, stuck in place.
2. Can move, but casting pauses while moving and resumes when you stand still again.
3. Can move, spell preparation continues.
   

Who knows, I may wind up just going with #3 anyhow. I want casting a spell to be somewhat challenging and dangerous (in that you're more vulnerable while preparing the spell), but not frustrating.

I continue to struggle with not knowing what all is available in Torque. I often find myself thinking that there's probably a built-in function to do something gracefully, but I don't even know where to look in the reference. Perhaps I should budget a couple of hours every week to just experiment with Torque and learn it better.

So I've fallen further behind my schedule. My goal this week is to absolutely finish the prototype and get started on the real game. I'm facing a schedule slip on my introductory-area milestone unless I have a very productive couple of weeks.

Week 8 -- Knocking each other around

The battle prototype came along nicely this week. I added the "wait time" in between attacks (preventing button mashing) and made so that you and the enemies knock each other back with each hit. (I also added not-yet-used displays for MP and SP.)

For the wait time, I realized that I really needed to add some simple state tracking to my player and enemies. In the process, I also cleaned up a couple of details, making it so you can't move while swinging your sword, etc. So far the player has an action state that is either ready, mid-attack, or wait ("cool-down" if you will), with more coming for spells and stuff later. There's also a just-got-hit flag (can't control your movement or attack while you're getting knocked back).

Had some trouble getting the knock-back effect right. It was easy to just knock you straight left or whatever, but I ran into problems trying to knock you back away from the direction of contact. First I tried taking the normal from the collision callback. That worked if you were standing still (after I fiddled with the collision settings), but sometimes would make you go backwards. Not sure why. I eventually got something working with some trig after some trial and error:

%rise = %dstObj.getPositionY() - %this.getPositionY();
%run = %dstObj.getPositionX() - %this.getPositionX();
%collDeg = mRadToDeg (mAtan (%rise, %run)) - 90;
%this.setLinearVelocityPolar (%collDeg, 20);

I think it needs the - 90 because in TGB 0 degrees is up instead of to the right. Or something. It's past my bedtime.

So now you fly backwards when the enemies run into you, and they fly backwards (away from you rather than your sword itself) when you hit them. That was cool.

I also made the enemy movement a bit more interesting. (I had to in order to knock them around. I had just been doing a moveTo and forgetting about them until they arrived, but they might not ever get there once the player started knocking them around.) So now they move towards you in "hops" with regular pauses. Then I was having fun so I made them sometimes take a longer pause and then lunge extra-fast! Yikes! Fun stuff.

There's still not much to see from a screenshot. Maybe I'll figure out how to take a movie sometime soon.

I'm about two weeks behind on my schedule. I'm still going for completing a rough, rough draft of the opening by the end of September. I'm feeling unsure about the plot, specifically the details of how the story starts off. So my "first five minutes" milestone will be more tentative as far as what exactly happens -- I'll use more "placeholder" type dialogue and areas rather than spending significant time on the details of something I'll likely change later.

The final steps for the battle system prototype are the spellcasting system and special techniques. That covers all the things I want to test out, and will set me up to take a running start at the real game.

Week 7 -- How many HP do I have?

Well, it was indeed a busy week, but I got a bit of time for the project. I spent most of it learning about TGB GUIs. Seems powerful and potentially handy, but I found the GUI builder distressingly buggy. I still managed to add a Hello World pop-up. (Handy for distracting you from fighting the demo enemies!)

My main goal was to add a couple of stat displays (HP now and a couple more later) to the battle system prototype. I figure it's time well spent as I'll certainly need those skills for the real game. And so there's now a working HP display in the corner of the window. And I wound up not even using a real GUI for it. =) Oh well.

So I've got catching up to do this coming week. Fortunately work looks more under control, I hope, so we'll see.

Week 6 -- Battle prototype baby steps

The bad news this week was that I was pretty busy and didn't find much time for the project. The good news is that I stayed somewhat on-schedule because the tasks I did took less time than I'd estimated.

I improved the battle system prototype a bit. Now it spawns multiple enemies, one wave at a time. The most interesting stuff happened behind the scenes here -- I had to learn some more about TGB and TorqueScript to get this working (mainly, dynamically creating the enemy objects rather than placing one in the level builder). Also, both the enemies and the player now have HP rather than dying in one hit. And the enemies freeze momentarily when you hit them. Also, everyone's momentarily invincible after getting hit (to prevent the constant collision from causing many rapid hits). This is a temporary quick measure; I want to later do something more sophisticated, like that each attack can only hit you once, but another enemy's attack can hit you any time.

The final bad news is that I'm extremely busy with work-work, so the outlook is grim for this week. We'll see.

Week 5 -- Planning

This week was a bit slower. I took a bit of a breather after working hard to get the design document out the door. I spent my time listing out all of the tasks I need to get done -- and boy is there a lot to do -- and estimating how much time each would take.

From there I drew up my schedule. So here's my plan: About 2 weeks prototyping key features of the battle system to see if they'll be fun and workable. From then through the end of September, implement the basic battle system, dialogue display, and navigation between areas, and come up with (rough) content for the introductory sequence of the game. This will give me a rough draft of the "first five minutes" of the game, a concept of Jay Barnson's that I think will be useful for focusing my early work.

October through mid-November: System for improving character powers (raise attributes, learn abilities), ally characters, various other things, and content (areas and enemies) for the first major exploring-type area.

My schedule may slip from tasks taking longer than planned and/or me having less time than planned. If my schedule slips more than a couple of weeks, I'll have to revise my plan and think about making some cuts. The ultimate contingency plan is to scale back the contest release to be a demo rather than the full game. Instead of trying to dash off content for the entire plot, I can cut it back to only the first "chapter," or first couple of areas, or whatever I can do well in the time I have.

After my mid-November goal, I have about 3 months to add more features and content. I want to wrap up major additions by mid-February and get the game semi-stabilized for the start of alpha testing on March 1.

Yikes. Well, here I go!

Concept sketches, schedule

Well, midway through making my task list and schedule, I'm feeling even more overwhelmed by how much there is to do. Yikes....

Here are a couple of my early concept sketches. First, the general main screen / battle concept:


And a couple of menus ... but I have a feeling I'll wind up doing something pretty different for a lot of these functions.

Development Diary Week 4 -- Design doc finished

Well, I finished the (first version of the) design document. I was too far behind and wound up a day late, but oh well.

I decided to focus my design document better by concentrating on my target audience. My primary target is, well, me. Its main purpose is to keep me focused on where I'm going, what's most important, and how I'm going to get there. The secondary audience is a hypothetical one. If I suddenly had to pass the project off to another developer or team, the document should guide them well enough that they'd eventually produce a game that's generally similar (in gameplay and plot) to what I have in mind.

I've started keeping a record of hours worked by task. I think this will be useful for 1) auditing how long a task takes me compared to my estimate, to aid my planning; 2) seeing how much time I'm actually able to spend each week.

I'm not satisfied with the menu layout and operation that I've designed so far. Some of the screens (mainly the ability learning one) seem clunky and hard to use. I think I'm going to have to wait until the game engine is fully built so I can get a sense for what the player does most often and try to make that more convenient. Corollary: Don't spend a lot of time tweaking the menus!

I still have a lot of details to flesh out in the plot. I've got a pretty clear idea of the beginning and the endgame, but only a general outline for the whole middle of the game.

In general, I'm feeling alarmed at the prospect of how much content I have to come up with in every area. ("Have to" in the sense of reaching the minimum level of variety that I'll consider adequate.) Spells, special attacks ... and I've barely thought about run-of-the-mill enemies.

I think my next step is to step back a bit and do some planning. I'm going to draw up a "triage guide" for all of the features I want to include. I'll use it as a guide to try to work efficiently by doing the most important and/or fastest features first, preparing for the likelihood that I won't get to everything (sniff). Then I'm going to make a schedule: need to have X feature done by this date, after this milestone date, need to stop adding features and just add content. I'll have to follow a careful plan if I'm going to actually get this done, especially considering my late start.

Development Diary Week 3 -- Design doc, beginnings of battle prototype

Fresh off my successful three-evening computer rebuild (could have been much faster, but it was my first time so I was super-paranoid), Last Ancient is moving forward again. I worked on the design document and started a prototype of the battle system. I met my goals for the week, although just barely.

Design Document

Got the actual design document started. Spent a lot of time listing planned character abilities. One problem I noticed is that it's easy for me to think of powerful spells and special attacks, but harder to think of simple ones suitable for the earlier game.

The ideas just keep coming when I'm thinking about spells and attacks for battles. This confirms my decision that "fun battles" is my top goal for the game.

I'm pretty sure that I have way too many ideas planned and will have to make some wrenching cuts as I go along. I think for now I'll go ahead and put everything I want in the design document and start making cuts later on after I'm in main development and have a better sense of how much is feasible.

Character Abilities

Selections from the Abilities section of the design document:

Beating enemies (and doing other stuff?) gets you Ability Points (AP), which you spend to raise your stats or learn new abilities. You can learn new special attacks, weapon techniques, magic spells, or support abilities. Or you can improve one of your existing abilities, like making your Fireball spell cheaper, faster, or stronger. The key idea here is to let the character specialize in certain abilities (meaning he'll clobber some enemies but maybe not have much to do against others) or be more diverse (or jack-of-all-trades, depending on your viewpoint) as the player chooses.

Note that spending AP is the only way that stats are permanently raised – there's no “level-up” process or anything else that automatically raises stats. Player has to balance raising stats (general character improvement) or learning abilities (more specific usefulness).

Special attacks should be usable frequently (several times in a battle); they are not occasional things that are hard to build up to (e.g. Limits/Overdrives in Final Fantasy). Ideally they should be used for a momentary boost to turn the situation in your favor. (Knock a tough guarding enemy out of the melee temporarily so you can take out the others, suppress enemy ranged fire so you can close in safely, strike down the troublesome armored enemy, that sort of thing.)

Special attacks:

• (weapon type) flurry: no wait time between (weapon type) attacks for a certain time

• (spell type) flurry: no wait time between (spell type) spells for a certain time
  

• shield blocks more/unlimited attacks for a certain time

• Lunging sword attack

• Several rapid sword slashes

• Double spell: Next spell cast fires twice rapidly (no MP cost for second one?)

• No MP cost for a certain time

• Hard hit: attack with greatly increased knock-back

• Piercing strike (normal damage against Armored target)

• Critical: ignores several pts. of target's Defense

• Sure shot: arrow automatically strikes nearest enemy

• Spinning sword/axe

• Spear spin: spin defensively in front, deflect all weapons/projectiles for a certain time

• Great Guardian: automatically intercept all attacks against nearby allies with shield for a certain time

• Light Burst: sword shoots beams of light in all directions

• (other such “Super” attacks)

“Super” attacks such as Light Burst shall be expensive to learn such that a normal character will probably have only one or two.

Spells (many of these are tentative / for example):

• Fire Shot: fire attack flies straight across screen

• (similar simple ranged attacks for most/all elements)

• Lightning: lightning bolt strikes spot at certain distance in front of caster

• Fireball: fireball flies straight, detonates on striking enemy/obstacle

• (Element) Field: creates stationary magic field around player that has some of the following effects (TBD): weakens/dispels spells of the inferior element, provides permanent duration for enchantments of that element, allows casting of advanced spells of that element, has permanent duration as long as caster remains in field

• Barrier: magical wall, works kind of like a shield but wide, blocks physical/magical attacks but loses strength with each hit as well as time – may want several power levels and specialized varieties (strong barrier against fire magic, etc.) for this

• Dispel: (large-ish) spell flies straight, weakens/destroys all enemy attack spells or enchantments that it hits

Inherent:

• faster MP recovery

• less/no wait before MP recovery begins

• increase (weapon type: sword/spear/axe/etc.) damage

• reduce wait time after (weapon type) attack

• able to resume casting spell after moving

• able to move while casting spell

• less/no chance to lose concentration (spell canceled) when struck while casting

• Pierce Elemental Field: Your spells can go through a field of the superior element without getting dispelled

Battle Prototype

I spent some time learning basics of TGB and GIMP, building up to start prototyping the battle system. My immediate goal for this is to try out the key ideas and make sure they seem like they'll work, so that I don't sink a lot of time into a design element that wasn't such a hot idea.

So far, the demo has a player character who can move around and make a momentary sword attack. (Yeah, he's stuck facing right, and he can leave his sword in mid-air and move away, and....) There's an enemy who makes a beeline for the player. If the enemy hits a sword attack, he dies and restarts from another spot. If the enemy hits the player, the player vanishes.

So it's not much at all, but it's the first step. I was pleased by how quick and easy it was to put together in TGB. I still feel that I don't "get" TGB, how the objects, scripts, and levels relate to each other, or what the "right" way is to design everything. But I'm finding it pretty easy to learn so far.

OK, one screenshot.

WARNING WARNING BAD PLACEHOLDER ART AHEAD



Next Week

I've got less than a week to submit my design document. (I might be better off points-wise turning it in a bit late, but it's important to me to hit the deadline.) I may work on the battle demo too, but I'll have to manage my time very carefully. (Focus on just testing the ideas as quickly as possible, not tweaking things to be more polished. It's a prototype, self!) This will be a tough week.

Development Diary Week 2 -- Nothing to see here, move along

This will be a short update. My plans for big productivity Friday died along with my main computer's motherboard. So all I have this week is a couple of minor design thoughts.

• Magic and MP: I want to allow characters to cast spells without MP at a penalty, to avoid the phenomenon my friend Dustin pointed out where you never use your cool magic because you're afraid of running out. I'm tentatively thinking that you can cast a spell instantly by spending MP, or you can spend time charging the spell (gathering magic power, if you will) to reduce the MP cost. If you have no MP stored, you can still cast a spell, you just have to charge up the full amount first.
• Normal battles will range from a couple of easy enemies to lots of and/or harder enemies. This works with the above idea of your MP being stored-up quick extra firepower.
• I'm toying with the idea of making it so in order to cast the more powerful spells, you first need to cast a "field" of that element around yourself. My idea here is to add a tactical / positioning issue to your strong abilities -- if you get knocked out of position, you can't do what you were planning to.
• In general, I think it's interesting for battlefield positioning to be tactically important. Nope, no more detailed thoughts on that, just a principle on my mind.

So my goal last week was to get the design document started and make a schedule. Fail. So this coming week my goal is to catch up on that, and also get a decent start on a combat mock-up in TGB. (Decent start = player character able to fight and defeat at least one enemy, enemy able to fight and defeat player.) But before that, I have to fix our main computer, so I'll bid you good night.

Development Diary Week 1 -- Basic thoughts

Here we are with my first weekly entry. So far I haven't accomplished anything concrete. I've just been thinking through the plot and gameplay, getting ready to write my design document.

Basics

The main game screen will be a third-person top/three-quarters view of the player character and surroundings. Settings will be general fantasy fare: castles, fields, forests, caves, etc. The player will visit towns etc. and talk to people to learn about what's going on and buy equipment.

A lot of time will be spent in battle against enemies (monsters, enemy soldiers, etc.), usually while traveling or exploring caves etc. Battle will be real-time action. I'm going for a bit slower, more tactical pace to the action, not a full-speed frenzy. The player will earn experience through battle (maaaybe also sneaking and other non-violent approaches, but that'll probably be too complicated for me to include) for increasing his power and learning new abilites. The player will also increase his power by buying/finding better equipment and magical items.

I'd like to include some puzzles and problem-solving to add some variety, but at this point I'm really not sure if I'll be able to include that.

I haven't decided whether you'll have a party or just one character. I'd really like to have multiple characters, but I'm afraid it would add a lot of work to implement (especially the A.I. for controlling your allies in battle).

(A note about pronouns: I noticed that I'm writing "he" for the player / main character. At this point, I'm thinking you'll have one main character as opposed to choosing one of several characters to be your main one. And he'll be a guy. Write what you know, right?)

Plot

The main character will begin the game as a soldier in his country's army, probably one who's just been drafted into service. This gives us a game opening where he goes through some basic combat training (probably a "go through my monster-infested training course" type of thing) to get the action going right away. The opening also needs to immediately set up the beginning plot situation -- why are we going to war? What's going on?

The overall plot is still unsettled, but I've got a couple of basic ideas decided. There's this guy known as the Last Ancient. Eventually it turns out that he's the lone survivor of an ancient race -- we're talking maybe dinosaur era here. He's come to the present day (suspended animation? just a spirit? near-immortal?) and is beginning his plan to revive his perished race. This plan will not turn out well for humanity, as you might guess. (It doesn't occur to him to care -- being from a much earlier species, he views us as just overgrown rodents.) He believes that the strongest (that's him and his people) should rule, and that the end of his race was contrary to the proper order of the world. It should never have happened.

So what's his plan? Um, that's what I still need to work out. It needs to lead to a good starting situation for the game. And it needs to provide good reasons for the player to travel to various places around the world. More subtly, it needs to be resolvable without requiring any crazy scenes or situations. (It could be fun to have a mass battle sequence, but am I really up for implementing something like that? No!)

I really want to avoid falling into the Collect X Special Items / Visit X Special Locations plot structure. I think we're all tired of that. But if I can't come up with anything better, oh well. I can't afford to aim for perfection here.

Battle Mechanics

The player should be able to dodge or block most if not all enemy attacks. That's a critical part of making action fun. Because the main character will start off as a generic soldier/swordsman type, the "default" defense will be a shield. I'm leaning towards having the shield be passive defense (it's always protecting your front when you're not attacking) rather than active defense (need to make a control action to block), but I may change my mind, especially if I add other advanced defensive abilities like barrier spells.

The player will need to make real-time actions to swing his sword at the enemy, cast a spell, and so on. Attack spells will vary in size and movement. Generally they will not be automatic hits, but will fly across the screen (or whatever) and hit the enemy or not.

I'm tentatively thinking that the player will charge up special attack points with normal hits. Special attacks will range from mundane ones like jump slashes and double slashes to more spectacular super attacks.

Spells (most spells?) will take time to cast (charge up) before using. There may be quick/instant weak spells and stronger more time-consuming spells. Magic consumes MP and is limited by your MP supply.

I may make a combatant go through a significant (a second or two) cool-down before making his next action. This cool-down, if any, will be whatever it takes to establish the moderate pacing that I want for the action.

As for damage calculations and such, right now I'm thinking to make them non-variable, that is, you know that it always takes 3 hits to kill So-and-so's. Not sure yet.

Puzzles / Obstacles

I'd like to include some puzzles and problem-solving to add some variety, especially when exploring ruins and such. Unfortunately, I haven't had a lot of ideas for this yet. Maybe I'll provide a wide variety of tools and magical items for solving obstacles, provide the obstacles, and not worry so much about scripting one "right" way to get through every area. For example, there's a high ledge. You can just take the long way around through the corridors. You can find the hidden switch to drop a rope up to the ledge. Or maybe the player uses his tree wand to make a tree grow on the ledge and grapples up to it, and maybe I never even thought of that solution -- great!

It seems like I'm thinking mostly in terms of optional obstacles / shortcuts. The player should get a hefty bonus (experience?) for cleverly skipping part of the "normal" path through an area.

Abilities

Experience lets you raise your stats or learn new abilities. You can learn new special attacks, weapon techniques, magic spells, or support abilities. Or you can improve one of your existing abilities, like making your Fireball spell cheaper, faster, or stronger. The key idea here is to let the character specialize in certain abilities (meaning he'll clobber some enemies but maybe not have much to do against others) or be more diverse (or jack-of-all-trades, depending on your viewpoint) as the player chooses.

I'd like to include non-combat ability sets, such as forging equipment, enchanting magical items, and so on. Again, not sure if it'll be feasible to include that.

Some abilities may have other abilities as prerequisites. But I think I'll keep that pretty minimal and instead make it easier to pick a varied set of abilities.

Conclusion

Well, this turned out a lot longer than I expected. Guess that's a good sign. My goal for next week is to get the actual design document started (possibly just this post copied and expanded). I should make myself a schedule too. Thanks for reading! If you have any thoughts or suggestions, please feel free to comment.

Introduction

Hello all. This blog is for the game I'm going to make for an entry in the 1 Year Dream Game contest, tentatively titled Last Ancient. This is where I'll post my regular development reports.

The game will be an action RPG along the lines of the Seiken Densetsu series (a.k.a. Secret of Mana, etc.). The plot will ultimately involve the Last Ancient of the title and his catastrophic attempt to revive his long-perished race -- at the expense of humanity. I'm thinking the gameplay will be heavy on combat, although hopefully with some interesting puzzles for variety. You will be able to choose which abilities your character should develop, weapon, magical, support, etc.

This is a solo effort, and my most ambitious game project in years, so I'll have to keep it fairly small and simple. I'm mainly doing this to motivate myself to get started making games instead of just thinking about it -- "throwing my hat over the fence," as Jay Barnson put it. The hardest part for me will be keeping my plans simple enough to actually get it done.

placeholder

Ignore, placeholder for image upload.