v0.1.7 - "Code Cleanup" Update
Finally, FINALLY, an update. Sadly it's all behind-the-scenes code improvements with virtually no gameplay or content changes.
WARNING: Previous save games will be wiped! From here onwards, it should stay backwards compatible... Sorry about that :(
It introduces two essential updates - old save game compatibility and being able to reset your game. Save games were critical before I could roll out future content updates. Reset will be critical for the future "prestige"-style mechanic, as seen in many clicker/idle games (though my approach will have a notable RPG twist ;).
UI and Pacing
- Intro sequence tweaked
- The max/min controls on the resources panel dont appear til a lil' bit later in the game now, likewise for the main dialogue box
- Game only saves if you've passed the intro sequence (about 1-2m of gameplay)
- Game now recognises if you come from an older version, and (should) gives you an update popup with a patch notes summary
- New versions (more) compatible with old save games!!!
- when loading new versions, game objects automatically updated, any new properties are inserted
- probably not 100% foolproof, but the game should at least now accept old saves, without automatically crashing or glitching out
- No longer have to reload the page when resetting the game!!!
- Objects and saved data is "reset" appropriately, and the start game sequence is restarted. "resetting" objects was way harder than I would have guessed. This will be critical for future updates.
- Scripted events are now contained within a single function
- technically isn't any more efficient but should make it MUCH easier to organise scripted events, plot and game progression. It also works as a catchall for unlimited customisation if ever needed.
- Upgrades are now dynamically handled (was all static HTML/hardcoded before)
- All upgrades except ore veins (for now) are handled in generic upgrade() function which handles determining whether the player can afford them, and if they can, subtracting the costs and removing the upgrade from the upgrades screen, and of course notifying them of whatever happened.
- "Effect" property: Basic effects to resources (e.g. increase the max stored or carried) is automatically handled in the function via this property
- "Unlock" property: Unlocking further upgrades (as many as wanted) is automatically handled via this property. it can also hide upgrades, if needed (maybe could be useful for creating scenarios where you have to choose one from between two upgrades?)
- Upgrades can additionally specify a "special" property, which, if exists, calls a specific function ame additionally to the generic buyUpgrade() function.
- On top of that, buyUpgrade() triggers scripted events, allowing for virtually unlimited customability if none of the above are enough.
- Locations and Dungeons objects merged into one object
- New checkskill() function
- handles checking if gathering a resource (wheat, ore, etc) trains a skill, and if it needs a min lv. requirement.
- as needed: grants a new (untrained) skill, trains an existing one, or informs player if skill lv not high enough, as needed.
- getlabel() function parses a property name and returns a plain English name (e.g. storedmax -> "maximum storage") - handy for automating displaying of notifications inside functions like buyUpgrade() or dealing with simple objects
- "Knowledge" system built in to the code. Not yet implemented into gameplay, but will be a major part of the next content update.
The Upgrades function is a huge step in making the game scalable. Displaying/hiding upgrades, checking if you can afford one, deducting the costs and removing the upgrade from the upgrade list is all automated. The special function and scripted events functions all unlimited flexibility while keeping 90% of the code automated.
It seems like there would rarely be a situation where I need to use the "special function". After all I could simply call as many specific functions as I want in the scripted events section, but its still convenient - if i really just need one extra function called, specifying it in the special function property is much faster and cleaner, saving code compared to adding in a scripted event hook.
A few minor tweaks that probably aren't noticeable, but the intro sequence flows a bit smoother now. Stopping the game from saving during the intro sequence was a tough decision. However, I think its smoother for the player to experience the intro sequence in one fluid segment. This way, even if the player closes and comes back very early on, for whatever reason (could have got interrupted) they don't end up at a weird halfway through intro, that could be jarring.
Only the base code for the resource is implemented, but in future this will be an interesting system.
You can collect "thoughts" until an "idea" forms, or, if you are lucky, an "innovation" from time to time. When an idea or innovation appears, it can be researched. Accumulate "research" until the idea or innovation is proven, which would generally lead to a new upgrade or game element opening up.
This system wont be the only way to acquire new upgrades or elements, of course. There will also be things unlocked by normal progress, of course, but I also want to have a good mix of other ways to discover and develop.
Finding good loot (e.g blueprints) can be one method that relies on luck/grinding. Reverse-engineering captured tech (X-COM style) can be another way that is based more on grinding, requiring research. Diplomacy - simply buying or sharing knowledge with NPCs or other towns would be another way, using resources like gold and wealth. In the end, hopefully there will be various gameplay styles open to the player - if you like the more idle approach you can set a bunch of workers to generate ideas, if you like a more hands on approach, you can explore dungeons, grind monsters and challenge rare monsters. If you prefer the management approach, get rich on trade or the currency market and engage in diplomacy.
The code changes here were pretty drastic. Large chunks of obsolete code were commented out, it remains to be seen if any thing will break the game. Any fixes will be hotfixes (0.1.7a, 0.1.7b, etc),
The next main update, 0.1.8 will be the "final" update of this branch, with more code clean up, and fleshing out the idle/clicker aspects, such as hiring and managing workers, workers gain skills, crafting tools to improve their performance, etc.
After that, we move to 0.2, hopefully, which is planned to be the first "public" release!
Leave a comment
Log in with itch.io to leave a comment.