Wings of Albero Development Blog

Firing up the engines

2008-08-11T21:52:00.000-07:00

After about three months of being mostly on hiatus, I'm getting back to work. I'm currently making a detailed plan of what exactly I'll be putting in the rest of the game, mainly what new enemies to make. I'll post my detailed task list when it's done for anyone who's interested.

The most important thing is for me to remember that this is meant to be a beginner project, and it's okay for it to suck. Hopefully it won't, but I just need to get it done in any case. My perfectionist streak is part of why I've been taking a break. Gotta fight that.

Version 0.900, and a real web site

2008-04-30T23:59:00.001-07:00

Sorry for the radio silence lately. It's way past my bedtime, so details will have to wait, but for now: Version 0.900 is out. Head on over to the new web site and try it out.

Week 39: Life intervenes

2008-04-02T19:16:00.000-07:00

I've been sick and busy, my wife's been sick and very busy, and our poor doggie's been very sick. In short, I haven't done much on the project lately and haven't touched it for a few days. All I've done is some planning, and made some design decisions I'd been putting off. Most notably: No healing magic; various potions for healing and other effects, bought with money, no inventory limit, so balanced by money resource instead (this means I'll have to balance the player's money carefully, but that shouldn't be too hard); arrows cost money per shot but have no stock limit (like in original Legend of Zelda). You may notice that in all cases I've chosen the easiest and simplest design option out of the ones I've considered. Yep. No time to make things any more complicated than they need to be.

Week 38: Slime and Boomerang

2008-03-23T20:41:00.000-07:00

Kind of a slow go on Wings of Albero this week, not helped by some general time-wasting on my part. I added a new enemy, a slime, and the first item ability, a boomerang attack a la Legend of Zelda. And a couple of new functions that aren't worth talking about.

So now we have slimes. I wanted them to split when you hit them, but ran into some nasty problems with TGB's collision physics response. Once there were several slimes close together, when a new one got placed they'd all go flying around like crazy and sometimes warp through walls. Not good. There are a couple of ways I could work around it, but I'd already wasted a couple of hours messing with it and it wasn't worth it. So, no splitting enemies this game.

The boomerang is the first item you'll probably find, in the jail cave. It normally stuns enemies for a couple of seconds. Some such as the knights are immune to it. The slimes are weak to it and actually take high damage from it, whereas your other attacks aren't as effective against them. (This is my substitute way to make the slime type interesting now that the splitting idea is dropped.)

Now I just have to make a way for you to actually GET the boomerang, and I'll be ready to move on to shopping, arrows, healing abilities, and I'd better get started on the further areas of the game soon....

Week 37: Smarter enemies, second alpha

2008-03-17T16:02:00.000-07:00

Huh, guess I should make my official Week 37 post here. As everyone reading this has probably already seen, I put out the second alpha release this weekend. Most of the work I did was making the enemies smarter and aggressive rather than just random. It's been an interesting challenge figuring out how to make fun, varied battle gameplay with this contact-attack battle system I've chosen. I'll probably have more to say about that as a post-mortem once we can see how well it turns out in the end. =) Now it's time to charge ahead with more features -- chiefly sub-weapons and other items, shopping, and equipment upgrades -- and more content.

Alpha 2 released, and we've got forums!

2008-03-15T13:00:00.000-07:00

Alpha version 2 is out. There is no additional content whatsoever in this release. *pout*

The main change is a drastic change to the behavior of all the enemies, making them much smarter and more aggressive. See what you think of the battles now and please share any suggestions. Also please tell me if it's too hard now! Remember, this is still the early part of the game, so I want the enemies to be interesting and to seem like they're actually trying to fight you, but not to be terribly dangerous overall.

Other changes:

your shield blocks shots only when standing still
you now bounce back slightly when attacking an enemy
changed damage formula so that damage starts falling off more slowly once it's below 1/4 attack power
various uninteresting bugfixes (note to self: if you're going to put in temporary code, mark it to be fixed later)

The alpha testing page with the game download has been moved to here, a post on our spiffy new forums. Enjoy! (I hope.)

Update: Video!

Wings of Albero (action RPG): smarter enemies (alpha #2) from Griffin Knodle on Vimeo.

Money

2008-03-11T17:04:00.000-07:00

I've been thinking about ways to avoid that weird RPG tradition where everyone still charges you money even after it's clear that you're the only hope to save the world, etc. I've been thinking over systems where the villagers will help you for free, but you need to find the materials they need to make you equipment, potions, etc. Problem is, everything I've thought of so far is, on further review, either too restrictive to be interesting (you find some iron; would you like to use it to upgrade your sword, armor, or shield?) or functionally equivalent to money except more complicated and annoying to handle (you find an iron ingot and can turn it into some iron arrows or save up several for an iron sword, and also you find various herbs that you can turn into potions or save for magic training later, blah blah blah).

So enough. I'm now working on talking myself into giving myself permission to use a perfectly ordinary, perfectly serviceable money system. This sort of thing is difficult for me....

Week 36: In which nothing much happens

2008-03-09T21:35:00.000-07:00

I've been busy with work work and catching up on all the things I neglected with the house during the push to alpha #1, so haven't made any progress on the game lately.

One of my friends brought up a tricky issue with the magic system I have planned. Your magic resource will be a fairly small stock that recharges quickly when you're not using it (already roughly this way in alpha 1). The desired gameplay result is that you'll be free to fire off a few spells when you decide that you need a boost in battle; you'll have to wait a bit between rounds of magic, so you want to choose a good spell at a good time and make it count; and you recharge fast enough that you might easily fire off two rounds of magic in a normal battle.

The tricky issue comes in if I provide any kind of healing magic. If your magic is unlimited and recharges quickly and you have a healing spell, then you have full recovery after each battle, which I don't think I want. But how to avoid that dynamic? I currently have these main ideas:

No healing magic. The obvious and easy solution. Your health recovery is limited to a consumable healing item or limited stock thereof.
Healing magic causes some kind of longer-term resource drain. I'm already considering having a "fatigue" penalty that you accumulate when you use your entire magic charge at once, probably something like making your magic recharge more slowly. Healing magic could always cause fatigue. Or another effect such as reducing your maximum magic charge until the next time you rest in town or whatever.

The general idea is to add a downside to healing magic so that one wouldn't always want to heal up. But having the downside be some effect that weakens your character doesn't appeal to me so much, because I want you to feel free to use magic frequently without worrying about a long-term strategic resource (such as MP in typical RPGs), and in general I want to avoid the "dungeon of attrition" model that many RPGs follow.
Healing fully will put you at risk to get attacked by more enemies before you're done. Maybe if you sit around for a certain time period, there's a continual chance for enemies to appear from one of the area entrances (with the certain time period such that it takes you longer to heal up from serious injury). Or, if you take some kind of fatigue penalty for magical healing, you can rest to recover from fatigue, but there's a chance for enemies to appear every time you rest.
I just thought of this one, so it's totally not thought through: Healing magic temporarily reduces your maximum health each time you use it (or, healing magic becomes progressively less able to restore you the more you use it, to think of it that way).

I'm also thinking of how to restrict healing items (assuming I have some). I just want to avoid the "99 Heal Potions on the wall" syndrome. I keep thinking to limit your inventory space in some way. One thought is that you have a limited total capacity for consumable items ... which are basically "healing items and arrows" in this game, so making a pooled carrying capacity doesn't add much interest here. Better is to just limit how many healing items you're allowed to carry, probably by you having only a certain number of potion bottles (see A Link to the Past).

I've also thought of making you find ingredients for potions ... but that can suck if not handled well, and is really a way to substitute for money rather than an effective way to limit healing items.

No new alpha this weekend

2008-03-06T19:42:00.001-08:00

On the off chance that someone is obsessively refreshing the page waiting for the next alpha version, I wanted to announce that it will not be out for this weekend. I've been too busy for the project lately, and I want the next alpha to have fixed up enemy behavior and hopefully some more content and features. So probably the weekend of the 14th.

Why does Albero give you Fire magic?

2008-03-03T05:36:00.001-08:00

It occurs to me that because alpha #1 doesn't include any of the backstory, I should explain just why it is that the evil tyrannical wizard Albero is nice enough to leave the Fire magic lying around for you to pick up. Briefly, he was originally a good wizard and a good ruler, but his heart was captured by evil and desire for power. But long before that, he was wise enough to recognize that one day he or a successor might succumb to evil. So that the people would be able to fight against such evil, he left many magical items and powers scattered around the land. (His greatest magical item is the eponymous Wings, which allow a hero to fly to the floating tower that is the center of his power.)

(I may rework the story to make the villain be Albero's successor instead of Albero himself. Haven't decided for sure.)

Week 35: Alpha testing begins, Griffin takes a nap

2008-03-02T20:31:00.000-08:00

I mostly took a much-needed rest today after working pretty hard to get a decent alpha #1 put together. I'm pleased with how it's going so far, but I have a lot of work to do.

It's become clear -- I was feeling it as I finished up the alpha version, and I've already gotten some feedback agreeing -- that the enemy behavior needs to be smarter and more aggressive. Currently, they all just move randomly. I thought that would be enough, considering that I do want these early enemies to be easy. Well, if this were a game where touching an enemy hurts you, then randomly moving enemies might work. But in this one, not at all. They're just not interesting or fun. So this is my #1 major task, even ahead of adding the rest of the planned content (of which there is a lot left to do).

Seems like there were other things that I wanted to ramble about, but I can't remember them and don't really have the energy anyhow. I'll leave you with a video of various clips from a playthrough of alpha #1.

Wings of Albero (action RPG): clips from alpha #1 from Griffin Knodle on Vimeo.

Alpha testing open!

2008-03-01T19:45:00.001-08:00

I've released the first alpha testing version of Wings of Albero. The alpha test is open to the public and everyone is welcome. The alpha testing page with the game download is here.

It's missing a lot more than I would like, but it's got enough that I'm (barely) comfortable releasing it for alpha. The main gameplay is there in something like its intended final form, even though it's short, with most of the planned game not open to the player yet. More details tomorrow.

Onward

2008-02-27T06:01:00.000-08:00

Forging ahead. Here's my hasty but passable art for castles and caves, because I felt like sharing:

Week 34: First area done (pretty much)

2008-02-24T19:13:00.000-08:00

Major crunch time here. Did I mention that art takes a long time? It does. In fact, everything takes a long time. I'm going to have to scramble to get a sufficiently semi-complete game together for alpha testing next week. So I'm cutting myself off in this post. That's all. Goodbye.

Well, first, here's a video of the first area, complete aside from some gameplay details that need to be changed or filled in.

Dev 5: Forest path (first area) from Griffin Knodle on Vimeo.

Week 33: Art takes a long time

2008-02-17T19:34:00.001-08:00

So yeah, art takes a long time, even though I'm just doing pretty simple colored-in outlines. For the player character, it ran me about half an hour for each frame. Now, being the player, that was unusually complex and I spent unusually long fine-tuning details, and I'm sure it'll get faster as I get more practice and nail down my workflow ... but it's taken a long time so far. I'm now trying to figure out all the ways I can cut corners on art requirements (e.g. rather than a typical character having one standing frame and two or three walking frames, maybe I'll just have two walking frames always cycling (the classic NES RPG "guys walking in place")).

I'm pleased with the results so far, at least. It won't win any awards, but it's quite adequate.

There'll be a video along soon as soon as I get the first area all presentable. To hold you over, here's one of my art files for a sample. Yes, you're a standard spiky-haired hero. Why mess with success?

Week 32: Crunch time, crunch crunch

2008-02-10T20:47:00.000-08:00

It's clear that it will be a near thing whether I can progress fast enough to start alpha testing next month on a reasonably complete game. This is despite having cut (well, "de-prioritized," let's say) a lot of features, and looking at probably losing some more. (For example, I really wanted to include a simple version of the flexible ability-up system I have in mind for the full game. But I'm realizing that it's just not as important as a lot of things I initially had prioritized lower. My stand-in "generic level-up" system is by no means bad if it comes to that.)

I'm currently hustling to get the first area put together with its real map, real enemies, and real graphics (that is, the best I can manage for a quick job -- hopefully they'll come out passable) for everything. I've got my three enemies acting right, subject to change. You've got the hoppy one, the stabby one, and the shooty one. (They're all currently recycling my existing animations, making them appear to be horrible misshapen shapeshifting knight-slime things, which is one reason I won't post a new video for a bit. Yes: I'm using my stand-in art as a stand-in for proper new stand-in art.)

I uploaded all of my videos to all of the several video sharing sites I've tried, as planned last week. Sure enough, they've each already picked up a dozen or so views from random people. I have no idea if anyone's clicked through to the blog from a video, much less started following the project. If you're such a person, welcome! Stick around, tell your friends, etc. This video thing really drove home to me that I have to get my art in order. I can write whatever disclaimer I like about stand-in art, but there's no substitute for a good impression.

Finally, yesterday I got my act together to set up proper version management for the project. (After getting mugged by the collision system the other week, I wanted to just roll back to my previous version. Fortunately, I could, from my manual backups, so it wasn't really even a close call, but it could have been troublesome if I'd had a larger problem.) I'm using Subversion, and liking it very well so far. Easy to set up and use, and seems efficient with operations and space usage. Shoulda done it a long time ago.

Week 31: It's a game! It's an RPG!

2008-02-03T20:50:00.000-08:00

I had some good, productive time this weekend. I put in a rudimentary ability-up system (just a plain-vanilla "level up" system, which is not what I want for the real game, but it works as a stand-in), which really made the whole thing come together much better and was a great morale-booster for myself. It now classifies as an actual RPG in my book. Sure, it's very short and simple, and the implied plot is, "Kill the slimes, then kill the red slimes, then kill the knights, then finally go and wipe out the horde of yellow slimes that's grown up in the meantime." But it's a genuine rudimentary action RPG, so it's an exciting milestone for me.

I also added a basic GUI display of the character's condition. Oh, and I also spent a couple of ultimately wasted hours messing with the collision detection, which I'd rather not discuss. >_< Also the yellow slimes now shoot at you rather than always to the right.

So for the contest, the game will definitely be just a long demonstration of the battle system, with as many additional things as I can fit in. At this point the "optional features" list includes things such as "people to talk to," "more than one weapon," and "plot."

Regarding publicity, I had a brainwave this afternoon (that seems embarrassingly obvious in hindsight). The other week I tried a few different video-sharing sites to choose which one to use. So today I logged in to Revver to check something technical. Lo, my test upload ("Knights") had 15 views, and I know those weren't all me. So, brainwave: Why don't I upload all of my videos to several sites? No need to choose only one. And -- hey! -- instead of assuming that everyone goes from this blog to the video, why don't I link from the videos back here too?

Finally, here's a full walkthrough video! Yay! (I'm embarrassed to admit that I got killed twice trying to take this video. I blame the lag caused by the video capture process. Actually, I think I forgot a setting on the knights so that they can hit you rapid-fire if you get stuck against a wall.)

Dev 4: A real, simple action RPG from Griffin Knodle on Vimeo.

Notes--
0:35 - I run because I'm not strong enough to fight the knights yet (did you see my 0 damage?).
2:40 - I'm beaten up enough that I go back to the red slimes before the knights get me.

Week 30: Griffin filibusters

2008-01-27T20:01:00.000-08:00

I was on vacation last week, so have no progress to report, but wanted to post to keep on my regular posting schedule. So I'll ramble on about the main design issue I'm struggling with.

I'm still waffling over exactly how much action and how much RPG I want in my action RPG.

Consider those knights I recently added. Currently, if you run into the sword side, you take a hit, and the knight is unharmed; if you run into any other side, the knight takes a hit and you are unharmed. This is an action-oriented gameplay mechanic [ADDED:] because you have to perform an action-gaming feat to win the battle.

There's another possibility that I've been thinking about a lot, but haven't (completely) implemented (yet). It would work like this: when you and the knight (or other attacking enemy) run into each other head-on, each combatant has a chance to hit the other and/or block the other's attack. I envision that you'd usually parry each other's attacks and bounce back, several times, until eventually one of you won the encounter, and the other took a hit and got knocked backwards.

If you hit the other from the side or back, you always make a hit.

This is a more RPG-type mechanic [ADDED:] because you don't have to perform any action-gaming task except running into the enemy, and can still win; it still has an action element in that outmaneuvering the enemy gives you an easier win. It makes the player's action skill much less important. It appeals to me. But I'm afraid it would wind up feeling like a MMORPG or FF12, only faster, which does not appeal to me. That's why I've been leaning more towards action-ish battles (more towards the Final Fantasy Adventure end than the Secret of Mana / Seiken Densetsu 3 end, to reference one of my touchstone series).

One complicating factor is that one of my sub-goals is to make an "Easy" level that really is easy -- easy enough to be accessible to non-gamers. Action gameplay is a major obstacle to that. I need to figure out ways to make it easy to win and progress even if the player has no skill for the action elements of the gameplay. So making it more RPG-like would help with that.

So. Waffling.

[edited 20080128 0710 to clarify what the heck I'm talking about]

Week 29: More slimes, with reactions and attacks

2008-01-20T22:51:00.000-08:00

I added a couple more battle features and cooked up two more test enemies to demonstrate them.

First, by popular demand and to honor video game tradition, red slimes. They react to the player's presence by attacking when you get close (rather than acting randomly as the original ones do).

Then I started adding the capability for combat creatures to "shoot," which encompasses short-range attack moves as well as projectiles. Demonstrating that, we have yellow slimes who make a sparky-looking attack but have no relationship whatsoever to Pika***.

(The shot should be aimed at the player, but it isn't yet. And I have more work to do getting the collision detection right, and the configuration data setting is a mess and needs to be cleaned up, but I'm out of time for this week.)

Dev 3: More Slimes from Griffin Knodle on Vimeo.

Week 28: More basics, now with knights

2008-01-16T22:21:00.000-08:00

This week I got some good things done behind the scenes (i.e. they won't be obvious from the video, but they were important). The big one was tracking each character's orientation and using that in evaluating hits. The upshot of that is that now you have to actually run into the enemy to attack (rather than before where the slime would get hit even if it ran into you from behind).

I also created a second test enemy to show off the orientation functions: a knight, which you have to attack from one of the non-pointy sides. =)

(Also some small fixes, such as the slimes no longer killing each other.)

New video:

Dev 2: Knights from Griffin Knodle on Vimeo.

Week 27: Battle basics

2008-01-08T21:55:00.000-08:00

I've been working on getting the basic battle system up and running. Right now, it's got endless hordes of cute slimes that you can fight (any resemblance to dangos is quite unintentional). One quirk is that currently they can hit each other as well as you. Oops.

I've also partly made spawn points -- spots on the field that generate new copies of enemies (hence the endless hordes). I still need to make them configurable for type(s) of enemies to spawn and conditions for spawning.

Feels like things are going slowly, but I have a good feeling that I'm setting up a good foundation that will let things go quickly once the basics are done.

Finally, I'm semi-proud to present the very first video of this very early stage of development:

Dev 1: Endless Slimes from Griffin Knodle on Vimeo.

Week 26: Vision of the Golden City

2008-01-05T21:04:00.001-08:00

(Late post here due partly to someone putting a backhoe through an important cable, knocking out the neighborhood's phone / DSL -- although to AT&T's credit, they had it fixed in just over 24 hours.)

Without further ado, the new and probably final title for this game:

Vision of the Golden City

In a certain country, many of the children start developing unusual powers as they approach adolescence, gaining powerful fighting skills and other abilities. This always begins with the children seeing a vision of a mysterious city of gold, opulent but empty under a hot sun.

The country often comes under attack by monsters or other nations seeking the power of the city, but the chosen warriors are always able to defend it. It seems as if the Golden City gives the children however much power they need to defeat any challenge.

However, many of the chosen children have noted that they change in strange ways after receiving the power of the city. They no longer feel themselves and some feel separated from the very people they are protecting. What is the truth of the Golden City and its power?

*****

The main character and her childhood friend are two of the newest group of chosen children. As they grow in power, Friend begins acting strangely, desperately seeking still more power because he thinks that he needs ever more to be able to protect the people. The main character will have to discover the truth about the Golden City and her world in order to save her friend and maybe more.

One helpful aspect of this plot is that the middle can be expanded or shrunk a great deal depending on how much time I have to put into it. There's a whole general arc -- exploring, fighting off dangers, gaining power, and Friend losing it -- that can take up pretty much any amount of time and attention, although it will become less effective if it gets too short.

This story takes place in the setting of Last Ancient, but some time earlier than that story. I was having trouble working out the details, and I clearly wasn't going to be able to do justice to the story I wanted to tell in the time frame I had, so it made sense to drop back to a simpler story. (Which is rapidly gaining complexity from some ideas for story elements that I've thought of and quickly gotten attached to. Oops.)

Even if I keep things simple, time is still very short. I think there's a good chance that for the contest I'll do something simpler still: a battle-only game with the battle system fully developed, and basic power development tacked on, but no plot, and with areas, enemies, abilities, etc. likely to change for the real game. My goal in this case would be to make a complete, fun game showing off the battle system, and post-contest filling it out into the complete game I have in mind.

OK, enough blogging for tonight, time to go do some more stuff.

Week 24 -- Basic fighting and more

2007-12-19T22:28:00.000-08:00

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)

2007-12-15T23:45:00.000-08:00

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

2007-12-04T21:33:00.000-08:00

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

2007-11-26T19:58:00.000-08:00

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

2007-11-14T22:07:00.000-08:00

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

2007-11-04T20:47:00.000-08:00

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

2007-10-11T22:13:00.001-07:00

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!

2007-09-26T22:33:00.000-07:00

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

2007-09-18T21:38:00.000-07:00

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

2007-09-10T22:42:00.000-07:00

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

2007-09-04T22:55:00.000-07:00

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:

Cannot move while preparing spell, stuck in place.
Can move, but casting pauses while moving and resumes when you stand still again.
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

2007-08-27T23:41:00.000-07:00

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?

2007-08-20T22:10:00.000-07:00

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

2007-08-12T21:30:00.000-07:00

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

2007-08-06T21:39:00.000-07:00

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

2007-08-01T21:56:00.000-07:00

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

2007-07-31T19:37:00.000-07:00

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

2007-07-23T22:54:00.000-07:00

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

2007-07-15T20:39:00.000-07:00

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

2007-07-04T19:36:00.000-07:00

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

2007-06-29T23:25:00.000-07:00

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

2007-01-01T18:28:00.000-08:00

Ignore, placeholder for image upload.