Super Glyph Quest Dev Diary 03
 |
| Must get Leanne to do a new logo... |
Busy week next week. Not to do with SGQ - the GUKPT rolls in to Brighton and I might be thinking of a cheeky tournament or two. But then I've got that long-awaited hospital appointment on Wednesday to sort out my wisdom tooth at last. That writes off Wednesday and, most likely, Thursday as well. On the one hand, I'm really looking forward to a pain-free existence and the ability to fit food in my mouth again. On the other, I'm not entirely sure I can afford to lose that much wisdom... or money, for that matter.
With all of that in mind, it's been quite a productive couple of days.
Main Loop
The idea was simple: the main game loop steps through a series of phases - everything from spawning the player or monsters to processing their input and effects. There are a series of delays built in, otherwise the whole thing just flies by. Then there are other bits that have to wait for other things to finish, like Effects. I had it all working with some hard coded delays and no player or monster input. It was only when I tried to implement those latter features that it all started going a bit pear shaped.
It was mainly to do with damage resolution. Whenever a Dude (either a player or a monster) takes damaged, they go in to another state - where you'll see them wobble a bit - for a while until finally applying the damage. To prevent the main game loop moving on when it shouldn't, I made it so that all currently active Dudes have to be in an idle state. It keeps everything nice and neat.
Attacks and Effects
I pulled across the Effect System from GQ, then proceeded to gut the thing. The basics are fine - if it ain't broke and all that - but I've pulled out the bits that did damage and status effects and written a new Attack class to handle all of that. Effects are now just that - effects - and the thing that does the damage is the Attack. Much more elegant.
Integrating all of this wasn't a seamless process and there was a spot of negotiation with the main game loop to keep everything swimming along. I also implemented an early-out type affair so that it doesn't always have to wait for the effect to finish completely. This means that stuff like smoke can fade out in its own good time without hampering the gameplay.
Attacks can apply damage to a target as well as confer health to the attacker. In this way they can be used for everything from simple damage to healing to lifesteal type affairs. The original had a system whereby an Effect could do damage several times, for things like rapid fire. For the time being I've abandoned that and just got the Attack applying the damage in one lump at the end. It makes life easier and means that the bug with the flying numbers* shouldn't rear it's ugly head again.
Currently, I've got placeholder Attacks and Effects in for all of the spells and I'll hook the actual content up as we go.
Numbers Game
Actually, along those lines, it's probably a good idea to talk about how we come up with the gameplay content for things like this. The answer is simple.
Spreadsheets.
Spreadsheets are your friend. We've got a doc that houses tons of information. Everything from the various spells we want and their combinations to a neat little table that is filled with formulae for health and damage at various levels.
Firstly, I should state that I'm totally against a completely mathematical approach to game design. To me, it's still an artform. A craft. The idea of game design as science is abhorrent to me. That said, getting some solid formulae down makes a great starting point. Then you play the game and see what it actually feels like. From that point on, you tweak based on your gut and playtesting feedback.
This table enables me to set up things like player health vs the amount of damage a monster of a particular level should do and how much DPS the player will need to pump out to be able to reach the end of the quest intact. If the player ends up with negative health, they will fail the level... or be forced to use healing. What I'm after is some kind of curve that starts off with a very high value (plenty of remaining health) in the early levels but actually goes negative later on in the game, requiring some decent strategy from the player to progress. That works just fine for the first few levels but it gets really complicated when you start introducing Status Effects.
Status Effects
Status Effects refer to things like Poison or Petrification - things that affect a Dude over a number of turns. They are applied as part of an Attack and they work similar to the way they did in the first game only, as you'd expect, in a slightly more elegant fashion. Status Effects can stack and there's a dedicated phase in the main game loop for processing them. Because any Dude can have multiple Status Effects active on them at any one time, this phase needs to loop through each of them. Again, looking at the old code, this got out of hand really quick and was very messy. The new one? Not so much.
Some Status Effects react differently depending or not on whether they've been applied to the player or a monster. For example, Blindness gives a monster a percentage chance of missing the target** whilst it flips the player's glyph board in to question marks. In real terms, this reduces the player's effectiveness in combat. Because it doesn't easily change into a DPS value, assigning a particular value to that in the spreadsheet becomes a bit trickier. Twelvety three. Plus or minus the square root of elephant.
Stat Multipliers
As a precursor to the player being able to equip Gear that will affect his stats, I've put a basic system in place to allow for stats to be altered on the fly. This has also allowed me to have monster variations. You know how Puzzle & Dragons occasionally features "Strong" variants of a particular monster? Well, something along those lines. Except it's not just "Strong" - we've come up with a number of different adjectives. "Tough" monsters, for example, have extra health. "Vicious" ones do more damage and so on. We might even implement "Formidable" ones that have extra health and do more damage. I know, right?
We could go the other way as well - have "Weak" or "Puny" versions. The sky's the limit here. I suppose we're not just limited to physical attributes either. We could have a "Cunning" variant that's more likely to perform attacks with those damned Status Effects in it. Or a "Cautious" one that's more likely to try to heal itself - I know how people love that***. Imagine a Cunning Harpy or a Cautious Troll, for example...
Text
One of the least glamorous jobs is that of text and localisation. As befits the original's thown-together approach, the text was all over the shop. Sometimes it would use the name of the prefab. Other times there would be a string as part of the class. Occasionally it would be in an array somewhere in the code. This meant that when we handed the project over to Chorus to do our Japanese version, they had a hell of a job on their hands.
To make it easier the next time, all of SGQ text is pulled from a single file. It means a bit more work at the beginning but should really pay dividends in the long run and I know a couple of Japanese people who will be very happy with that****. Of course, we knew this is something that totally should have been done anyway with the first one, but we really weren't thinking that far ahead and I was happy to sweep it under the rug.
* Ooh, must remember to implement the flying numbers...
** A though just occurs to me. Now that I've split Attacks up, I can have the monster still Launch their attack but just not play the Hit if they've been Blinded rather than not play anything at all like the first game. Cool. I'll have to write that down too...
*** Actually, less "love" and more "hate".
**** One of their other bugbears was the lack of a centred board when you don't have enough glyphs to make a perfect hexagon shape - something I've also fixed for the new game. It's the little things.
Comments
Post a Comment