Brace yourselves; this is going to be a long one. Time to talk inspiration!
I’ve played a lot of games in my life and in many ways they’ve colored how I view things in a mechanical sense. I like to think that I have a fairly solid grasp of what works and what doesn’t when it comes to general game design (my library of tabletop house rules attests to this). There are many, many outside influences in Fiancée Game, some of which are games that my fiancée has never played.
Once the very basics were done, I put aside actual programming for a time to get a good idea in my head of how I wanted the game itself to play. It is very important to have a solid idea of what you want a program to do before you start working on it in earnest. Sure you can get some basic systems in place that you know you’re going to need further on down the road, but before you start committing to actual mechanics you absolutely need to plan ahead.
The one element of the game that I’d (more or less) finalized before doing much in the way of planning was the basic locomotion system. Movement in Fiancée Game, as it stands as of this time, is very similar to that of Legend of Grimrock: smoothed movement and grid-based, minus the free-look. I’ve even got a handy minimap implemented (with a full area map to come).
I had initially developed movement to be almost identical to the system present in the Eye of the Beholder games, but I found that the instantaneous movement and turning was very disorienting in a 3D environment. It worked with 2D, but it’s jarring as all hell in 3D. Live and learn. To ease the disorientation I added smoothed camera movement when turning and walking. Now you slide forward instead of teleporting (no head-bobbing) and you spin smoothly when turning. You also peer over ledges that you’re facing because otherwise you might think that stairs are actually a pitfall (this was implemented due to my fiancée testing an earlier version of the game and thinking stairs to be a pit).
The skill system of the game, which I’ve yet to begin working on, is going to be based around skill trees like those found in games like Diablo II, Titan Quest, and so on. Skill trees will function as classes (there will be four to start with) and each tree will have somewhere in the ballpark of five or six activated abilities.
In addition to activated abilities will be passive abilities that affect how activated abilities work. For example, there may be a skill that deals ice damage to a single target. Attached to this skill are passive abilities that change how this spell functions on its targets. One may cause it to slow targets struck, while another may cause it to affect multiple targets at once. This passive system is based on the one found in The Incredible Adventures of Van Helsing II, which I found to be surprisingly engaging.
To add some complexity to the system I elected to employ a very limited number of slots (similar to what is found in the Guild Wars games) in which the player is allowed to allocate their skills. The player is given eight slots to build their ideal skill setup. I think that this will allow enough variety that multiple runs through the game will be encouraged — especially since the level cap will be fairly low (I’m thinking around 20).
I like gear. A lot. One of the primary reasons I play RPGs is because I love finding the next new piece of equipment. You have a thinly veiled Skinner box that feeds me nifty new items every ten minutes that I can then use to beat my enemies to death? Count me in!
I don’t think I’ve ever played a game that embraces “holy shit that’s a lot of gear” more than the Everquest games. Here’s a screenshot from the equipment panel from Everquest II:
Count those equipment slots! There are twenty-four there. Admittedly three are kind of throwaways (one for food, one for drink, and a third for a quiver). This is what RPGs should aspire to be! So much gear to tweak!
The problem inherent to a system like this is that most people will look at it and then promptly freeze up. Why? Because “holy shit there are twenty-four equipment slots I’ve got to manage.” That’s why. Now, admittedly, Fiancée Game doesn’t go quite as far as Everquest II does. Fiancée Game only has fourteen equipment slots by comparison (I suffer!). I’m actually okay with this number because it gives me the slots that I think I can work with while keeping from being too overwhelming.
So, how do we ‘fix’ this overwhelming amount of items to manage? There are a multitude of options, but I elected for a few solutions that I consider fairly simple. The first solution I set upon was introducing affinities to each gear slot. How this works is that each type of item is going to provide only a small set of bonuses from a much larger list. You want gear to increase your offensive power? Look for magic weapons, bracers, or gloves. You want extra hit points and defense? Those properties will be found on armor, shields, and necklaces. One thing that must be kept in mind with a system like this is that a player won’t realize it exists unless they’re informed about it. As such, documentation (whether in-game or in a manual) should provide a listing of what properties are typically found on what equipment
The second way to stymie the tide of overwhelming loot is to gradually introduce it. This is something I cribbed from the 4th Edition rules of Dungeons & Dragons (though I’m absolutely positive they borrowed it from elsewhere). You won’t be finding magical rings and amulets at first level. My fiancée might not see her first magical piece of jewelry until she’s halfway or more through the game. This gradual introduction allows the player to become comfortable with what they currently have before slowly introducing more for them to manage. This gradual introduction is excellent at keeping a player from feeling overwhelmed so long as they have sufficient time to acclimate to changes as they occur. Coupled with the affinity system it also makes gear upgrades easy to manage. You don’t have to look through fourteen different pieces of gear when only two of them will ever provide specific bonuses to you.
I decided fairly early on that loot in Fiancée Game was going to be static in nature. While I’m very fond of RPGs that have randomized gear, I find that interesting static gear tends to lead towards more player attachment. Everyone who played Neverwinter Nights: Hordes of the Underdark, for example, tends to remember Enserric. Not too many folks remember the beryl cap of the whale they used for two levels in Diablo II. All that being said, I don’t intend on all of the items in Fiancée Game to be quite as interesting as Enserric (he was a talking sword, after all), but I’d still like for them to be more than just random assortments of stats.
When I’d first started work on Fiancée Game I was playing a decent amount of Demise: Ascension which itself is a sequel to Mordor: The Depths of Dejonel. Mordor was heavily based around old game called Avatar which was developed to be a superior version of Oubliette (which saw a recent mobile re-release that plays very closely to the old DOS version). Oubliette was, itself, a game based on pedit5 which was (like both Avatar and Oubliette) developed for play on the PLATO system. All of these games feature interesting static loot. This is how I wanted Fiancée Game to roll.
I elected to go the route of static loot because I think it allows for greater flavor in the game along with the possibility of item permanency. With purely static loot, I can introduce items that do things that no other item in the game might do. With items like this, the player has the additional choice of staying with a an item that would otherwise be mechanically inferior because it provides some unique benefit that cannot be found elsewhere. Demise is an excellent example of this. There are items that you find in what would be the mid-game that are useful past the base game’s end-game portions. I do intend for the game to feature a pretty sizable pool of items for the player to find, some much rarer than others. The downside to this method is that there is always the chance that a specific piece of gear becomes ‘essential’ to optimal play. While this is something I’d worry about on a larger scale, I’m not too worried about it with Fiancée Game.
To curb the spamming of consumables such as healing potions, I’ve added a ‘consumables belt’ to the game. How it works is very similar to the belt found in the original Diablo, there are a limited number of slots that you can place various consumables into. The slots in the belt are the only consumables you can use in any one battle. This will make careful use of restorative items during boss encounters a must. It also allows me to create consumables that affect the game in a meaningful fashion. Inventory space isn’t really at a premium — the player has roughly forty slots to work with — but I’m thinking that most consumables will stack in some fashion when in the inventory.
I had initially intended to develop Fiancée Game to be a purely solo experience along the lines of Dragon Warrior on the NES. I decided against the game being a solo run because, knowing my fiancée, there are certain things she might need character-wise that she either wouldn’t know she needed or wouldn’t be interested in investing in. To compensate for this, I decided to include a companion in her game. The companion ended up being her dog, Sam. I intend on Sam serving a few different roles. Primarily he’ll be there as a tank to soak damage from enemy attacks. I also have plans to have him provide a small selection of party buffs called ‘boofs’ to keep with the dog theme (she thinks this is the most clever thing I’ve ever come up with — I think I’m flattered).
I don’t intend to have a separate equipment set for Sam. I figure that his stats will derive themselves based off of my fiancée’s character level. I’m doing this so Sam will always be decent, but not overpowering compared to the main character. The only thing he’ll really excel at is soaking damage and possibly providing taunts via obnoxious yapping and particularly unpleasant dog-related odors. I do intend to implement a skill or two that allows my fiancée to change Sam from a defender into a more offensive role should she have the desire to tank.
I intend for encounters in Fiancée Game to be visible things. Invisible random encounters have annoyed me since the first time I picked up Final Fantasy on the NES. I understand their necessity in the time period, but they’re something that should have been dropped as soon as systems were powerful enough to render wandering enemies without slowdown (Earthbound in the SNES-era is an excellent example of how things should have been done with regards to enemy encounters in early JRPGs).
While I don’t expect my fiancée to be able to evade every encounter in her game, I would like her to generally have the opportunity to do so. One thing I want to instill in her is economical dungeon exploration. I have a number of mechanics in place to limit the amount of time the player can generally spend in the dungeon, so being able to sneak past groups of enemies is imperative. I’m currently juggling a number of possibilities for how enemies will appear in-game. Part of me wants to go the Paper Sorcerer route and have them appear as black clouds if, for anything, simplicity’s sake.
This goes beyond just monsters, too. I want friendly NPCs to be visible in the game world. A conversation system in the vein of the one provided in the Infinity Engine games (Baldur’s Gate, Icewind Dale) or Neverwinter Nights will also be present.
When it comes to the bestiary itself, I have options. Since this isn’t a game I intend on releasing for public consumption, I can probably get away with some creature combinations that I would never be able to use thematically, legally, or otherwise. I fully expect to sneak in a hidden boss battle of some sort that involve Kefka from Final Fantasy VI. Outside of such references, the enemy roster will likely be pretty straight-forward, composed of your typically fantasy enemies. Naturally, there will be Dragon Warrior (Dragon Quest for the purists) slimes in there somewhere
Initially I’d planned for the world of Fiancée Game to be entirely enclosed in a dungeon like the original Eye of the Beholder. Grid-based engines fare well in this environment because the interiors of structures lend well to square-based design. However, after playing Legend of Grimrock II, I elected to expand outwards into the natural world just a bit.
The area of exploration in Fiancée Game is going to be quite large. The worldspace itself is a 32x32x32 grid. Here’s a quick look at the current WIP worldspace. You can see the outline of the forest outside of the evil keep where the majority of the gameplay will take place. I don’t expect the player to enter the keep until they’ve got a few levels under their belt. The neon purple blocks are the corners of the worldspace. I have a lot of room to work.
As mentioned above, the world is not small in fiancee game. A 32×32 grid in and of itself isn’t particularly huge, but that grid having 32 Z-levels to it makes is substantially larger. I fully intend on having a number of ways for the player to enter the evil keep where the latter parts of the game will occur. Also present outside the keep (and outside the forest) will be a small camp where the player can return to sell loot, stock up on equipment, and rest.
To reduce redundant exploration, I’ll also be introducing a waypoint system similar to the one found in Diablo II. I also intend on there being a central tower to the evil keep that allows quick navigation between levels. If you can find it (it’s rather obvious in the above screenshot).
I think that the above wraps it up regarding the general influences behind Fiancée Game. I’m sure there are more games that are influencing how I develop things in one way or another, but these are the major ones that strike me immediately. Those of you that stuck with me through this whole post: I salute you!