Saturday, February 6, 2010

HG101's Own Game - Shining Force Ripoff


I think that, for the most part, anyone that writes about video games really wants to be a designer at heart. What's the point of criticizing if we ourselves did not have some kind of "ideal" game, that we thought we could do better? It was the reason I got into Computer Science, but by the time I got my degree, it was too late for me fully realize that the Real World application of my coding skills was Big Boring Corporate Crap, seeing as nothing I had learned would be much of use in the video game industry. I only found programming fun when it was put to my own creative designs, but the concept of developing web applications and managing databases makes me want to...well, I can't think of a metaphor that isn't super cliche so I'm not even a particularly good writer. But my education didn't go to waste - at least there's Shining Force Ripoff.

Shining Force Ripoff was my Senior Project, the one time I could do design my own project completely. I loved every minute of it. As the name states, it's a strategy game, with all of the sprites and tiles ripped from Shining Force (and a few from Phantasy Star III, I think.) I didn't know jack shit about graphics programming (and still don't), so it was all done in MFC, which was the only way I knew how to handle bitmaps. So it's all very simple - no music or animation, and all of the action is handled via dialog boxes, which can get very annoying depending on your Windows sound settings. My initial versions were actually a little animated - the characters marched in place, and the water currents ran, although they still just jumped from tile to tile, because I never figured that out - but as it turns out the MFC timer function really sucked, and it kept crashing the whole thing after a few minutes, so I took it out.

Despite its simplicity, even playing it now, there are a lot of things I like about it. I've lost the documentation and source code (they might be in a hard drive in a closet, providing it would even still compile nowadays), but here's what I remember. You have five characters, each with different tasks:

Karloth: The "main" guy, since he's the hero of Shining Force (Max, I think?) and the first character you control. He has all-around average stats. But he also has a skill called "Push Back" which will push an enemy back a single square. If they have their back to impassable terrain (or another unit), you'll deal extra damage instead.

Kyo: The tank. Really high attack, really high defense, really slow (single space movement per turn) and no special powers.

Trodgor: Slightly weaker than Karloth, but has a Counterattack skill which is activated every time he's attacked. The damage of the counterattack is calculated by some percentage of the initial attack - I think it's 50%.

Mai: The healer. Low stats all around. She can heal any of your characters, but since I didn't program in any MP, it drains her health instead, again by a percentage I can't remember. She also cannot move and heal in the same turn, one of those things I couldn't be bothered to implement so it became a feature. To offset the health drainage, every time she attacks, she restores some health, again, a percentage of the damage dealt.

Wiggins: By far the weakest character but with the highest movement range. Every attack will permanently drain some of the enemy's offense and defense. But obviously he'll get killed quickly if you don't use him well. There's also a bug in his movement range - since it's higher than everyone else, and I didn't put in a check to look at impassable terrain, technically he can jump over the river and the mountain. I think I called that another "feature" in the documentation, that he has flying skills or something. From a strategic point of view, it would be a bad thing to do, though.

The active unit is highlighted in red, and their movement range is highlighted in white. You move all five characters, one at a time, and then the enemy moves. (The enemy movements happen almost instantly.) If an active unit is placed next to an enemy, you can left click the enemy to attack. You can also right click on any unit for their stats.

There are seven standard enemy dwarves, and one boss monster, which is much stronger than the rest. The game ends when either all of your units are killed, or all of the enemies are killed. Straightforward enough. The terrain modifies the stats, too - the forests raise defense and the paths lower it, I'm pretty sure. So if you're in a forest and you attack an enemy in the path, you'll make a critical hit, and you'll take less damage on the retaliation hit.

Beyond the bugs/features I mentioned, there are still some stupid usability issues. Like the way to instinctively move Karloth on the first turn will always block Kyo, making him useless for a turn. And others, I'm sure. The AI isn't great. It's simple, like the rest of the game. I think it just scans the tiles for the closest target and makes a beeline for them. If there's an impassable tile, it just moves in another direction. It will always prefer a specific direction - I forget which. I think it turned out well, though. Also, the debug function on the menu totally doesn't work at all.

I designed this all around the time I was playing Breath of Fire: Dragon Quarter (still one of the best RPGs on the Playstation 2, and an insane value at Gamestop for $6.) In that game, you only ever had three characters (mostly), but each character had a very specific role in combat. Ryu was the melee fighter, which made him susceptible to damage, but he was also the most powerful. Nina had spells to attack from a distance, but more importantly, traps to set and debilitate enemies. Lin could also attack from a distance, and could push enemies around. You needed to use their skills together for the best effect - like, have Nina cast a paralyze spell behind an enemy, use one of Lin's powers to push them into the trap, then have Ryu run up to smack them a few times before running back, avoiding counterattack. Shining Force Ripoff isn't quite that fleshed out, but you can still see the power of teamwork - for example, using Mai to keep Wiggin's health up, or using Karloth's Push Back to knock enemies in more susceptible terrain.

Like I said, I really like the fundamentals of this! I've been finding myself drawing away from JRPGs in favor of WRPGs nowadays, for any number of reasons, but as much as I'm a fan of just shooting stuff, I REALLY miss the cool turn-based battle systems in the Japanese games. I mean, traditional stuff like Dragon Quest and Etrian Odyssey get passes because they're supposed to be old (or, erm, "classic"), but I much more respect Grandia or Chrono Cross for the ways it played with the standard "line up and take turns whacking each other" formula, which somehow still passes for acceptable game design these days. I want to design something that clever.

The one major, conscious decision I made for this - there are no random number modifiers on anything. If you attack an enemy twice under the same conditions, it will always do the same damage. There is no "agility" or "dexterity", and you cannot miss attacks. I always HATED this, especially in Final Fantasy Tactics or Tactics Ogre. I hated that too much of my fate was in the hands of a random number generator, and it always felt like a stupid holdover from the days of dice rolling. Consequently, this means I can pretty much never play a board game or a pen and paper RPG without getting really pissed off. It's almost always factor in any video game RPG, but it's usually so minor that it rarely makes THAT much of a deal, but I'd prefer to not have it at all.

You can tell some of the things I was playing with around the time I was developing this. Two of the characters are obviously named after King of Fighters characters, and one was named after Strongbad's doodley dragon from Homestar Runner, a favorite of my friends in college. I think there's a Tactics Ogre reference or two in there, too, try to spot it!

Anyway, since the game was programmed by me as a college student, it's probably buggy, and may very well refuse to work on your computer. Hopefully not. Maybe one day I can dig up Virtual Studio again and design another similar battle system. I really wanted to expand on it - add multiple levels and experience gain, stick a status bar on the side, and stuff - but then the whole Real World Job thing got in the way, as it does for billions of other creative endeavors worldwide. My plans for Pride and Prejudice: The Dating Sim also went down the drain, but maybe someday!

10 comments:

  1. Awesome, I always like reading about early or first time examples of game development. There's a kind of purity, or innocence of design, which you don't always find once a developer has a dozen games under their belt. Perhaps they become less conscious of what they're doing because they've got some experience? Regardless, the interesting thing is seeing the working behind certain decisions, such as the creation of "features".

    I know what you mean about random generation sucking in games. When I dabbled in QBasic programming, I found an interesting solution was to base any supposedly random occurence on a very wide range variables - even disparate things like, say for example in an action game, deciding when an enemy will shoot based partially on if you have an even or odd number of bullets in your gun. Or how many healing items you've used so far. Something the player isn't likely to be immediately aware of, and using a lot of such variables so that technically while it would be difficult to predict what would happen, it's not entirely down to chance. I found that for AI it resulted sometimes in some brilliantly unexpected behaviour. Of course when I was lazy I just used random timer code.

    This brings back a lot of fond memories of my high school days, spending IT lessons making my own games (most of which were pretty awful). None of them work on anything higher than XP, but I might post a few as a follow up to this post. As you say, a lot of writers have always wanted to be designers.

    ReplyDelete
  2. Nice! I'd like to download it myself. An inspiration for those who want to go into game designing (me). I think that the hook of Etrian Odyssey is the exploring and questing, rather than the spartan battle system. The battling is decent at best, but it's the improving the characters that's the best part of it.

    ReplyDelete
  3. Once I finish my Java class I'd like to teach myself C++ and use SDL to make a game or two of my own. In my case, I'd probably rip off the gameboy legend of zeldas and the Ys games, and if I feel really ambitious I'd throw in an insane story as well.(assuming I actually get to doing that. I'd problably make a sort of basic action RPG rogue-like and shove lovecraftian monstrosities in there if I actually did anything. Ambition is great, but till I have something I'm just talking big.)

    ReplyDelete
  4. I find it awesome that you programmed the graphics with MFC; I did the exact same thing when I made my first game. After a big book of theory but no practical application programming, MFC was the easiest, cheapeast, junkiest solution.

    ReplyDelete
  5. Could you please post the source code?

    ReplyDelete
  6. @Anon, source code appears to be lost in time, or at least buried on a mysterious folder in one of my four hard drives.

    ReplyDelete
  7. Same Anon here; I wanted to try my hand at an Android turn based strategy game. I was wondering how you program the movement range for each character. Other than that, I have a basic idea of how to do everything.

    ReplyDelete
  8. Honestly I remember it being pretty badly implemented. Basically it created paths in all four directions based on the movement range. Then it counted backwards to your character, adding a extra blocks to the side of each tile based on how far away you were. It's sort of confusing to explain in text, but it creates a star like below, where the * is your character and the # are movement range. So assuming a movement range of 3:

    #
    ###
    #####
    ###*###
    #####
    ###
    #

    But there was no real pathfinding. While it wouldn't let you move on invalid/occupied tiles, it wouldn't compute that, oh, there was no path around the river so you couldn't move across it. In fact I think one of the characters can actually jump across it even though it's not supposed to. It was one of those things I put in as a character trait even though it was a result of lousy pathfinding. I also made the map so only one character could exploit it. I'm sure you could modify that algorithm to check for certain tiles and stop drawing paths.

    ReplyDelete
  9. Oh, looks like Blogger ignored the formatting and removed the spaces, so that star doesn't look quite right. Sorry.

    ReplyDelete
  10. thanks a lot, pal, I know exactly how to do it now. I can think of an Android specific way to do the pathfinding...ill have to implement the basic levels using xml files and have my program read the xml filess to determine what kind of terrain there its on a certain spot

    ReplyDelete