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.
Wednesday, September 26, 2007
Tuesday, September 18, 2007
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):
(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:
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.
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.
Monday, September 10, 2007
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.
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.
Tuesday, September 4, 2007
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:
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.
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.
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.
Subscribe to:
Posts (Atom)