Project Minotaur Progress Report: Too Much?

Legend:
(-) Goal incomplete
(~) Goal partially complete (buggy/hacked)
(+) Goal complete

Goals for this week:
1. (+) First pass art for elemental spell orbs
2. (+) Complete initial spell design
3. (-) Rebuild casting prototype as sustainable code
4. (-) Add timer
5. (-) Allow combining elements
6. (~) Create development schedule

Goals for next week:
1. Write Design Document
2. Core architecture
a. Gamestate management
b. Base object class
c. Base object components
3. Redo spell casting prototype

Other work done:
1. Feedback gathered on first pass art
2. Java research into useful data structures
3. Architecture concepts designed
4. New laptop on the way
5. Pseudo coded procedural generation of the map

To say this week didn't go as I hoped would be accurate.  I got about half of what I originally intended to do.  On the other hand, my plan was faulty:  To rebuild the prototype I had in a way that won't call for another rewrite down the line, I need an architecture in place.  Otherwise, anything I write will be throw away code - which I learned this week that I don't have time to waste writing such code during such a short development time.

Speaking of development time, I've got six weeks until my original launch date, which is a pretty heavy weight.  If I want to get this game done for that date, it's gotta be lightweight (read unpolished and a bit lacking).  Unless my architecture makes development quite a lot quicker, I'll have to make cuts or push the deadline.

Something that should help speed up development is some new equipment - specifically a new laptop that actually has battery life and is lightweight.  My current laptop is hefty and has a broken hinge, so it can be a bit of a pain to work on.  Also, I'll feel the need to prove the new laptop is a good investment, which should help with motivation.

In other news, my time estimates for what I did get done were pretty much spot on.  While that may not matter to some, it certainly makes. The producer side of me feel like a champion.

Finally, here's the first pass on the elemental spell orb sprite sheets (inactive on the left, active on the right).  I'm happy with most of them, but some definitely need another pass.  Feel free to leave your thoughts on how they look (and try naming the elements without looking at the filenames).

See you next week!

Project Minotaur Progress Report: Spell Casting

Note:  This post has been sitting around as a draft since Friday morning, but the Blogger mobile app has issues with placing images.  I'll try to get updates out on Fridays here on out.

Legend:
(-) Goal incomplete
(~) Goal partially complete (buggy/hacked)
(+) Goal complete

Goals for this week:
1. (~)Complete a proof-of-concept of the spell-casting system that contains:
a. (+)Basic interface that accepts player input and reports selection
b. (~)Generation of spell circle
c. (+)Placeholder art for spell orbs
d. (-) Measure and report casting time

Goals for next week:
1. First pass art for elemental spell orbs
2. Complete initial spell design
3. Rebuild casting prototype as sustainable code
4. Add timer
5. Allow combining elements
6. Create development schedule

Other:
1. Working title has been chosen

This was a slow week starting out, busy and and somewhat undirected.  Android and Java have their quirks that are slowing me down a bit, and Eclipse is definitely not one of my favorite tools.  Excuses aside, I really just need to hunker down, plan out my development path, and get cracking.

So how does spell casting work?  A spell is created by choosing an element, a form, and a target from successive spell rings.  First, the player is shown the element spell ring.

 

After choosing an element, the player chooses the form for the spell to take.  These forms determine what the spell does (e.g. bolt is a missile attack, shield is defensive).

Finally, the player chooses the target of the spell.  Since this concept is based on idea of true names/words, the player may cast the spell on his/her self or other (the enemy).  There's also true self, which will have a much greater effect, but also allow the enemy to cast spells using the true name of the player character.  However, if the enemy casts a spell using their own true name, then the player may cast spells against them with greater power using "true other."

At this point the spell is cast, with damage dependent on the casting time and character abilities.  In this proof-of-concept, the spell orbs chosen are displayed on the left of the screen.

However, all I've got for this first week is the bare-bones of the concept, and the insides aren't pretty.  Over the next week, I want to rewrite this system into something I can sustain and build on, and hopefully make it prettier on the outside at the same time. Most importantly, I need to plan out what I can accomplish by March and how I'm going to go about doing that.

See you next week!

Happy Birthday!

So I've come to a decision.  I've longed for the opportunity to go indie and start working on my own games.  Finally, I'm actually in a position to do so - I've got some long term employment that's not eating the entirety of my day, nor is it scratching my game development itch (in a good way).  I have money to pay the bills, the time to work on a game idea, and the need to do so.  Oh, and I have enough of an idea I'm excited about to get started (at the very least, a few mechanics that I really want to prototype).

So, in the words of Leeroy Jenkins, let's do this!

Here's the plan:  I want to make a dungeon crawler like those from the late eighties/early nineties for Android.  Some of my fondest memories are of playing these games with my older brothers, and there's a lot of neat features that Android offers that I'd like to use to spice up the genre.  I'm currently weighing the options of procedural generation or a hand-crafted experience, which will likely come down to scoping.  There's a lot to get done in just three months.

Oh right, one of my goals is to launch on March 9th.  Why?  We'll just call it motivation.

Like I said, I have enough to get started, so I'm going to do just that before I over think it all.  I'll keep you updated (maybe on a weekly Thursday update).  Happy gaming!

Oh, why today?  It's my birthday :D

Randomness in Games

(This is a reproduction of some old content I wrote back in 2009.  I'm still figuring out what I want for this whole blog thing for the year, but we'll start with a Monday release schedule and some slightly dated content.)

While playing Mario Party the other day, it really hit me that randomness can suck in video games. Mario Party is one of the very few games that when you say the game cheated, I will likely agree with you (see here for some first turn ridiculousness). All the games of that series have had a terrible tendency to favor one player up until the very end, then suddenly the underdog comes in and wins the day. This raises the question:

Is randomness good for games, and what can be done to improve upon existing randomness?

Now I am an avid DnD player, a game that revolves around dice so much so that I'd skip a planet analogy and go straight to galaxy. Dice are flying back and forth across the table for almost anything. The base rule of DnD: Roll a die, add some stuff, then see what happens. So how has this game survived and thrived over the last thirty years?

There's a massive human element to DnD. The DM controls the fates behind his screen, laptop, stack of folders, or charade that he has any plan at all. Ultimately, the dice don't decide what happens, the DM does. The true base rule of DnD is the DM makes the rules. This means that the DM cannot cheat, even if he smudges a few numbers for or against the players' favor. The players, though the DM is instructed to never let them in on that secret, know all along that they got help somewhere along the way. The trick is to keep them in the dark about when that was.

Another thing that helps these players out is that, as their characters get more powerful, the dice have less and less of an impact on the outcome of a roll. For instance, a certain ranger in my current campaign just about always succeeds at attack rolls, spot checks, and most of what she does. Meanwhile, the Dwarf in the party, while he has a bit of crummy luck when it comes to attacking, basically never gets hit (and when he does, he still has damage reduction... and about 120 hit points).

So when you really think of it, that galaxy is a fantastic analogy of DnD's randomness: There may be a lot of shiny, colorful, sparkly planets and stars, but good gravy that's nothing compared to the infinite blackness between it all. The dice can mean the difference between a party wipe and a tremendous victory, but the DM's human element and the bonuses and skills of the player characters make that extremely rare. More often, it's the DM's human error or the lacking of a particular skill that gets characters killed.

Then there's World of Warcraft. How many hours have those of you that play spent trying to get a super rare drop? How much did you enjoy the mind-numbing task of continuous, pointless slaughter? Oh, wait, that refers to the entire game... Anyway, you get the point. Certain things have a random drop chance that's bloody atrocious, that's all there is to it.

Granted such items do have a reward. I know there are certain weapon drops that are nearly game breaking (the type of item you then run around with for the next twenty levels), and there are some that just add a flair to your character (like a blue dragon pet or a phoenix mount), which you can also sell for ridiculous amounts of cash (could probably get away with real money too, not just in-game gold).

Along the same lines, we have King's Field. What do you mean you haven't played it!? Okay, I know, it's old and, well, old. This first person adventure game has a slight amount of randomness to it in that there's one monster that can drop a wicked sword that allows you to recharge mana. Why's this so important? If you make a certain choice earlier in the game, you cannot regain mana. Guess what choice I made. Anywho, this is a major part of the game I was missing out on here, so much so that I camped out this monster, killed him a billion times, and got the sword so I could start casting spells. While that made the game a lot more fun, it really was not fun for the three hours I was hacking away at the same monster.

This brings me to Left 4 Dead (L4D). Valve's zombie title here comes with a wonderful thing called commentary mode, which lifts the hood of the game so you can see inside. Valve realized they were having this randomness trouble during playtesting when weaker players would have a run of bad luck that would lead to their death at the hands of the zombie hordes. How did they solve this problem? Basically, they made a DM. Really! Okay, so they call it the AI director, which basically will push players to a certain stress level (i.e. to the point of near death, low ammo, and generally screwed) then ease up, give them a Molotov and a weapons cache to nurse them back to health, then bring in more zombies.

However, if you've played through commentary mode, you may point out where they added more randomness to add to the fun. A problem we've all had with FPS death-matches at some point is spawn-camping, where a jackass will just hang out at your spawn location and kill you, just so you respawn there and die again. That sucks. To battle this, developers have been adding to the number of spawn points, but still, a player with enough experience will remember every nook and cranny where something will appear and have the map completely memorized in a matter of minutes (if that).

Valve's solution is just a set of rules where the enemies can and can't spawn. The most basic of which is the classic "line of sight" rule. This means that enemies are not allowed to pop out of thin air directly in front of your eyes. That doesn't mean it won't spawn a horde around corner after you've thrown an explosive there to clear the way ahead of you (granted, they may have a rule about that).  (A friend pointed out a flaw in this logic, where a horde of zombies spawn inside the safe room he had just come from.  He felt cheated.)

Basically, Valve's hit the bull's eye on the randomness problem. Randomness can improve gameplay, but it can also detract from it. The trick is to keep a handle on the situation, a balancing factor of some sort to keep the players from feeling cheated that still allows for a wide array of results. It's all about helping the players have fun, even if they know they're getting a little help here and there. The trick is to keep them from knowing exactly when and where that help arrived.