Hello, we apologize but forum registrations are non-functional at this time. This issue should be fixed around mid-December. Until then, please stop by our Discord channel if you'd like to get in touch with the team. Thanks!

2016 Refactoring

For discussion of the code running behind the game

Moderator: Staff

Post Reply
User avatar
Posts: 8669
Joined: Wed Jun 16, 2004 12:07 pm
Location: Austin TX

2016 Refactoring

Post by Roots » Thu Jul 28, 2016 12:04 am

There's a lot of change going on in the code right now, despite the fact that only two people are working on it. I thought i should share what, where, and why we're making some of these changes to existing code. One of the reasons we're doing this refactoring now is because after the 1.0 release, making changes like this is going to be harder to ensure we don't break anything for users inbetween releases.

1) MenuMode views
Lordakius is working on this. All the different screens in menu mode that show the party, inventory, equipment, etc. are all wrapped up in multiple classes defined in menu_views.h. We're splitting this file up into many so the code for the various views are more organized instead of being lumped all together in one file. This mimics the way that the ShopMode code is organized (with a file for buy, sell, etc).

2) GlobalEventGroup and global events
So what we call a "global event" is nothing more than a string/integer pair that the GlobalManager code maintains throughout the game, including when the game is saved and re-loaded. Global events are combined into groups (represented by another string) to make it easier to organize them all (as you can imagine, a 10+ hour game will have a lot of events).

The naming here is unfortunate, because unlike map events, these have nothing to do with processing actions and changes in the game. I'm beginning to find cases where I'm using both map events and global events together, and its annoying to have to frequently distinguish the two. Therefore, I'd like to rename global events to global records, as a record is a much better word for what this data represents. I'll be updating all the naming of global events everywhere, as well as in map mode where we sort of have a similar construct called a "KeyValueData" that gets stored in a _data_log. This I'll rename as a local event, since it is both volatile and not accessible outside of MapMode (or at least, it shouldn't be).
Post Reply