Fiancée Game – 05 – Wandering Encounters

Estimated Hours of Work Since Last Update: 4

   As with last time it’s been overlong since I last posted about Fiancée Game. I’d love to give the last excuse as last time (work being busy), but I don’t really have anything to blame but my lack of putting time aside to program. Still, a bit of work has been done!

Message System
   I’ve implemented a buffer system for message handling. Previously all messages would appear in the message box the instant they were ordered. This tends to get confusing in combat where you might make multiple attacks which will quickly fill the message box without actually letting you know what the results of the attacks were.

   Fiancée Game now prints messages in the buffer word-by-word until the buffer is empty. I think this is a much better way of doing things. I do want to implement a ‘lock’ system to the message system that prevents the player from taking action until a given message has finished displaying. I’m thinking that this will mostly be used in combat. I’d also like to get the ability to play sounds along with messages implemented, but it’s not a high priority at the moment.

Encounters
   In working to get the combat system up to a playable state, I’ve added wandering encounters. As it stands they take the form of floating capsules that meander randomly around the map. They respect walls and pits, so you don’t see them appearing out of nowhere or floating in the air.


Here comes trouble.

   As it stands, all random encounters are with a set group of enemies (a trio of kobolds, for now). I do want to implement randomly selected groups of enemies. Doing so won’t be too much work, but I wanted to get something playable implemented before doing anything complex with it.

   The Fiancée has stated that she’d like to eventually be able to clear areas out but have other (likely optional) areas that have constantly respawning enemies that she can use to grind levels should the need arise. I see nothing wrong with this, though I’m sure figuring out a system of persistence between game sessions is going to be a bit of work.

   My eventual plan, I think, will be something akin to Gauntlet where there are monster spawners that can be destroyed to stop the flow of monsters in a given area. I do plan on having set encounters (boss monsters, rare optional fights, and so on) that are only ever there once and do not respawn. I also plan on having some spawners that the player cannot destroy so that the player has areas to grind out levels if they need to.

Combat
   The core combat system is in much the same place as it was as of the last update. I’m hopeful that, having finished working on the above, I’ll be able to put some serious time into getting it fully functioning. There are still some things I’d like to finish with the message system (notably the locking system mentioned previously) before I get everything working fully.

Equipment
   I’m thinking strongly of overhauling how special properties function on equipment. I’m thinking of moving away from each property being its own class and instead simply making them into variables on the items and having the effect of the property based on the variable.

   This would mostly be for simplifying things on my end and wouldn’t really be noticeable from the player’s side of things since items that have unique properties would still have them, they’d just be a unique variable instead.

   Of course, I could always stop being lazy and instead program a proper effect handler but I’m currently undecided.

Read More Fiancée Game – 05 – Wandering Encounters

Fiancée Game – 04 – CharGen

Estimated Hours of Work Since Last Update: 8

   It’s been a lot longer since the last update than I’d intended, apologies for that. Life does, as they say, have something of a tendency to get in the way. My day job has been extremely busy of late and, between that and longer hours at my second job, it’s been cutting into my free time for both Fiancée Game development and LPing.
   That said, I’ve managed to squirrel away a few decent chunks of time over the past month-ish to work on things and get some additional systems implemented. Let’s dive in, shall we?

   Here’s a quick look at what the above eight hours have turned into:

Character Creation
   I spent around three hours getting character creation implemented into the game. It’s fairly simple looking, but it does what I need it to do. The player can name themselves, choose a class, and roll their attributes before beginning play. I decided to go with randomly rolled attributes because my fiancée really enjoys both the randomness and the “one more roll and it’s all 18s” aspect of the system.


Character generation is basic, but it does what it needs to do.

   There are the beginnings of some deeper systems in play here. Skills are going to be something that I’ll be needing to implement to finalize character creation. Three of the four classes begin play with a predetermined skill (the adventurer being given a skill point instead). In addition to a starting skill, each class begins play with a small bit of gear appropriate for them along with a pittance in gold — I’m thinking between 50 and 100 — enough for a night or two at the inn in town and maybe a healing potion.

   The only things left to be implemented in character generation are a “Begin Play” button and the ability to spend randomly generated bonus points on ability scores. Outside of that it’s fully functional.

Combat
   Up until now combat had more or less only been implemented in the UI sense. I’ve not got some basic fighting implemented, at least on the player’s side. The player attacks properly (with calculated miss chances), with the appropriate number of swings depending on weapon(s) equipped, and deals appropriate damage based on their equipped weapon and other assorted statistics.

   The current systems I have in place for attacking are likely to be re-coded in their entirety before combat is finalized. I want to separate some functions and I have to implement weapon properties, which should be an adventure.

   Once player attacking is where I want it, I need to work on the enemy’s ability to retaliate. I’ve currently got a handful of ideas on how I want to do this based around assorted types of enemy behavior. I want to make it so some enemies favor using special attacks (spellcasters), while others will favor attacking but might occasionally use a special attack if they have it (general critters). There are going to be sub-types to the AI, I think; a spellcaster, for example, with special abilities keyed towards healing its allies will probably have AI written around making sure all of its allies HP are greater than 50% and healing them when it isn’t. That kind of stuff. I’m looking forward to it as I’ve never really dealt with anything resembling complex AI before, even in a turn-based setting.

Equipment
   Amidst working on all of the above, I also went back and re-wrote how the game handles the player’s equipment. Nothing major, but it speeds up the various look ups I have to do for determining final statistics and whatnot.

Read More Fiancée Game – 04 – CharGen

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



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

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

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