But the live-update part? That's trickier. I have an idea formulated which I'll code up soon, maybe later today, but for now it remains larval.
In the mean time, I can talk about what I did work on today. I fixed some issues with the pricing of alcoholic goods (so far: beer, ale, and rum) in my recipe system.
Previously, the recipes by which the prices for these goods were evaluated were written such that they were priced on the basis of the unit by which drinks are sold, such as the pint. However, this is not how production of such beverages actually works. They are turned out, not by the pint or by the gallon, but by the barrel. Since this is a game, I can stipulate that all barrels are alike, and that a barrel contains 30 gallons.
What I did today was rewrite the recipes as follows:
- The basic beer/ale/rum recipes were rewritten to price each drink as brewed in a 30-gallon barrel (including the price of the barrel, of course.) The rum recipe was predicated on being priced by the half-pint, so I had to rewrite it completely for 30-gallon production; the others required only minor tweaks. Now, the reality of alcohol being brewed in large batches, instead of gallon by gallon, is made concrete in the recipe system.
- The recipes which build on the one-barrel recipes, such as "by the tankard" (beer/ale sold to be drunk on the spot, without including the price of a vessel) and "by the bottle" (sold to-go, including the price of a glass bottle), were reconfigured to make use of the new by-the-barrel recipe. This means that now, the realities of a tavern proprietor purchasing a barrel and tapping it for his patrons, or of a brewer buying bottles and bottling his product, are made concrete in the specification of how by-the-tankard and by-the-bottle purchases are priced. These elements were not present before; they were papered over by simplification.
Not much an increase, granted. But that doesn't matter one bit. Getting it right -- or at least, getting it more right -- is what matters.
Nice work !ReplyDelete
Concerning your choice of language, is there any reason you used Python ? Have you looked into its usefulness concerning the "live-update" part of your program ?
Most of the economy system, and all of the character background generator, are implemented in Python. It's just the language I've used the most. (If you're curious: the part of the economy system which doesn't use Python is the part which makes the maps I've posted on this blog. That program is written in Haskell. It consists of several parsers which read in data saved from the Python program, and a renderer which writes the SVG map files from the parsed data.)Delete
As I said I believe I have a way to address the live-update functionality. Testing that solution is next on my todo list. I am also drafting a longer post regarding the evolution of the current "digital character" project. I now believe that calling it a "digital character sheet" is incorrect, and would bias me toward simply copying and extending the functionality of a paper sheet. What I actually want to do is think more in terms of the player's interface to the game world. In addition to the (non-trivial!) task of displaying the character record with all its details and derived statistics, I also want to be able to do things like have live-updating for what the character is hearing and smelling, and for the character's immediate environment to be represented graphically.
Enabling such features will require me to lean even more strongly in the direction of modeling the game world on the computer. Very exciting, even if I have no idea how to get there.
I understand your excitment, I hope you'll succeed !Delete
Sadly, I cannot help you out on the coding job, because none of those languages is on my skill list.
Best of luck !