May 26th, 2016: Runestar devlog 26/5/16: all the essentials
Posted by Gravecat at 11:36 am under Game Dev, Runestar. Comment?

Game version: 0.23.8a (pre-alpha)
Lines of C++ code: 10,210 (+401)
Lines of JSON data: 3,695 (+28)

This may not be the most interesting of devlogs today, but it’s one worth mentioning: I’ve finally cleared my to-do list of a lot of essential-yet-boring tasks, adding a bunch of boilerplate functionality to the game! This includes:

  • The drop-down status bar resize/revamp I’ve been meaning to do forever (the bar now occupies only a corner of the screen, rather than the entire top with a bunch of blank space)
  • Health regeneration! Now the player will heal damage slowly over time, though the more total health you have, the longer it’ll take to regenerate the slow way. Consumable healing items are coming soon.
  • Examine command, to see the attributes of items in the game. Not terribly exciting, but useful.
  • Splitting and re-stacking of stackable items (such as food rations or ammunition).
  • Corpses will now disappear eventually, slowly if they still have loot and more rapidly once looted (or if they were empty to begin with).
  • A flee command to run away from combat, if an exit is available. However, any foes you were fighting will remember you the next time you encounter them.
  • The skills listing (currently only combat skills) has been revamped and now looks pretty snazzy, rather than the uselessly ugly garbage it was before.
  • More in-game help files. ’nuff said.
  • A bunch of bugfixes, including some really obscure edge cases that were lurking around for a long while, and one that inadvertently made the player invincible.

I know nothing in that list is particularly thrilling, but I’m happy to have gotten a bunch of essential functionality implemented and done, so I can begin focusing on more exciting features. :3

May 25th, 2016: Runestar devlog 24/5/16: vehicles, mechs and ammunition
Posted by Gravecat at 12:24 am under Game Dev, Runestar. Comment?

Game version: 0.23.1a (pre-alpha)
Lines of C++ code: 9,809 (+481)
Lines of JSON data: 3,667 (+254)

Today I decided to completely eschew doing boring, boilerplate stuff that needs doing such as splitting item stacks or regenerating health, and instead worked on something a bit more fun: early framework code for vehicles and mechs, which also paves the way for distant-future stuff I want to eventually work on, such as airships. But enough about the future, what did I manage to get done today? Plenty!

While there’s currently no way to manage, repair, or equip vehicles and mechs outside of hard-wired debug code, I threw a couple of test vehicles into the game world to try out regardless: a tank (representing the basic vehicle type, which is slow and has terrible agility but packs powerful weapons), and a mech (representing the walker type, which has increased mobility but lower defenses). Vehicle weapons are extremely powerful compared to their hand-held equivalents, however the ammunition is expensive and heavy, and vehicles can’t reach a lot of areas, such as going indoors or climbing down ladders, limiting their use to outside, wide open spaces. I’m also going to eventually add fuel, which will be another balancing factor to vehicle use.

The other major addition today is one that I’ve been meaning to include for a long time: ammunition for ranged weapons! Ranged weapons tend to have a higher base damage than melee, along with a better chance to hit (because they can’t be parried), and the plan all along was for ammunition to act as a balance to compensate for the superior stats over melee weaponry, along with occasional weapon jams (which are currently not implemented).

Finally, I’ve implemented a much more minor feature which limits the speed at which player-entered commands are processed, stopping a player from getting an unfair advantage by being able to type extremely fast. Player input is now processed once per game tick (2 seconds), though you can still queue up a number of commands in a row if you wish. There’s also a few bug fixes and the like, but they’re not very interesting to write about, so let’s just have some screenshots instead.

May 23rd, 2016: Runestar devlog 23/5/16: combat and equipment revamp
Posted by Gravecat at 7:29 pm under Game Dev, Runestar. Comment?

Game version: 0.21.3a (pre-alpha)
Lines of C++ code: 9,328 (+36)
Lines of JSON data: 3413 (+34)

Another relatively short update, but a fairly significant one today!

While I’m largely very happy with the direction that the project is heading, especially with plans put in place for player-controlled vehicles and mechs, there was one thing that was consistently bothering me: the equipment system. The combat engine is based largely on (character) skill levels, but also influenced significantly by equipment, and the system I had in place up until this point was… in a nutshell, too granular. I had no less than 100 separate tiers of weapons, and not only did the combat system rely more heavily on gear over skill (especially for ranged weapons, which can’t be parried), but it was also far too much of a headache to deal with such an absurd range of potential gear.

Something had to change, and that came in the form of a combat revamp of sorts — the new system is a lot more linear than exponential growth, equipment tiers are narrowed down from 100 to 20, and character skill makes a huge difference in combat, to the extent that with maxed-out combat skills, you could be dealing up to 11 times more damage with the same weapon than a complete novice. After a fair amount of tinkering and testing, I’m happy to report that I’m extremely pleased with this new system, and it fits my vision for the game far better than the original ever did.

In addition, I’ve finally implemented the feature that grants bonus critical strike chance when using a one-handed weapon with an empty off-hand, meaning that now all styles of combat (one-handed, dual-wielding, two-handed) are equally viable — as it always should have been; I prefer the use of weapons to come down to player style and preference, not a clear-cut case of X is objectively better than Y. I’ll also be implementing ammunition and weapon jams to ranged weapons in the near future, along with backfires from overcharged weapons such as plasma rifles, which should help narrow the gap between melee and ranged weaponry in terms of overall usefulness.

Here’s a couple of screenshots of the new combat engine in action. More to come soon; there’s some more boilerplate to work on, but I’d like to get the vehicle code implemented sometime very soon!

Page 3 of 41234