Month: February 2016

Fiancée Game – 03 – Current Status (As of Now)

   In the previous post I talked at length about the influences to the various systems in Fiancée Game. In this post, I intend to outline exactly where the game currently stands. Unlike my previous posts, this one will probably be both fairly short and fairly dry — I’m going to state what’s currently implemented and possibly expand on it a bit, but not too much beyond that. Time to get to it!

   Inventory slots work and properly store items. Tooltips for items are implemented, though descriptions for most item properties still need to be included.

   Equipment tooltips display appropriate information based on the type of gear you’re mousing over. Items also have a variety of different rarity levels that will allow me to make more powerful, but appropriately less common, items in addition to Bob’s +1 Sword. Here’s a quick preview of what a higher level artifact might look like:

Sometimes “dropping the bass” is a very bad thing.

   The gear system is in place. Equipment has statistics, though, admittedly, they currently have no effect on actual gameplay.

   I’ve only recently begun working on the combat engine for Fiancée Game. Currently you can enter combat with a dummy enemy and choose to attack (and automatically defeat) it. Combat then resolves and you gain XP and gold. The dummy enemy does not fight back and has no supporting AI.

Combat. Very, very much a work in progress.

   Before I get too deep into the combat portions of the game, I want to have the statistics system for MOBs (the player, NPCs, monsters) finalized. That said, I do want to get something playable in place so that my fiancée can have some actual game to play with during testing.

   I fully expect the combat system to be the largest single chunk of programming that goes into the game. While all of the subsystems are going to equate to a lot of code, the combat is going to have so much going on that I can’t see it not eclipsing everything else. Once I get the basics done, I want to start implementing skill trees and all that fun character building crunchiness.

   More or less where I want it. You can move around in what I consider a comfortable fashion. Stairs and drops — which cause damage — have both been implemented. I don’t foresee too much more work being done here beyond tying things into appropriate systems (drops dealing actual HP damage in addition to mentioning it happening).

The Environment/Worldspace
   Unlike Grimrock, Fiancée Game has no load times beyond the initial ones to boot the game and load into the gameplay scene. Once the player has actually loaded into the game world, they are free to explore it seamlessly. This is likely to change should I decide to release ‘expansions’ for Fiancée Game due to worldspace size limits.

   Doors, both mundane and secret, have been implemented with the appropriate buttons to open them. The art of closing them currently eludes the dungeon’s designers.

User Interface
   The player’s inventory is more or less fully functional. The player can move gear around, examine item statistics (tooltips have been implemented), and equip various pieces of equipment to their appropriate gear slots. I still have to implement offensive and defensive statistic displays, but that has to wait until the player actually has the stats to display.

The inventory is mostly finished. Ignore the random dagger equipment slot.
I have yet to find an appropriate icon for the wrist slot.

   The game currently features a basic minimap that shows the area local to the player. It automatically notes where walls are, but nothing beyond that. It draws different textures to each cell based on what the floor texture of a given tile is.

The minimap does not distinguish between walls and doors. I debate on wanting it to.

   I’ve implemented a few other UI elements that I don’t think warrant screenshots at the current time. I currently have a working message box that displays flavor text and other information to the player. I also have portrait bars for the main character and for Sam. The belt is also implemented, though it currently serves no mechanical purpose.

That’s All, Folks
   And that’s about it. I’m sure I’ve forgotten a thing or two, but that’s more or less everything as it currently stands. Since this has finally been posted, I’m hoping to start weekly progress updates. Hopefully we’ll see some real growth of the game over the coming months!

Read More Fiancée Game – 03 – Current Status (As of Now)

Fiancée Game – 02 – Influences

   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).

Peering down the stairs and into the depths in a more recent version of Fiancée Game.

   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).

Equipment Slots
   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:

What do you mean “too many equipment slots”?
Every game needs bracelet and earring slots, dammit!

   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.

The single-player DOS version of Oubliette. Image courtesy of MyAbandonware.

   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.

The Party
   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

The World
   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.

32x32x32 is bigger than it sounds. Much bigger.

   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!

Read More Fiancée Game – 02 – Influences

Fiancée Game – 01 – Humble Beginnings

   Hello and welcome to my blog series relating to the game I’m developing for my fiancée. I figure, if anything, this series will keep me accountable towards actually finishing the game for her. I intend for the first few entries in this series to basically be working towards getting to where I currently am with regards to game development. I want to outline what my general ideas for the game are as well as what’s currently working. Once all that’s done, I’ll probably switch to a weekly, or bi-weekly “here’s what I’ve been up to” posting schedule until the game’s finished and in her hands.

   So, how did all of this get started?

   It’ll be romantic, I thought. Make a game for the eventually-to-be-wife. How many gamer girls can say that their gamer guy made ’em a game where they can do violent things to equally violent critters? Not only that, but I’ll be learning some game development, too! Now, full qualifiers out in the open, I’m a programmer. But I’m the boring kind of programmer. Most of my work is website and database related stuff; nothing to do with games (well, I did make a random map generator for my D&D tabletop games ages ago, but that doesn’t count).

   Sounds good right? I’ll make her a game, score some sweet, sweet brownie points, and learn some fun stuff about game development. Plus, y’know, “hey internets, I made a game!” Oh how naive I was.

   Once all is said and done, Fiancée Game (it does have an internal name, but this is what it’s been dubbed in the Twitterverse) is to be a first-person RPG that features grid-based movement and turn-based combat (that will not, contrary to what I’ve said was a possibility, be released to the public — this game is Wife Only™).

   So, how did we get to this point? Easy: I asked her.

   I broached the subject easily enough — I asked if she’d be interested in a “shitty little game” and she was excited at the prospect. Following that, I asked what kind of game she wanted. She knew she wanted an RPG but not much beyond that. First I asked what kind of navigation she wanted and led with “something like Eye of the Beholder?” She seemed to like the idea. After that I asked what kind of combat she wanted and turn-based was an almost immediate response (so she could have time to think out her actions, I’m sure — she’s a smart cookie!).

   Having the above was enough to get me a starting point. With that starting point I got to working on something fairly simple in Unity3D. My first goals were getting a proper movement system working. It took substantially longer than I’d initially anticipated (game development is hard!). After working for a week or so, I had something fairly basic to call my own.

Fiancée Game roughly a month into development.

   Getting movement implemented was tough mostly due to having to learn how to control cameras and properly smooth object movement in the Unity engine. It was very much a case of learning a new language, so to speak. I knew how I wanted it to work, but I had to learn how to tell Unity how I wanted it to work (a recurring problem, as I’ve learned).

   Once I had the basics of the movement system finalized, I then moved on to some rudimentary UI work (as seen above). There has been quite a bit of divergence between the above screenshot and where the game’s UI sits to this day. I’d originally intended to have a separate inventory and equipment window, but have since decided that it would be more prudent to have them combined.

   We’ve all got to start somewhere, and I think the earlier versions of Fiancée Game certainly showed some promise with regards to what was to come.

   Over the next few posts I want to begin talking (probably for several posts) about the various things that are influencing the design behind Fiancée Game. Following that, I intent on going over the game’s current systems. Hope to see you all there!

Read More Fiancée Game – 01 – Humble Beginnings