Oh... I suppose then: https://logicmag.io/06-model-metropolis/
Entrepreneur Central
Moderators: Bob the Hamster, marionline, SDHawk
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
So, Heart of the OHR 2018 is over. A return to focus on Entrepreneur: The Beginning has been ramping up (on Fridays and Saturdays). I think it's time for a new update.
Well, that is, assuming there is something to report.
In reality, there's been nothing new since the last update, which is nothing new from the update before that. Everything is about planning without any real proof of implementation. That's probably uneventful in the greater scheme of things. How many times have we been pitched an excellent idea and given a subpar implementation? Early Access is full of such atrocities.
But, what if I did have something to show of my months and years of hype? What if all this talk has led to some kind of action?
Warning: Monster post ahead. Read only if you want to see how I took a chunk of scripting insanity and pared it down to something reasonable. (TMC, this is for you.) Also read if you want to take a stab at adding your own items to the game.
For the past couple of years, I've undergone a process to rewrite the game from pseudo-scratch (that's where you keep the same systems already established but rewrite how they work). A big part of that system rewrite is to change how items are implemented. Prior to the rewrite, this journal has infamously chronicled the lengthy steps I'd have to take to add just one new item (where adding a single item could take almost a day's worth of scripting, due to all of the hunting and modifying I'd have to conduct, based on a series of instructions I had to write to keep track of the process that is as similarly complicated as it is to building a desk chair from Office Depot, though not as easy to actually do). For the last few months, I've been improving on this system enough that adding a new item now takes just a few minutes.
It's an impressive turnaround in comparison, and I've decided that now is as good of a time as any to show you how the new item implementation works, as well as to feature all of the new things that the rewritten item structure can do. I was going to show you this some time ago, but that was before I made it better.
The Old Way versus the New Way:
First of all, it's important to mention that I've since scrapped my plan to focus all of item creation into a single script. I've tried it, and it ended up being almost as equally insane as splitting item development across 20+ channels. So, I broke item development into several categories. The new steps are as follows (for comparison, you can read my previous list of steps to get a sense on what I had to overcome to get to this point):
1. I still have to define items in the items menu to give them a unique ID. I also still have to add four tags for consumables and five tags for equipment (under the prefixes, "have," "use," "shop," "item," and "sell," with the lattermost reserved for equipment only). I still have to assign global variables with the item's name, serving value (usually prefixed "serv"), and trending potential, if it's an item sold in stores, to track specific attributes throughout the game. I still have to assign each item a unique "trytobuy" ID to track acquisition habits (including those related to shoplifting). I still have to give each item a "compareitem" constant to use for trending (if it can be bought in stores). I still have to consider special case variables, like those attributed to items that can spoil. I still have to write textboxes that signal the item's existence in the game and menu selections that make highlighting it possible. These old steps can't be avoided. But, they also take hardly any time at all to implement. With the exception of textboxes, that's always been true.
2. What's changed is the scripting. Once I've defined the components, I can now greatly reduce the steps required to implement them into the game. In fact, for any item that already has a template in place, the only thing I need to do to get the item up and running is to fill out a chart with its respective attributes defined. For items that don't yet have a template (like advertising items, for example, which are next on my list as of this writing), I may have to spend a little extra time determining what that template should be, but that, too, is on a system that's been pretty well streamlined.
3. Once the chart is filled out, I have to commit it to the game and assign the respective scripts to each item's location in CUSTOM.
And that's it. What's so great about this new system is that it can be infinitely customizable (not literally infinite, but customizable up to the point that I run out of global variables). If I want to create new attributes to each item, I just have to write the base formula and then apply it to the item's chart, or one of the special component scripts that are designated to handle add-ons. It's highly moddable in this respect.
Insanity Made Easy:
For example, let's examine how cinnamon powder is now defined in the game. Note that the following example is in-progress and may not reflect the final version. Some components are not yet fleshed out and will show a bunch of zeroes for now, but this will be addressed as I go through the next pass of item creation. I will also be substituting scripts and sections that do not affect cinnamon powder with a (#...) symbol or removing sections unrelated to cinnamon powder completely (not all, but some). Even though the new system greatly simplifies the process, it can still be intimidating to look at when viewed in its entirety. I'll explain each part under the posted code to give you a sense of what's happening here. Again, this is all WIP and can change before it's finalized.
This is the hub script for all item manipulations. By accessing "locate item," I can call up all of its related stats and attributes and export it to a series of "general" variables that can be altered without damaging the item's core stats. This function is usually followed by a "write to item" command at the end of the manipulation script to confirm changes to the actual item.
Note: This is one of the only hub or template scripts I have to modify with each new item addition. One line! The case number is identical to the item's ID number defined in CUSTOM.
Every writable category needs a "clean" or "clear" script prior to the transfer process to prevent corruption.
Any statistic or function that is true for every item in the game will go into this script. This is basically a "set it and forget it" type of function. The only reason I would ever need to think about it is if I want to add another universal function to it or change the current behavior.
These two script functions make it easier to script in-game menus and determine whether the item is visible in the menu (to prevent cluttering menus with items the player doesn't yet have). For example, any item tagged "category:flavor" will activate the menu tags 2889 and 2921 when the script detects that Buck has it in his inventory, allowing that menu to become selectable. This is designed primarily to keep me from having to constantly hunt for the right tag to match the right item to the right menu. Now all I have to do to get an item to appear in the proper menu is to assign it a category and make sure that category is defined.
This is a "cleaner" script for allergies. It ensures that all items that activate allergies will require an allergy definition or two (which cinnamon powder will have, as you'll soon see). Items that do not trigger allergies need not worry about this function as it's already applied to them.
Note: Allergies will have three levels of intensity, as defined by the values. Customers will likely have their own "allergy tolerance" levels that will modify the allergy values so that a person with a strong tolerance will provide a low multiplier and those with a weak tolerance will provide a high multiplier (and those with no susceptibility will merely zero out the value).
The above section is a shell script that calls on text boxes and slice collections related to consignments.
Note: There are currently 15 consignment categories, but cinnamon powder uses category 2.
The above section determines how Sapphire, the consignment shop owner, responds to Buck's attempt to sell items. Her responses depend on the type of item it is.
The above is an example of the category system, in this case for equipment. When the item data is cleared, all "itemis" attributes are set to "false." The category shell script sets "itemis" variables to "true" if that item falls into that category. Below is a sample of garnishes (like cinnamon powder, which is listed as "flavor") according to the categories system.
Every category has a list of subcategories attached. Any new item I add that does not fall into an existing category will require that I add a new category. Any additional item I add that falls into this category will already have its respective "itemis" and consignment rules set.
This is for items found in trashcans or created through processing. Does not apply to cinnamon powder.
The next few scripts are shell scripts that transfer item-specific values to general variables. These are the values that I define on each item's definition page. This is what allows me to cut my item implementation time down from one day to a few minutes. I'll include every section here, even those that do not relate to cinnamon powder, but explain only those that may not be obvious by reading what they say. If you want more information on any of these topics, let me know.
Note: "Component object essentials" are a new item type that refers to installed containers, like watercooler jugs.
Item capacity is a new value given to container items, like the watercooler jug. In the case for equipment, I believe I've set this to include serving capacities for coffeemakers and other equipment items.
Note: The latter script, "item trash settings," is actually an all-purpose script to define all single-use, non-storebought items.
This function sets a universal price and quantity for selling items. This is important for when two or more shops sell the same item (like cream or milk) but sell it at different prices. The mean item price determines the base value that Sapphire will use when determining what to offer Buck at the consignment shop.
Even though this isn't in play yet, storage capacities will depend on item sizes and weights, as well as certain consignment values (like fruit and vegetables).
Did I mention that inventories will have limits soon?
These values are the textbox numbers for items based on shopping, acquiring, and viewing in inventory.
This script is still fixed, but I'll be switching it to custom positioning soon. In other words, you won't have to put your coffeemakers where the game tells you to. You'll soon get to put your machines wherever you want. For now, the above script sets the tags that make the coffeemakers work. Has nothing to do with cinnamon powder.
Coming soon.
These are the values that modify coffee when a garnish, finisher, or essential is added. This feature extends to side items, fruits, etc. and will play a role in future crafting. "CS Bonus" refers to "customer service bonus" and "addadollar" is refers to a customer's mandatory tip.
These values apply to entertainment items like newspapers and radios.
The above two functions are a work in progress and will eventually define how flavor and comfort values are achieved. I will likely use the sums of these functions to determine the general flavor and comfort values in the "item condition bonus stats." For now, the values are arbitrary.
This is the modifier given to any item that's used in saturation. This is typically a decadent modifier.
These two scripts read the bonus modifiers and display them in shops when the player selects an item for purchase (or for consideration of purchase).
The next section I'm omitting from this report because it's focused entirely on equipment items and I want to keep this from getting too complex to read. I may do a separate feature on equipment if there's any interest.
The "altered state meta check" is used to store data for items that may have more than one form. Cinnamon powder does not have an altered state, but coffee beans (powder), dairy items (perishable), pastries (stale), etc. do. Equipment items may also fall into this category. The purpose of this script is to isolate special cases from the main item data sheets so that I don't lose track of them.
In-progress script for determining the outcomes of coffee (and maybe other future crafted items) that have been saturated or otherwise deemed unpleasant.
A "set it and forget it" script that affects shop inventories when dynamic shoppers purchase items. For items that cannot be bought in stores (like trash and processed items), the function "dynamicitemisvalid := false" will run in its place.
This script goes with shop displays, used in the "item bonus display values" function listed a few lines above.
This is used for items that apply a special designation to a crafted item if used. All toppers (stirrers, cup warmers, and now even cinnamon powder, as of the upcoming version) will use this function.
Used to assign allergy types and degrees of intensity to items. For example, peanut butter affects "allergy:peanuts" at an intensity of 2. Some items, mostly pastries, contain more than one allergy category. Woe to the customer who has low tolerance and is allergic to both ingredients in said item.
Additional scripts for yard equipment and health items have been omitted from this report.
This is the shell script that copies item name strings to various slice and text displays.
This is how Buck responds to using finishers (stirrers, cup warmers, etc.). Works in conjunction with "record item special case."
And those are some of the formulas and shell scripts I use to help me keep control of new item additions.
The Item Sheet:
And now it's time for the main event, the item sheet. Note that this is the main script out of three that must be written from scratch or modified from a template to get an item into the game. The other two essential scripts are "locate item" (listed at the top of this post) and "write to item" (not featured in this post, but is essentially a shorter reversal of the item sheet listed below, used to transfer general data back to the item).
Note: For special or converted items, "altered state meta check" is also important.
As you can see, forming items through a standard worksheet is so much faster and easier than doing so through a series of 20+ individually handcrafted sections. While each item type may have its own set of parameters (for example, coffee beans may have an additional function for powder conversions), the universal attributes (cost, bonus, IDs, etc.) can be easily tracked, modified, and implemented. This means that any item modification I make, like deciding that all powders are flammable, for example, can also be quickly implemented.
If all goes well, I can also use this system to make everything into a coffee garnish, for better or for worst, with a few more adjustments. Ever wanted to see what would happen if you put bananas in your coffee? Yeah, me, too.
I still have about half of the 300 series of items to implement, which includes advertising, electronics, and office items, and all of the 400 series of items (right now, there are 12, and they're all pastries). When that's done, I need to go back and fill in some of the zeroed items like height, weight, temperature, and exact flavors and comfort levels, as well as most of the altered state values. Then I need to finish my consignment categories (I've got one or two left to define), turn previously arbitrary items like teddy bears and videocassettes into actual defined items, possibly pushing me into the 500 series of items, complete the "write to item" section, and then finish checking my various shop, consignment, and pavilion formulas to make sure everything will work and make the necessary adjustments. By then, I should be ready to package the next experimental release, 1.2.2.
Hopefully production will start going faster after that. Exciting, right?
By the way, the 10th anniversary of me beginning this madness happens on May 12th. Mark your calendars.
Well, that is, assuming there is something to report.
In reality, there's been nothing new since the last update, which is nothing new from the update before that. Everything is about planning without any real proof of implementation. That's probably uneventful in the greater scheme of things. How many times have we been pitched an excellent idea and given a subpar implementation? Early Access is full of such atrocities.
But, what if I did have something to show of my months and years of hype? What if all this talk has led to some kind of action?
Warning: Monster post ahead. Read only if you want to see how I took a chunk of scripting insanity and pared it down to something reasonable. (TMC, this is for you.) Also read if you want to take a stab at adding your own items to the game.
For the past couple of years, I've undergone a process to rewrite the game from pseudo-scratch (that's where you keep the same systems already established but rewrite how they work). A big part of that system rewrite is to change how items are implemented. Prior to the rewrite, this journal has infamously chronicled the lengthy steps I'd have to take to add just one new item (where adding a single item could take almost a day's worth of scripting, due to all of the hunting and modifying I'd have to conduct, based on a series of instructions I had to write to keep track of the process that is as similarly complicated as it is to building a desk chair from Office Depot, though not as easy to actually do). For the last few months, I've been improving on this system enough that adding a new item now takes just a few minutes.
It's an impressive turnaround in comparison, and I've decided that now is as good of a time as any to show you how the new item implementation works, as well as to feature all of the new things that the rewritten item structure can do. I was going to show you this some time ago, but that was before I made it better.
The Old Way versus the New Way:
First of all, it's important to mention that I've since scrapped my plan to focus all of item creation into a single script. I've tried it, and it ended up being almost as equally insane as splitting item development across 20+ channels. So, I broke item development into several categories. The new steps are as follows (for comparison, you can read my previous list of steps to get a sense on what I had to overcome to get to this point):
1. I still have to define items in the items menu to give them a unique ID. I also still have to add four tags for consumables and five tags for equipment (under the prefixes, "have," "use," "shop," "item," and "sell," with the lattermost reserved for equipment only). I still have to assign global variables with the item's name, serving value (usually prefixed "serv"), and trending potential, if it's an item sold in stores, to track specific attributes throughout the game. I still have to assign each item a unique "trytobuy" ID to track acquisition habits (including those related to shoplifting). I still have to give each item a "compareitem" constant to use for trending (if it can be bought in stores). I still have to consider special case variables, like those attributed to items that can spoil. I still have to write textboxes that signal the item's existence in the game and menu selections that make highlighting it possible. These old steps can't be avoided. But, they also take hardly any time at all to implement. With the exception of textboxes, that's always been true.
2. What's changed is the scripting. Once I've defined the components, I can now greatly reduce the steps required to implement them into the game. In fact, for any item that already has a template in place, the only thing I need to do to get the item up and running is to fill out a chart with its respective attributes defined. For items that don't yet have a template (like advertising items, for example, which are next on my list as of this writing), I may have to spend a little extra time determining what that template should be, but that, too, is on a system that's been pretty well streamlined.
3. Once the chart is filled out, I have to commit it to the game and assign the respective scripts to each item's location in CUSTOM.
And that's it. What's so great about this new system is that it can be infinitely customizable (not literally infinite, but customizable up to the point that I run out of global variables). If I want to create new attributes to each item, I just have to write the base formula and then apply it to the item's chart, or one of the special component scripts that are designated to handle add-ons. It's highly moddable in this respect.
Insanity Made Easy:
For example, let's examine how cinnamon powder is now defined in the game. Note that the following example is in-progress and may not reflect the final version. Some components are not yet fleshed out and will show a bunch of zeroes for now, but this will be addressed as I go through the next pass of item creation. I will also be substituting scripts and sections that do not affect cinnamon powder with a (#...) symbol or removing sections unrelated to cinnamon powder completely (not all, but some). Even though the new system greatly simplifies the process, it can still be intimidating to look at when viewed in its entirety. I'll explain each part under the posted code to give you a sense of what's happening here. Again, this is all WIP and can change before it's finalized.
Code: Select all
script,locate item,item,clr = true,begin
#needs a clear data script to prevent item corruption
#this "clear item data" needs to run before this script, but independently to prevent blocking outside flags.
if (clr) then(
clear item data
)
saveitemnumber := item
clear categories
switch (item) do(
case (0) read equipment item (@read coffeepot data, category:coffee)
#...
case (22) read garnish item (@read cinnamon powder data, category:flavor)
#...
)
true for all items
run new menu verification
saveitemnumber := 0
endNote: This is one of the only hub or template scripts I have to modify with each new item addition. One line! The case number is identical to the item's ID number defined in CUSTOM.
Code: Select all
script,clear categories,begin
menucat1 := 0
menucat2 := 0
menucat3 := 0
endCode: Select all
script,true for all items,begin
switch (persuasionlevel) do(
case (persuasion:low) do(
generalpersuasionneed := generalprice / 2
persuasionfloat := (generalprice * 50),mod,100
)
case (persuasion:average) generalpersuasionneed := generalprice
case (persuasion:high) do(
generalpersuasionneed := ((generalprice * 150) / 100)
persuasionfloat := (generalprice * 50),mod,100
)
case (persuasion:elite) generalpersuasionneed := generalprice * 2
case (persuasion:perfection) do(
generalpersuasionneed := ((generalprice * 250) / 100)
persuasionfloat := (generalprice * 50),mod,100
)
case (persuasion:impossible) generalpersuasionneed := 1000
case (persuasion:inevitable) generalpersuasionneed := 0
)
#add script for checking security levels or equivalent (which will require a shop value search)
generalshelfsafety := generalshelfspace--(generalshelfspace / 10)
endCode: Select all
script,run new menu verification,begin
if ((generalitem>=1) || (generalitemunit>=1)) then(
check item menu category (menucat1)
check item menu category (menucat2)
check item menu category (menucat3)
)
end
script,check item menu category, which, begin
switch (which) do(
case (category:coffee) menu subscriptions (2886, 2904)
#...
case (category:flavor) menu subscriptions (2889, 2921)
#...
)
endCode: Select all
script,no allergies affected,begin
generalallergytype := allergy:none
generalallergyvalue := 0
generalallergytype2 := allergy:none
generalallergyvalue2 := 0
endNote: Allergies will have three levels of intensity, as defined by the values. Customers will likely have their own "allergy tolerance" levels that will modify the allergy values so that a person with a strong tolerance will provide a low multiplier and those with a weak tolerance will provide a high multiplier (and those with no susceptibility will merely zero out the value).
Code: Select all
script,consignment category block equipment, string override = 0, text override = 2060,begin
consignment parameters (1, string override, 71, text override)
end
script,consignment category block items, string override = 0,text override 1 = 2062, text override 2 = 2063,begin
consignment parameters (2, string override, 70, text override 1, text override 2)
end
#...
script,consignment parameters,type = 0, str1 = 0, disp = 0, txt1 = 0, txt2 = 0,begin
itemtype := type
reporttype := type #refers to shop window displays (formerly consignmentreport) (for equipment)
consignmentstringsdisplay := str1
generalconsigntext := txt1
generalconsigntextaft := txt2
generalconsigndisplay := disp
endNote: There are currently 15 consignment categories, but cinnamon powder uses category 2.
Code: Select all
script,consignment package type,pack = 0,begin
switch (pack) do(
case (0) item text (2060) #equipment (standard)
case (1) item text (2066, 2067) #individual unit
case (4) item text (2062, 2063) #bag
case (5) item text (2064, 2065) #bottle
#...
)
end
script,item text,txt1 = 0, txt2 = 0,begin
generalconsigntext := txt1
generalconsigntextaft := txt2
endCode: Select all
script,set category menus, cat1 = 0, cat2 = 0, cat3 = 0,begin
menucat1 := cat1
menucat2 := cat2
menucat3 := cat3
end
script,read equipment item, scr1, cat1 = 0, cat2 = 0, cat3 = 0, begin
itemisequipment := true
set category menus (cat1, cat2, cat3)
consignment category block equipment
equipment sub categories (cat1)
equipment sub categories (cat2)
equipment sub categories (cat3)
no allergies affected
run script by id (scr1)
end
script,equipment sub categories, which, begin
if (which == category:coffee) then(
itemiscoffeemachine := true
)
if (which == category:conversion) then(
itemisconversiondevice := true
)
if (which == category:electronics) then(
itemiselectronic := true
consignment category block depreciated items
)
if (which == category:storage) then(
itemisstorage := true
)
if (which == category:blender) then(
itemisblender := true
)
if (which == category:juicer) then(
itemisjuicer := true
)
if (which == category:cooking) then(
itemiscookingdevice := true
)
if (which == category:dispenser) then(
itemisdispenser := true
)
if (which == category:tea) then(
itemisteabrewer := true
)
if (which == category:broken) then(
itemisbroken := true
consignment category block broken equipment
)
if (which == category:modded) then(
itemismodded := true
consignment category block modified
)
if (which == category:moddable) then(
itemismoddable := true
)
if (which == category:refurbished) then(
itemisrefurbished := true
consignment category block fixed equipment
)
endCode: Select all
script,read garnish item,scr1,cat = 0,begin
itemisgarnish := true
set category menus (cat)
if (cat == category:flavor) then(
itemiscoffeeflavoring := true
consignment category block items
consignment package type (4)
)
if (cat == category:dairy) then(
itemisdairy := true
itemcanspoil := true
consignment category block items
consignment package type (5)
generalallergytype := allergy:dairy
)
if (cat == category:preserved dairy) then(
itemisdairy := true
consignment category block items
consignment package type (7)
generalallergytype := allergy:dairy
)
if (cat == category:spoiled dairy) then(
itemisdairy := true
itemisspoiled := true
consignment category block trash
generalallergytype := allergy:dairy
generalallergytype2 := allergy:spoiled
)
if (cat == category:processed dairy) then(
itemisdairy := true
itemisprocessed := true
consignment category block processed
generalallergytype := allergy:dairy
)
if (cat == category:ice dairy) then(
itemisdairy := true
itemcanmelt := true
itemisfrozen := true
consignment category block items
consignment package type (15)
generalallergytype := allergy:dairy
)
if (cat == category:melted dairy) then(
itemisdairy := true
itemcanfreeze := true
itemismelted := true
consignment category block trash
generalallergytype := allergy:dairy
)
if (cat == category:chiller) then(
itemcanmelt := true
itemisfrozen := true
consignment category block items
consignment package type (4)
)
if (cat == category:liqueur) then(
itemisliqueur := true
itemisalcoholic := true
consignment category block items
consignment package type (120)
generalallergytype := allergy:alcohol
)
if (cat == category:perks syrup) then(
itemiscoffeebean := true
itemiscoffeeflavoring := true
itemisperk := true
consignment category block items
consignment package type (119)
)
run script by id (scr1)
endCode: Select all
script,special consignment pricing instructions, fract = 0, cent = 0,begin
fractionprice := fract #for trash items only (number required to make a dollar on consignment)
centsprice := cent #for processed items only (nominator over item unit value)
endThe next few scripts are shell scripts that transfer item-specific values to general variables. These are the values that I define on each item's definition page. This is what allows me to cut my item implementation time down from one day to a few minutes. I'll include every section here, even those that do not relate to cinnamon powder, but explain only those that may not be obvious by reading what they say. If you want more information on any of these topics, let me know.
Code: Select all
script,equipment parameter essentials, it = 0, eqset = 0, eqactive = 0, eqinuse = 0, eqbought = 0, eqsold = 0, ittrend = 0, itcomp = 0,begin
generalitem := it
generalequipset := eqset
generalequipactive := eqactive
generalequipinuse := eqinuse
generalequipdaybought := eqbought
generalequipdaysold := eqsold
generalitemtrend := ittrend
generalcompareitem := itcomp
end
script,trying to buy, reg = 0, post = 0,begin
generaltrytobuy := reg
generaltrytobuypost := post
end
script,equipment have use shop item sell tags, have tag = 0, use tag = 0, shop tag = 0, item tag = 0, sell tag = 0, begin
generalhaveitemtag := have tag
generaluseitemtag := use tag
generalshopitemtag := shop tag
generalitemtag := item tag
generalsellitemtag := sell tag
end
script,item parameter essentials, it = 0, servit = 0, ittrend = 0, itcomp = 0,begin
generalitem := it
generalitemunit := servit
generalitemtrend := ittrend
generalcompareitem := itcomp
end
script,item have use shop item tags, have tag = 0, use tag = 0, shop tag = 0, item tag = 0, begin
generalhaveitemtag := have tag
generaluseitemtag := use tag
generalshopitemtag := shop tag
generalitemtag := item tag
end
script,component object essentials, obset = 0, obcap = 0, obcur = 0, obfull = 0, obempty = 0, obinst = 0, begin
generalobjectset := obset
generalobjectcapacity := obcap
generalobjectcurrent := obcur
generalobjectfull := obfull
generalobjectempty := obempty
generalobjectinstalled := obinst
endCode: Select all
script,equipment shop settings, shop = 0, case id = 0, shop item id = 0, item price = 0, item shelf space = 0, item content capacity = 0, begin
if (current map == shop) then(
generalshopid := shop item id
generalprice := item price
generalshelfspace := item shelf space
shopcaseid := case id
dynamicshoplocation := shop
generalequipcapacity := item content capacity
)
endCode: Select all
script,item shop settings, shop = 0, case id = 0, shop item id = 0, item price = 0, item quantity = 0, item shelf space = 0, item content capacity = 0, begin
if (current map == shop) then(
generalshopid := shop item id
generalprice := item price
generalinitialquantity := item quantity
generalshelfspace := item shelf space
shopcaseid := case id
dynamicshoplocation := shop
generalobjectcapacity := item content capacity
)
end
script,item trash settings, item price = 0, item quantity = 0, item shelf space = 0, begin
if (itemisused) then(
generalprice := item price
generalinitialquantity := item quantity
generalshelfspace := item shelf space
)
endCode: Select all
script,item mean values, item price = 0, item quantity = 0, item capacity = 0, begin
meanitemprice := item price #useful info for consignments
meanitemquantity := item quantity
meanitemcapacity := item capacity
endCode: Select all
script,special pawn conditions, pawn tag = 0, pawn type = 0,begin
generalpawnitemtag := pawn tag
generalpawntype := pawn type
end
script,item dimensions, itsiz = 0, itwt = 0,begin
itemsize := itsiz
itemweight := itwt
endDid I mention that inventories will have limits soon?
Code: Select all
script,item prime texts, to buy = 0, acquire = 0, inv = 0, begin
originalitemtext := to buy
generalacqtext := acquire
generalitemtext := inv
endCode: Select all
script,equipment peripheral tags, plug = 0, filt = 0, begin
generalpluglocationtag := plug #this will be dynamic eventually
generalfilterdiscardtag := filt #this will change with multiple versions
endCode: Select all
script,item temperature values, heat min = 0, heat max = 0, current heat = 0, begin
itembestheatminimum := heat min
itembestheatmaximum := heat max
itemcurrentheatvalue := current heat
endCode: Select all
script,item condition bonus stats, flav = 0, comf = 0, addic = 0, qual = 0, hlth = 0, lvl = 0, csb = 0, dol = 0,begin
generalitemflavor := flav
generalitemcomfort := comf
generalitemaddictive := addic
generalitemquality := qual
generalitemhealth := hlth
generalitemlevel := lvl
generalitemcsbonus := csb
generaladdadollar := dol
endCode: Select all
script,additional bonus special features, scene = 0, spc = 0, ent = 0, qual = 0, info = 0, csb = 0, begin
generalitemscenerybonus := scene
generalitemspecialbonus := spc
generalitementertainmentbonus := ent
generalitemspecialqualitybonus := qual
generaliteminformationbonus := info
generalitemspecialcsbonus := csb
endCode: Select all
script, item flavor meter, sweet = 0, sour = 0, bitter = 0, earthy = 0, fruity = 0, acidic = 0, rich = 0, silky = 0, spicy = 0, salty = 0, choco = 0, meaty = 0, smoky = 0, eggy = 0, oily = 0, viney = 0, creamy = 0, woody = 0, wheaty = 0, nutty = 0, doughy = 0, moldy = 0, bubbly = 0, misc = 0,begin
generalitemsweetflavor := sweet
generalitemsourflavor := sour
generalitembitterflavor := bitter
generalitemearthflavor := earthy
generalitemfruitflavor := fruity
generalitemacidicflavor := acidic
generalitemrichflavor := rich
generalitemsilkflavor := silky
generalitemspicyflavor := spicy
generalitemsaltflavor := salty
generalitemcocoaflavor := choco
generalitemmeatflavor := meaty
generalitemsmokeflavor := smoky
generalitemeggflavor := eggy
generalitemoilyflavor := oily
generalitemvinegarflavor := viney
generalitemcreamyflavor := creamy
generalitemwoodyflavor := woody
generalitemwheatflavor := wheaty
generalitemnuttyflavor := nutty
generalitemdoughyflavor := doughy
generalitemmoldyflavor := moldy
generalitembubblyflavor := bubbly
generalitemmiscflavor := misc
end
script, item comfort meter, cool = 0, heat = 0, soft = 0, firm = 0, dry = 0, wet = 0, smooth = 0, velvet = 0, sharp = 0, carpet = 0, spongey = 0, prickly = 0, coarse = 0, sticky = 0, slimy = 0, cold = 0, hot = 0, tingle = 0, shock = 0, vibrate = 0, bubbly = 0, relief = 0, gross = 0, misc = 0,begin
generalitemcoolcomfort := cool
generalitemheatcomfort := heat
generalitemsoftcomfort := soft
generalitemfirmcomfort := firm
generalitemdrycomfort := dry
generalitemwetcomfort := wet
generalitemsmoothcomfort := smooth
generalitemvelvetcomfort := velvet
generalitemsharpcomfort := sharp
generalitemcarpetcomfort := carpet
generalitemspongecomfort := spongey
generalitempricklycomfort := prickly
generalitemcoarsecomfort := coarse
generalitemstickycomfort := sticky
generalitemslimycomfort := slimy
generalitemcoldcomfort := cold
generalitemhotcomfort := hot
generalitemtinglecomfort := tingle
generalitemshockcomfort := shock
generalitemvibratecomfort := vibrate
generalitembubblycomfort := bubbly
generalitempainreliefcomfort := relief
generalitemgrosscomfort := gross
generalitemmisccomfort := misc
endCode: Select all
script,item saturations, flav = 0, comf = 0, addic = 0, qual = 0, hlth = 0, lvl = 0, csb = 0, begin
#Note: These values seem to be affected during brewing. Best to leave them at zero for now.
generalitemoverflavor := flav
generalitemovercomfort := comf
generalitemoveraddictive := addic
generalitemoverquality := qual
generalitemoverhealth := hlth
generalitemoverlevel := lvl
generalitemovercsbonus := csb
endCode: Select all
script,item bonus display values,begin
append number (47,generalinitialquantity)
append number (27,generalprice)
display modification value shifts (28,generalitemflavor)
display modification value shifts (49,generalitemcomfort)
display modification value shifts (42,generalitemaddictive)
display modification value shifts (43,generalitemquality)
display modification value shifts (44,generalitemhealth)
display modification value shifts (29,generalitemcsbonus)
append number (45,generalitem)
append number (46,generalitemunit)
end
script,item null display values,begin
append number (47,generalinitialquantity)
append number (27,generalprice)
$28="n/a"
$49="n/a"
$42="n/a"
$43="n/a"
$44="n/a"
$29="n/a"
append number (45,generalitem)
append number (46,generalitemunit)
endThe next section I'm omitting from this report because it's focused entirely on equipment items and I want to keep this from getting too complex to read. I may do a separate feature on equipment if there's any interest.
Code: Select all
script,altered state meta check, which = 0, begin
#The following section refers to special metadata for broken and trash items, as well as unique social and moddable items.
#These won’t apply to most store-bought items.
#I need to decide if I want a broken subcategory, or just make broken items their own item.
switch (which) do(
#...
case (compareitem:cream) do(
dairy spoil conditions (creamspoil, goodcream1, spoiledcream, 494)
)
case (compareitem:milk) do(
dairy spoil conditions (milkspoil, goodmilk1, spoiledmilk, 495)
)
#...
)
end
#...
script,dairy spoil conditions, tospoil = 0, gooditem = 0, spoil version = 0, spoil tag = 0, begin
itemtospoil := tospoil
generalgooditem1 := gooditem
generalspoileditem := spoil version
spoileditemtag := spoil tag
endCode: Select all
script,overabundances,begin
#toosweet - for sugar
#toorich - for cream (all types)
#toosaturated - for milk (all types)
#toothick - for ice cream
#toosandy - for cinnamon
#toobitter - for powdered grass and old salt
#toonasty - for spoiled garnishes
#toostrong
#toospicy
#toocold
#toohot
#tooboring
#Note: This section connects to “Check Garnishing Tray.�
#I may want to redo how this works, especially with the customer response texts.
#if (itemisgarnish) then(
# generaloverabundance := toosandy
# $56="Too Sandy!"
#)
endCode: Select all
script,dynamic shopping conditions,begin
#This section is for dynamic shopping
#Update to shopcaseid if this section is independent of shop scripts
dynamicitemisvalid := false
switch (generalshoplocation) do(
case (dynamicshoplocation) do(
if (generalshopitem == shopcaseid) then(
dynamicitemisvalid := true
)
)
)
endCode: Select all
script,display modification value shifts, str = 0, value = 0,begin
clear string (74)
if (value >> 0) then(
$74="+%d"
)
else(
$74="%d"
)
string sprintf (str,74,value)
end Code: Select all
script,record item special case, case = 0, attrib = 0,begin
itemspecialcase := case
specialattribute := attrib
endCode: Select all
script,allergies affected, alg1 = 0, algval1 = 0, alg2 = 0, algval2 = 0,begin
generalallergytype := alg1
generalallergyvalue := algval1
generalallergytype2 := alg2
generalallergyvalue2 := algval2
endAdditional scripts for yard equipment and health items have been omitted from this report.
Code: Select all
script,object name string, whichmain = 0, whichartc = 0, whichhold = 0, whichsub1 = 0, whichsub2 = 0, whichabbr = 0, scr = 0, begin
if (specialtextdisplay) then(
copy string (9, whichmain) #$9="Store Powder"
copy string (57, whichartc) #$57="is"
)
if (itemisholdover) then(
copy string (30, whichhold) #$30="Store Powder"
)
if (checktag (2203)) then( #prep item reports
copy string (11, whichsub1) #$11="Store Powder" (may need new string)
copy string (12, whichsub2)
)
#This section is for shop display slices (equipment)
if (checktag (2203)==false) then(
if (itemwindow1) then(
copy string (12, whichmain) #$12="Store Powder"
shopping item rewrite strings (generalcompareitem)
)
if (itemwindow2) then(
copy string (12, whichmain) #$12="Store Powder"
if (scr<>0) then(
run script by id (scr) #item bonus display values
)
)
)
#for end of day trends reporting
if (checktag (2637)) then(
copy string (2, whichmain) #$2="Store Powder"
)
#for standard shopping cart windows (consult old “record list,cur� for comparison strings)
if (checktag (2638)) then(
copy string (2, whichabbr) #$2="S.Powder x"
)
endCode: Select all
script,finisher interactive text, conv1 = 0, conv2 = 0, begin
conversiontext1 := conv1
conversiontext2 := conv2
endAnd those are some of the formulas and shell scripts I use to help me keep control of new item additions.
The Item Sheet:
And now it's time for the main event, the item sheet. Note that this is the main script out of three that must be written from scratch or modified from a template to get an item into the game. The other two essential scripts are "locate item" (listed at the top of this post) and "write to item" (not featured in this post, but is essentially a shorter reversal of the item sheet listed below, used to transfer general data back to the item).
Note: For special or converted items, "altered state meta check" is also important.
Code: Select all
script,read cinnamon powder data,begin
generalitemid := 22
item mean values (30, 50)
multiplelocations := true
item parameter essentials (
cinnamon,
servcinnamon,
cinnamontrend,
compareitem:cinnamon
)
trying to buy (trytobuy23, trytobuy23post)
item have use shop item tags (141, 142, 56, 25)
item shop settings (4, 8, groceritem8, 30, 50, 100) #shop, item id num, item id var, price, quantity, stock, capacity
item shop settings (27, 75, sassyitem75, 32, 50, 100) #shop, item id num, item id var, price, quantity, stock, capacity
item prime texts (119, 93, 47) #to buy, acquire, inventory
item dimensions (0, 0) #size, weight
item temperature values (0, 0, 0) #best heat min, best heat max, current heat
item condition bonus stats (2, 0, 0, 0, 0, 1, 0, 0) #flavor, comfort, addictive, quality, health, level, cs bonus, add a dollar
item flavor meter (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) #sweet, sour, bitter, earthy, fruity, acidic, rich, silky, spicy, salty, choco, meaty, smoky, eggy, oily, viney, creamy, woody, wheaty, nutty, doughy, moldy, bubbly, miscellanous
item comfort meter (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) #cool, heat, soft, firm, dry, wet, smooth, velvet, sharp, carpet, spongey, prickly, coarse, sticky, slimy, cold, hot, tingle, shock, vibrate, bubbly, pain relief, gross, miscellanous
item saturations (-2, 0, 0, 0, 0, 0, 0) #flavor, et al.
combobonusactive := false
altered state meta check (generalcompareitem)
special consignment pricing instructions (0, 0) #fraction, cent
#Shopping
$9="Cinnamon Powder" #special text display item
$57="is" #special text display article
$30="Cinnamon Powder" #holdover info
$11="Cinnamon" #prep item report a
$12="Powder" #prep item report b
$2="Cinnamon x" #shopping list
object name string (9, 57, 30, 11, 12, 2, @item bonus display values)
overabundances
dynamic shopping conditions
allergies affected (allergy:cinnamon, 2)
record item special case (cinnamonspiced, attribute:quality)
finisher interactive text (5147, 5148)
endIf all goes well, I can also use this system to make everything into a coffee garnish, for better or for worst, with a few more adjustments. Ever wanted to see what would happen if you put bananas in your coffee? Yeah, me, too.
I still have about half of the 300 series of items to implement, which includes advertising, electronics, and office items, and all of the 400 series of items (right now, there are 12, and they're all pastries). When that's done, I need to go back and fill in some of the zeroed items like height, weight, temperature, and exact flavors and comfort levels, as well as most of the altered state values. Then I need to finish my consignment categories (I've got one or two left to define), turn previously arbitrary items like teddy bears and videocassettes into actual defined items, possibly pushing me into the 500 series of items, complete the "write to item" section, and then finish checking my various shop, consignment, and pavilion formulas to make sure everything will work and make the necessary adjustments. By then, I should be ready to package the next experimental release, 1.2.2.
Hopefully production will start going faster after that. Exciting, right?
By the way, the 10th anniversary of me beginning this madness happens on May 12th. Mark your calendars.
Place Obligatory Signature Here
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
So, today is May 12th, Entrepreneur’s birthday, and this begins its tenth year of production. Therefore, I think it’s a good time to reflect on the state of the game, past and present.
The game started with a lofty idea: create an adventure-based prequel to a game that I had stewing in my mind, called Entrepreneur: The Perfect Frappuccino, and turn it loose as an 8-bit game for that year’s 8-bit Contest. On May 12, 2009, I created the game file, developed a test room to see how well my idea would work, sent it to James to test it, and used what I learned to begin building the actual game. My rapid prototyping escalated quickly, and I somehow managed to release a semi-playable tycoon adventure game on the OHR in just under 30 days. It was messy and ugly, but it worked for the most part. After the initial release, I’d spent a week fixing bugs and finishing features that I didn’t have time to finish for the contest (and no one would likely discover anyway, as the unfinished stuff happened halfway into the game). Then I spent a few more sessions between June 14 and July 6, 2009, prepping for version 1.2 content. And that was it for the rest of the year and much of the first half of 2010. All of that progress simply stopped. I spent much of the interim working on Powerstick Man related things, including the novel versions of the story line, but I kept thinking about that coffee game I’d made the previous year, and I wondered if I could do better. Finally, when the summer of 2010 rolled around, I thought it was time to stop thinking and start picking up on development again. So I did. I stayed relatively consistent after that, or at least I kept up with it more than once every ten months.
Version 1.2 was supposed to contain all of the features I’d wanted for 1.1, including the infamous “hostile takeovers� feature. Instead of diving right into the coffee simulation I had started in 2009, however, I went to work on the chores system, where Buck can do yardwork for the people of Pine Alley Drive. I spent the better part of a year on that system. None of the coffee-related updates would come until well into 2011. Once I moved back to the coffee parts of the game, I worked on customer behavior, better flow control (the game was notorious for pausing to wait for scripts to finish in those early days—now most customer behavior happens on timers), better information delivery, and a number of other quality of life features to make the game less of a mystery or a burden to players. I spent until 2013 trying to cram in everything I thought the game needed to be more complete and more of a challenge, until September when I finally released 1.2 to the public.
Just like the 1.1 release, 1.2 didn’t receive a lot of fanfare. By that time, HamsterSpeak Magazine had completed its run. The community was active but busy with life. And, Entrepreneur: The Beginning wasn’t an RPG or a good-looking game, so it was understandably soft on the landing. But then Spoonweaver revived the OHR Book Club (though I think it was called something different under his leadership) and chose Entrepreneur 1.2 as its opening focus. Finally, some feedback!
It was mostly negative feedback, but good negative feedback. It helped inform my plans for 1.3, which I started on right away. The number one concern had to do with the tutorial, which I had implemented late into 1.2’s development. It was essentially incomplete. So, my primary goal for 1.3 would be to write a better tutorial, which is still on the to-do list as of today. But I started 1.3 by finishing the shops I had begun in 1.2 to encourage the game’s push toward tracking customer health. I also implemented some features left unfinished in 1.2, like the ability to fix teddy bears and the ability to sell desserts to customers.
All was well and typical until sometime late in 2014 when I conceded to the fact that items took too long to implement and that production on the game was moving way too slowly. I kept at it, but my decision to add more than 200 items into the game at once turned into a bottleneck for the game’s development that would last two years. Sure, I worked on other minor features along the way so that the game wouldn’t suffer a drought, including the implementation of six new shops and a brand new beach zone. But the game had taken a noticeable turn into the unproductive slog, and I was growing frustrated at my lack of momentum. After more than five, six, and seven years of development, I had surprisingly little to show for it.
By February 2017, I’d decided I’d had enough of the slog. It was time to take development back into more reasonable hands. It was time to reorganize the game so that it would become more efficient and make more sense to me moving forward. I started by developing an Excel spreadsheet that contained all of the existing items and a list of all of their various attributes, including tag information, prices, values, and so on. Having a quick view access of every item would save me time plugging in their values as I applied them to new formulas. Then I started a Scrivener Edition of the development journal to help me keep better track of categories and development plans. As of this writing, I’m woefully behind, but what I have so far has given me a strong basis for how to continue once the reorganization is finished. Then, heading into the summer of 2017, I finally started on my greatest undertaking yet, rewriting the more than 1000 scripts that make up the game’s inner workings to make the game more adaptable in the future. This included developing a transfer system that would allow me to copy specific values related to customers, shops, and items to general variables that I’d use in each of the game’s essential functions and formulas, and transfer any value changes back to each source, creating a means to add new items, shops, and customers without having to hunt down every script designed to affect them and manually plug in their variables. This change alone would cut my development time down by 2000% (approximately). It comes with a hefty front end, of course. The fact that I’m still overhauling the game’s scripting should be a testament to that. But, as of this writing, a task like adding a new item that would take me an average six to eight hours to accomplish in 2014 now takes me about 15 to 20 minutes. That’s significant.
But, there’s still more work to do, and I’m still finding more efficient measures to make the game work better and become more adaptable to future plans. My next goal is to cut down on the required resources to make the game work. As of this writing, I’m developing a plan for reducing my need for global variables by transferring as much data as I can into arrays. I’m also developing a plan for reducing my string dependence and for ultimately breaking functions down into lists and categories. This means my scripting rewrites may take another few months to complete, and version 1.2.2 may not be ready before the end of the year. But it does mean that once everything is in place, the road to 1.7 can come much, much faster.
So, that’s the state of Entrepreneur: The Beginning ten years later. Like a human ten-year-old, it’s starting to mature a little. But, it'll probably become obnoxious a few years from now. We'll see.
The game started with a lofty idea: create an adventure-based prequel to a game that I had stewing in my mind, called Entrepreneur: The Perfect Frappuccino, and turn it loose as an 8-bit game for that year’s 8-bit Contest. On May 12, 2009, I created the game file, developed a test room to see how well my idea would work, sent it to James to test it, and used what I learned to begin building the actual game. My rapid prototyping escalated quickly, and I somehow managed to release a semi-playable tycoon adventure game on the OHR in just under 30 days. It was messy and ugly, but it worked for the most part. After the initial release, I’d spent a week fixing bugs and finishing features that I didn’t have time to finish for the contest (and no one would likely discover anyway, as the unfinished stuff happened halfway into the game). Then I spent a few more sessions between June 14 and July 6, 2009, prepping for version 1.2 content. And that was it for the rest of the year and much of the first half of 2010. All of that progress simply stopped. I spent much of the interim working on Powerstick Man related things, including the novel versions of the story line, but I kept thinking about that coffee game I’d made the previous year, and I wondered if I could do better. Finally, when the summer of 2010 rolled around, I thought it was time to stop thinking and start picking up on development again. So I did. I stayed relatively consistent after that, or at least I kept up with it more than once every ten months.
Version 1.2 was supposed to contain all of the features I’d wanted for 1.1, including the infamous “hostile takeovers� feature. Instead of diving right into the coffee simulation I had started in 2009, however, I went to work on the chores system, where Buck can do yardwork for the people of Pine Alley Drive. I spent the better part of a year on that system. None of the coffee-related updates would come until well into 2011. Once I moved back to the coffee parts of the game, I worked on customer behavior, better flow control (the game was notorious for pausing to wait for scripts to finish in those early days—now most customer behavior happens on timers), better information delivery, and a number of other quality of life features to make the game less of a mystery or a burden to players. I spent until 2013 trying to cram in everything I thought the game needed to be more complete and more of a challenge, until September when I finally released 1.2 to the public.
Just like the 1.1 release, 1.2 didn’t receive a lot of fanfare. By that time, HamsterSpeak Magazine had completed its run. The community was active but busy with life. And, Entrepreneur: The Beginning wasn’t an RPG or a good-looking game, so it was understandably soft on the landing. But then Spoonweaver revived the OHR Book Club (though I think it was called something different under his leadership) and chose Entrepreneur 1.2 as its opening focus. Finally, some feedback!
It was mostly negative feedback, but good negative feedback. It helped inform my plans for 1.3, which I started on right away. The number one concern had to do with the tutorial, which I had implemented late into 1.2’s development. It was essentially incomplete. So, my primary goal for 1.3 would be to write a better tutorial, which is still on the to-do list as of today. But I started 1.3 by finishing the shops I had begun in 1.2 to encourage the game’s push toward tracking customer health. I also implemented some features left unfinished in 1.2, like the ability to fix teddy bears and the ability to sell desserts to customers.
All was well and typical until sometime late in 2014 when I conceded to the fact that items took too long to implement and that production on the game was moving way too slowly. I kept at it, but my decision to add more than 200 items into the game at once turned into a bottleneck for the game’s development that would last two years. Sure, I worked on other minor features along the way so that the game wouldn’t suffer a drought, including the implementation of six new shops and a brand new beach zone. But the game had taken a noticeable turn into the unproductive slog, and I was growing frustrated at my lack of momentum. After more than five, six, and seven years of development, I had surprisingly little to show for it.
By February 2017, I’d decided I’d had enough of the slog. It was time to take development back into more reasonable hands. It was time to reorganize the game so that it would become more efficient and make more sense to me moving forward. I started by developing an Excel spreadsheet that contained all of the existing items and a list of all of their various attributes, including tag information, prices, values, and so on. Having a quick view access of every item would save me time plugging in their values as I applied them to new formulas. Then I started a Scrivener Edition of the development journal to help me keep better track of categories and development plans. As of this writing, I’m woefully behind, but what I have so far has given me a strong basis for how to continue once the reorganization is finished. Then, heading into the summer of 2017, I finally started on my greatest undertaking yet, rewriting the more than 1000 scripts that make up the game’s inner workings to make the game more adaptable in the future. This included developing a transfer system that would allow me to copy specific values related to customers, shops, and items to general variables that I’d use in each of the game’s essential functions and formulas, and transfer any value changes back to each source, creating a means to add new items, shops, and customers without having to hunt down every script designed to affect them and manually plug in their variables. This change alone would cut my development time down by 2000% (approximately). It comes with a hefty front end, of course. The fact that I’m still overhauling the game’s scripting should be a testament to that. But, as of this writing, a task like adding a new item that would take me an average six to eight hours to accomplish in 2014 now takes me about 15 to 20 minutes. That’s significant.
But, there’s still more work to do, and I’m still finding more efficient measures to make the game work better and become more adaptable to future plans. My next goal is to cut down on the required resources to make the game work. As of this writing, I’m developing a plan for reducing my need for global variables by transferring as much data as I can into arrays. I’m also developing a plan for reducing my string dependence and for ultimately breaking functions down into lists and categories. This means my scripting rewrites may take another few months to complete, and version 1.2.2 may not be ready before the end of the year. But it does mean that once everything is in place, the road to 1.7 can come much, much faster.
So, that’s the state of Entrepreneur: The Beginning ten years later. Like a human ten-year-old, it’s starting to mature a little. But, it'll probably become obnoxious a few years from now. We'll see.
Last edited by Pepsi Ranger on Sun May 12, 2019 9:08 pm, edited 1 time in total.
Place Obligatory Signature Here
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
It's been a while since the last update, so I think it's time to post a new one.
I'll start by saying that my work for the last nine months has given me a headache. As I've mentioned in the previous post, I had decided I would move all of my data structures to fake arrays. I made this decision because I was told that using global variables to design data structures is "the wrong way" of doing it. Given what arrays are supposed to do, I'll say that I agree.
But, I still think using global variables for all data storage and manipulation is much, much easier, or at least it is when the alternative is to use fake arrays.
I've actually been working with a separate test file since last summer to learn how to use arrays properly. I've gotten the basics down, but when it comes to the complicated nature of applying them to specific storage containers, item states, and all of the flexible things I want to do (and currently do with global variables), I realize that the current way of implementing arrays (because they're not real arrays) is making the job far more complicated and hard to manage than it needs to be. Every time I look at my scripts now (the ones that use simple fake arrays), I get a headache. They're supposed to be written like filing cabinets, with their contents representing folders of information (an easy concept to grasp for sure), but because they're slice-based, I find that managing them within the context of what I want to accomplish is an utter nightmare. Every time I look at them, it takes me a while to recognize what I'm seeing, what everything means, and what it connects to.
In short, I don't have the memory anymore to keep track of what every slice is doing, or what I should be storing in it, or when I should close it, or how I should connect it to relevant containers, and so on.
Global variables are just easier. I know what they're called. I know what they represent. I know how to use them in the context of transferring information. I don't worry about them corrupting anything. They don't confuse the crap out of me. When I read them, I know what they mean and what they're used for. They don't make my brain hurt.
Fake arrays make me want to punch the computer screen. But they're more efficient!
I know I should be using arrays. Their existence makes perfect sense. I think my headache comes from how they're used in the OHR. On the one hand, I know I should be writing my scripts to account for future real arrays, so that I have a lot less work to do when they're finally implemented. On the other hand, I just want to finish my game, and any system that forces me to relearn it every time I sit down and try to work is not worth using in my opinion. I've literally done no work on this game since last summer because I'm having immense difficulty retaining my knowledge of using fake arrays and making them do what I want them to do. Even my test file that has nothing to do with the game has been a slog, and it's only maybe a dozen scripts long.
I don't know if the problem is with how fake arrays work, or if I'm just losing my sense of organization. I suspect it's the latter because the basic principles behind fake arrays are not difficult to grasp. I get how they work. I'm just having the worst time fitting them into a structure that will allow me to "plug in" new item definitions and inventories based on the need while remembering what every component in the array(s) is supposed to represent. That's a big deal because, if you recall, the whole reason why I'm restructuring my scripts at all is to make my design efforts move along much faster. Again, the thing about global variables that I like so much is that I don't need to think about them once they're defined. I don't need to remember what their values represent. I can just use them as needed, according to their name. I can read and write them through functions, maximizing their universal accessibility. That's part of their design.
With fake arrays, I have to remember what every part represents, double-check the positions of values to make sure I'm not pointing at the wrong thing when calling up or changing a value, manage the open and closed states of the slices that contain them, possibly open hundreds of slices at once to keep the values from erasing out of existence, identify values based on locations and whatever actions the player takes, store values that represent object states as well as counts, and just a mess of other elements that wouldn't be so bad if I had a better organization system.
I'm not quite sure how to effectively organize a "filing" system using fake arrays, or to attach arrays to an adaptive universal script that I can use as a hub to create new items with states and track them. I just know how to store values according to array position and change them, assuming I remember what the array is called and what the position represents. And, that's probably all I need to know. So, I don't really know why it looks likes a puzzle because it shouldn't. But it does.
So, that's the latest update. My efforts to update my systems from global variables to fake arrays make me want to quit. It's like pouring the ocean through a straw.
That said, I'm still trying to pull it all together. I'm also tempted to start over (the test file, NOT the game). I'm using well-named constants, functions, tag names, etc. to label everything the best that I can, but jamming those fake arrays into a single global variable with all of their components and trying to do everything "the right way" makes remembering what each component does maddening, and the whole system keeps falling outside of the scope of sanity. This game is already plenty complicated without it.
I don't know. I'm probably just losing my touch. Even the systems I know well are starting to look more complicated than they are. Can't say I'm happy about that.
I'll start by saying that my work for the last nine months has given me a headache. As I've mentioned in the previous post, I had decided I would move all of my data structures to fake arrays. I made this decision because I was told that using global variables to design data structures is "the wrong way" of doing it. Given what arrays are supposed to do, I'll say that I agree.
But, I still think using global variables for all data storage and manipulation is much, much easier, or at least it is when the alternative is to use fake arrays.
I've actually been working with a separate test file since last summer to learn how to use arrays properly. I've gotten the basics down, but when it comes to the complicated nature of applying them to specific storage containers, item states, and all of the flexible things I want to do (and currently do with global variables), I realize that the current way of implementing arrays (because they're not real arrays) is making the job far more complicated and hard to manage than it needs to be. Every time I look at my scripts now (the ones that use simple fake arrays), I get a headache. They're supposed to be written like filing cabinets, with their contents representing folders of information (an easy concept to grasp for sure), but because they're slice-based, I find that managing them within the context of what I want to accomplish is an utter nightmare. Every time I look at them, it takes me a while to recognize what I'm seeing, what everything means, and what it connects to.
In short, I don't have the memory anymore to keep track of what every slice is doing, or what I should be storing in it, or when I should close it, or how I should connect it to relevant containers, and so on.
Global variables are just easier. I know what they're called. I know what they represent. I know how to use them in the context of transferring information. I don't worry about them corrupting anything. They don't confuse the crap out of me. When I read them, I know what they mean and what they're used for. They don't make my brain hurt.
Fake arrays make me want to punch the computer screen. But they're more efficient!
I know I should be using arrays. Their existence makes perfect sense. I think my headache comes from how they're used in the OHR. On the one hand, I know I should be writing my scripts to account for future real arrays, so that I have a lot less work to do when they're finally implemented. On the other hand, I just want to finish my game, and any system that forces me to relearn it every time I sit down and try to work is not worth using in my opinion. I've literally done no work on this game since last summer because I'm having immense difficulty retaining my knowledge of using fake arrays and making them do what I want them to do. Even my test file that has nothing to do with the game has been a slog, and it's only maybe a dozen scripts long.
I don't know if the problem is with how fake arrays work, or if I'm just losing my sense of organization. I suspect it's the latter because the basic principles behind fake arrays are not difficult to grasp. I get how they work. I'm just having the worst time fitting them into a structure that will allow me to "plug in" new item definitions and inventories based on the need while remembering what every component in the array(s) is supposed to represent. That's a big deal because, if you recall, the whole reason why I'm restructuring my scripts at all is to make my design efforts move along much faster. Again, the thing about global variables that I like so much is that I don't need to think about them once they're defined. I don't need to remember what their values represent. I can just use them as needed, according to their name. I can read and write them through functions, maximizing their universal accessibility. That's part of their design.
With fake arrays, I have to remember what every part represents, double-check the positions of values to make sure I'm not pointing at the wrong thing when calling up or changing a value, manage the open and closed states of the slices that contain them, possibly open hundreds of slices at once to keep the values from erasing out of existence, identify values based on locations and whatever actions the player takes, store values that represent object states as well as counts, and just a mess of other elements that wouldn't be so bad if I had a better organization system.
I'm not quite sure how to effectively organize a "filing" system using fake arrays, or to attach arrays to an adaptive universal script that I can use as a hub to create new items with states and track them. I just know how to store values according to array position and change them, assuming I remember what the array is called and what the position represents. And, that's probably all I need to know. So, I don't really know why it looks likes a puzzle because it shouldn't. But it does.
So, that's the latest update. My efforts to update my systems from global variables to fake arrays make me want to quit. It's like pouring the ocean through a straw.
That said, I'm still trying to pull it all together. I'm also tempted to start over (the test file, NOT the game). I'm using well-named constants, functions, tag names, etc. to label everything the best that I can, but jamming those fake arrays into a single global variable with all of their components and trying to do everything "the right way" makes remembering what each component does maddening, and the whole system keeps falling outside of the scope of sanity. This game is already plenty complicated without it.
I don't know. I'm probably just losing my touch. Even the systems I know well are starting to look more complicated than they are. Can't say I'm happy about that.
Place Obligatory Signature Here
-
SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
arrays aren't fundamentally different from global variables.
they can just be arranged and reordered
here are some tips.
- you can access and manipulate data in an array the same as a global variable. there is no real difference, but you have to write your own script to do so.
the advantages are that you can store as many variables as you like
- try giving your slices a lookup code. this not only identifies parts of your array, but you can look in the slice debugger to see things more easily. also you can search for a lookup code!
- use a hierarchical structure for your slice tree. create a root node to contain all relevant slices. you might have a root node for each item, location, character etc., with many data nodes each
- somewhat more difficult is arranging your slices. don't think of it like an array, a list of variables, think of it as a tree with branches.
there are 2 approaches I can think of
1. parent to the most relevant slice. for example, an item (slice) in an item shop (root node) can be transferred to the player (root node) when they acquire the item
2. have all your slices exist in a list, and don't reparent them. but create a child for each item (slice) that denotes the owner. and update it as needed.
you can write wrappers around your array bits quite easily, to check the ownership of an item (slice), either searching it for a child slice that represents the owner, or checking who the parent it.
or something like that
arrays aren't really different from variables, but the big thing is being able to arrange them and add bits of data to them however/wherever you like.
sorry if thats not helpful.
they can just be arranged and reordered
here are some tips.
- you can access and manipulate data in an array the same as a global variable. there is no real difference, but you have to write your own script to do so.
the advantages are that you can store as many variables as you like
- try giving your slices a lookup code. this not only identifies parts of your array, but you can look in the slice debugger to see things more easily. also you can search for a lookup code!
- use a hierarchical structure for your slice tree. create a root node to contain all relevant slices. you might have a root node for each item, location, character etc., with many data nodes each
- somewhat more difficult is arranging your slices. don't think of it like an array, a list of variables, think of it as a tree with branches.
there are 2 approaches I can think of
1. parent to the most relevant slice. for example, an item (slice) in an item shop (root node) can be transferred to the player (root node) when they acquire the item
2. have all your slices exist in a list, and don't reparent them. but create a child for each item (slice) that denotes the owner. and update it as needed.
you can write wrappers around your array bits quite easily, to check the ownership of an item (slice), either searching it for a child slice that represents the owner, or checking who the parent it.
or something like that
arrays aren't really different from variables, but the big thing is being able to arrange them and add bits of data to them however/wherever you like.
sorry if thats not helpful.
-
Bob the Hamster
- Lord of the Slimes
- Posts: 7732
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Yes, thank you for saying that. That's what I'm figuring out. I only bring it up because I prefer using global variables for all of my values since they're easy to recognize, but this game is a devourer of variables, so I've been advised to use a system that uses far fewer of them. The reason for using arrays makes perfect sense to me. Trying to keep track of what every value within the array represents is the part that causes me brain strain (since I can't assign the values names within the array, at least as far as I know). The fake array system adds to that bit of stress since I have to initialize each array before I can use it, and then I have to remember to close it whenever I no longer need it, which can have dubious results if I forget, or if I link its closure to the wrong thing. With globals, they either have a value of zero, or they have a value of something other than zero. It's pretty simple to track them.Bob the Hamster wrote:You mention wanting to do things the "right way" but that is only useful if it actually makes things easier for you. If it makes things harder for you, then it isn't the right way.
Where things get messy (and why I've been advised to switch to arrays--for good reason) is when a single item has a hundred or more possible state combinations to track. That's when globals advance past arrays in the nonsensical usage category. One of the reasons I'm trying to take the switch to arrays more seriously is because I need the game to have more organic results to player decisions without land-locking entire global variable sets to a mere possibility of use. In other words, if a single sandwich has one of 125 possible state combinations (i.e. cold, half-eaten, stale, moldy turkey sandwich with provolone cheese), then having a single global variable looking for that exact state is too much. This is where I want the array to kick in.
Fortunately, I have given this problem some thought, and I think I have a workable solution.
I think my new method will be the hybrid method, where I can use arrays to store static lookup tables (like item prices or serving quantities) but use globals to keep track of hard data (like how many of a certain item the player is carrying). Or, in the example above, "tick" the box of any state that applies to a certain chosen item. What I don't know yet is how to let the player choose an item with a specific state combination. I suppose this is where parenting a slice to a particular item and understanding how to use child slices (for states) comes into play.
At least, this hybrid method is what I'll likely do at first. As I get more comfortable with using arrays the right way, I'll likely migrate more data navigation to them until I can use them the way they were suggested to me.
I think this is actually the type of functionality that can get me in trouble. The abilities I need right now are reading, writing, and transferring data from one source to another. I can't think of any other function I would need. Where arranging and reordering would come in handy is if I implemented some kind of system that reorders items based on quantity. And, to be clear, I don't think that's a bad thing to want. Perhaps if I can get used to this system, then I might implement a feature like that. For now, I just want to get my head around using slices for flexible data storage and access properly.SwordPlay wrote:arrays aren't fundamentally different from global variables.
they can just be arranged and reordered
I've been using KyleKrack's fake arrays scripts. As I said in the previous post, I understand the basics. Where I stumble is with the tracking of values and with managing the open and closed states of the slices they belong to. This defaults to my general apprehension with using slice order scripting. Any time parent and child elements are put into play, I tend to mess things up.SwordPlay wrote:here are some tips.
- you can access and manipulate data in an array the same as a global variable. there is no real difference, but you have to write your own script to do so.
the advantages are that you can store as many variables as you like
Yep, did that already.SwordPlay wrote:- try giving your slices a lookup code. this not only identifies parts of your array, but you can look in the slice debugger to see things more easily. also you can search for a lookup code!
Yeah, so this is where things start to go belly-up for me. I completely get what you're saying. The concept is as easy as pie. The problem is in the tracking. In a small game, this might be manageable. In this game? It's like aiming for a net . . . after jumping out of a moving plane.SwordPlay wrote:- use a hierarchical structure for your slice tree. create a root node to contain all relevant slices. you might have a root node for each item, location, character etc., with many data nodes each
I've been trying to think of it like a filing cabinet. Again, I get the concept. Just having trouble with the implementation.SwordPlay wrote:- somewhat more difficult is arranging your slices. don't think of it like an array, a list of variables, think of it as a tree with branches.
there are 2 approaches I can think of
1. parent to the most relevant slice. for example, an item (slice) in an item shop (root node) can be transferred to the player (root node) when they acquire the item
2. have all your slices exist in a list, and don't reparent them. but create a child for each item (slice) that denotes the owner. and update it as needed.
And . . . this is where I lose the thread. I'm fine with top-level slices. Once we get down to the children, things go sideways.SwordPlay wrote:you can write wrappers around your array bits quite easily, to check the ownership of an item (slice), either searching it for a child slice that represents the owner, or checking who the parent it.
or something like that
All advice is helpful. Except bad advice, which this isn't. I just need to figure out an organizational system that I can manage.SwordPlay wrote:arrays aren't really different from variables, but the big thing is being able to arrange them and add bits of data to them however/wherever you like.
sorry if thats not helpful.
I'm going to try one more thing first. Since my problem is not with understanding the concept but with focusing on the organizational elements, I'm going to attempt to bridge the difference between the practical and the Entrepreneur: The Beginning way.SwordPlay wrote:i dont recommend using the fake array scripts, because they are quite limited. you are better off writing your own scripts and arranging things in a tree structure.
if you want someone to look over your work, or help write it, hmu, i am interested.
Thank you, though. I'll keep that in mind.
My scripts often melt TMC's brain. Probably best I don't post them here. :pBird wrote:Dear Pepsi Ranger, could you give some example scripts, how your code looked before and after using fake arrays? We have to learn from your case.
Place Obligatory Signature Here
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Just a quick bump. I haven't been putting much time into Entrepreneur: The Beginning this year because I've been taking advantage of being stuck at home by trying to rebuild my author brand (you can read more about that in the "I'm Writing a Book Thread") and doing all that I can to avoid having to use fake arrays, which is where I'm at in Entrepreneur development. The little bit of OHR work I am doing has been going toward rewriting my scripts for The Adventures of Powerstick Man: Extended Edition (which is what's driving the creation of all of those convenience functions I've been posting about).
But, I did want to say that, in case you haven't seen it already, there's a new game on Steam called Travellers Rest that is essentially the Early Access medieval tavern version of Entrepreneur: The Beginning. It currently has 115 reviews and a 99% rating, and is proving very well-liked by its players. For those of you who like Entrepreneur, it might be worth your time to check this game out (I plan to myself). But I also wanted to point out that there is an audience for this type of game, and it's looking pretty hungry given how quickly these reviews went up (and how positively they're turning out). Granted, I think Travellers Rest has much simpler mechanics (I actually want to play it just to see how over the mark I may be with Entrepreneur's gameplay systems), but the concept and execution is, so far, very well-received.
That said, it's also reminding me that I really need to build a Unity version of Entrepreneur on the side (while using the OHR version as the planning board), not only because I think Unity can do more of what I need the game to do (though the OHR is definitely starting to catch up), but because it would allow me to rethink how everything is laid out now that I have more systems in play than I had in mind when I first conceptualized it.
It would also give me an excuse to decide which feature creep elements I could comfortably strip away without feeling like I'm robbing the game of something special.
Anyway, that's the state of the game at the moment. Oh, and regarding some tangible news, I bought some supplemental music from Game Dev Market over the weekend. So, in addition to the current soundtrack, you may also get to hear tunes from these albums at some point:
Generation 198X
Retro VHS
Synthwave Loops Music Pack
Thanks again to everyone who supports Entrepreneur: The Beginning. Hopefully I'll be able to get the scripting madness under control soon and start getting some momentum on its development again. And I'll let you know if/when I have a Unity prototype to show. I haven't forgotten about it.
Before redoing the game in a different engine, maybe you should quickly tie up loose ends as much as possible and release a playtest version of your OHRRPGCE project and garner feedback before you spend possibly several more years continuing to work on it. Working that long on a game and not even knowing if people will like it is kind of a big risk, IMO.
But, I did want to say that, in case you haven't seen it already, there's a new game on Steam called Travellers Rest that is essentially the Early Access medieval tavern version of Entrepreneur: The Beginning. It currently has 115 reviews and a 99% rating, and is proving very well-liked by its players. For those of you who like Entrepreneur, it might be worth your time to check this game out (I plan to myself). But I also wanted to point out that there is an audience for this type of game, and it's looking pretty hungry given how quickly these reviews went up (and how positively they're turning out). Granted, I think Travellers Rest has much simpler mechanics (I actually want to play it just to see how over the mark I may be with Entrepreneur's gameplay systems), but the concept and execution is, so far, very well-received.
That said, it's also reminding me that I really need to build a Unity version of Entrepreneur on the side (while using the OHR version as the planning board), not only because I think Unity can do more of what I need the game to do (though the OHR is definitely starting to catch up), but because it would allow me to rethink how everything is laid out now that I have more systems in play than I had in mind when I first conceptualized it.
It would also give me an excuse to decide which feature creep elements I could comfortably strip away without feeling like I'm robbing the game of something special.
Anyway, that's the state of the game at the moment. Oh, and regarding some tangible news, I bought some supplemental music from Game Dev Market over the weekend. So, in addition to the current soundtrack, you may also get to hear tunes from these albums at some point:
Generation 198X
Retro VHS
Synthwave Loops Music Pack
Thanks again to everyone who supports Entrepreneur: The Beginning. Hopefully I'll be able to get the scripting madness under control soon and start getting some momentum on its development again. And I'll let you know if/when I have a Unity prototype to show. I haven't forgotten about it.
Place Obligatory Signature Here
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Okay, so I picked up a copy of Travellers Rest last night and played through its first day of gameplay. It's quite good. I put together a video of the playthrough for anyone who wants to check it out and see what makes it good. Maybe it'll give you ideas for your own game. I don't know.
BUT this thread is for Entrepreneur: The Beginning, so I've added a second half to the video where I PLAY MY OWN GAME for about 45 minutes (starting at the 26:51 mark). So, for those of you who still struggle with Entrepreneur's gameplay, this will show you how to do it better (while also offering a commentary on design choices past, present, and future). It skips the intro and tutorial, though.
Here it is if you want to check it out:
[yt]eYXKpup4NNY[/yt]
BUT this thread is for Entrepreneur: The Beginning, so I've added a second half to the video where I PLAY MY OWN GAME for about 45 minutes (starting at the 26:51 mark). So, for those of you who still struggle with Entrepreneur's gameplay, this will show you how to do it better (while also offering a commentary on design choices past, present, and future). It skips the intro and tutorial, though.
Here it is if you want to check it out:
[yt]eYXKpup4NNY[/yt]
Place Obligatory Signature Here
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1466
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Thought I'd try out some new title concepts.
Original:
New (Concept):
I'd still need to work with more than 256 colors most likely, but this is my working idea.
For now, I'm using the base image (without the titles) for the novel adaptation.
Oh, and I started writing the novel adaptation.
Edit: Actually, which do you prefer, with colors or blends?
Original:
New (Concept):
I'd still need to work with more than 256 colors most likely, but this is my working idea.
For now, I'm using the base image (without the titles) for the novel adaptation.
Oh, and I started writing the novel adaptation.
Edit: Actually, which do you prefer, with colors or blends?
Last edited by Pepsi Ranger on Tue Apr 27, 2021 12:36 am, edited 2 times in total.
Place Obligatory Signature Here