January has not been particularly kind to me. It started with getting sick (you always seem to pickup a bug of some kind from planes) and after getting over that I had wisdom teeth extraction to look forward to and recover from. In fact, I'm currently writing this entry on the last day of my 4 day weekend to recover from that particular adventure. Thankfully everything on that front has gone super smoothly and am doing really well. So on to the parts that everyone here is way more interesting to the folks here.
I started 2017 with the decision that I wanted to move on adding elements that are more about gameplay than development utilities. As much as I like that sort of work, it's time to move onto things to actually making a game. I'll swing back to utilities for a change of pace or as needed to support gameplay.
As I mentioned in Journal #6, I'm working on a tactical strategy game. I've got some basic movement supported already, so the main missing tactical element is combat. I added (for now) another stats component (also Journal #6) to act as the data for a weapon attached to the each unit. For now all the ships have the same weapon with the same values. The stats my weapons are starting out with are Range (how far it can deal damage), Power (how much damage it does) and Cost (how much of the ship's supply stat is used to use). Since I don't really have a good solution for UI, I'm outputting most feedback that would be UI updates to the standard out for now.
I added to the starship data definition (Journal #7) to include the mesh information and then reordered my object construction so that given one of those definitions I could construct an object. I also swapped out the generic stats component that I was using for the ship's runtime data (health and power) with a component specific to the job of tracking starship data. Since this component was meant to have a reference to the data definition it was created from, I added support to my reflection system so that it knew about the data definition library. That way the JSON data I use can include a serialization safe string (as opposed to a doing crazy things with pointers) that the reflection system knows how to turn into a definition entry pointer.
Lastly, for use on my starship component I wrote up a data structure for gameplay stats (not to be confused with the stats component) and modifiers to those stats. In a typical RPG this would be used for values like Strength or Agility or the like. The modifiers would be things applied by equipment (like +50 Str or +25%) while they are equipped. For now the modifiers only support addition and multiplication. The stat starts with a base value that is the value when there are no modifiers, then multipliers are applied and then the additions to calculate the maximum value for that stat. It also keeps track of the current value over time. So in the case of a Health stat, it's tracking your current health, maximum health, base health and all the modifiers to the base that determine what your maximum actually is. We'll see how that goes for now.
New todos:
- Logging: I can generate output to the debug window but it's not really a log. At some point I'll want a logging solution that can save to a file and do some basic filtering on what output is saved.
- Reflection: Support for dynamic arrays. My reflection system already supports normal C arrays but to finish my gameplay stats structure it needs to support dynamic arrays (std::vector). I haven't decided yet if I'll just do support for vector or if I'll try to implement something that is more general right off the bat.
- Console: I realized I forgot to include scripts in list of console todos. It's nice to be able to write up a series of console commands in a text file that you can then reference repeatedly and across multiple executions. The console I worked with at Volition supported this and it was super useful.
- Strong typedef: This was something I introduced at Volition and thought I had a version of it here at home. When working in C++, typedefs are great but in a great many circumstances they just aren't typesafe enough. For this reason I wrote up (as have many others include one that is part of boost) a macro that simply wraps an instance of a type in a struct to prevent general type conversions from happening when you don't want them to. I need to find some time to recreate that in my home project. I guess I didn't need it, but I'd like to use it as part of how the stats and their modifiers interact with the clients that are applying the modifiers.
New project idea:
- I mentioned in my first post a tool I had been working on for the Fantasy Flight game, Descent. A campaign tracker. Well I started collecting and playing another game by Fantasy Flight called Star Wars: Armada. I think it would be very interesting to put together a tool to help keep track of things there. It could even spiral out to three tools, Fleet Construction, Combat tracker, Campaign tracker (campaign play being a thing that was just released). I'd need to work on upgrading my copy of the wxWidgets library since the one I currently have isn't compatible with the version of Visual Studio I'm currently on. Really just an idea right now. Edit: I am aware of online tools for this game in regards to Fleet Construction so it might not be the highest priority tool of the three.
Well, that's it for January of 2017!
