Another five months, another sporadic update… 🙂 Been busy with various things; my girlfriend and I completed our living room decor this weekend and it is beautiful! If only my office was that clean and zen…
After spending some time working in C# on a transaction parser, I went back to the assembly code to actually implement the transaction code itself. This was important because I suspected, correctly, that the act of actually writing out the implementation would help determine what transactions I needed.
For example, my original plan had a transaction code that would alter any byte/word value in the game’s data arrays. This meant tracking size, operation type, index, whether or not subtraction would go below zero, not allow below zero, etc. But I realized it burning up too much code space to do a single simple operation.
Instead I focused on making transaction codes for specific use cases. Because training points are earned by all players at once, I just wrote a code to do that and that alone, rather than engineer a solution that would do it for anything anywhere.
Writing up transactions also revealed I had a lot of “dead” code from older implementations lurking about. Removing these feels good as it’s cleaning up the codebase and freeing up memory. I have just under 5k of space left which looks like it will be enough to finish it!
I came up with a new idea as well; I’m adding gambling as an option to the game. Certain places will have a gambling sub-game, involving dice rolls. I’m a big fan of the CRPG Addict, and he’s noted that games to win money are useful for bypassing tedious monster fighting in games. Given I don’t want the game to focus solely on combat, it seems like a nice idea to have the option to earn money in other ways.
Right now, I’m working on buying and selling items. I’ve hit a particularly complicated and infuriating snag, which is ammunition. I decided to make the item # for ammunition types reflect the count of ammunition awhile ago, because I didn’t want to maintain separate counts of items for everything. This “special case” though is causing major headaches… I can’t just consider the number of items in a backpack as an indicator of fullness where ammunition is concerned, because it should add to an existing item… IF it’s in there. Plus I have to display the cost on screen a little differently, showing the number of ammunition you buy for the given amount. So more special casing, argh! For selling items, I’m not even going to allow you to sell ammunition back for money, it’s just too complicated…
The good news is that after I’m done with all the transaction code, my next step is to prepare a baseline “demo” data package for test purposes, compile the code, fix bugs, and start testing the hell out of the engine to make sure everything works. Once that’s done, I can start actually WRITING the game in earnest. Getting closer and closer…