+CONTROLS+ Currently using ESDF keys because my A key chooses not to work occasionally. Left click to hit/interact with menu buttons Scroll wheel to cycle through inventory [Works best in fullscreen] +FEATURES+ Completely overhauled, actually decent now. A couple different things nearby for resources and crafting. Some borders, different biome areas. A mini-map. A bunny that is somewhat hostile, or he really likes you. Press J to open the command menu. Some dysfunctional buttons, some that kind of work. Simple day, night cycle. Statbars. Inventory system with some tools, a sword, a certain secretary dog's broom, and a certain crazy jester's scythe. You are playing as the previously mentioned best character in all of reality.
THIS PROJECT IS IN DEVELOPMENT Starve.io | vDev 1.0 "Complete Rework Update" Changed many things and made them actually good. ------------------------------------------------------------------------- +MAIN GOAL+ Replicate most of Starve.io and create a single player version that is faithful to the actual game. +Current Goals to Launch Version+ Create forest map. Add wolves, spiders. Add crafting system. [ Kind of done, need to finish adding items ] In order to have objects like campfires and plants, which have timers that run even when offscreen and unloaded, I will need to loop through the PLACEDOBJECTS part of the list MAPDATA. The biggest issue with this being that in my current system, all placed objects have only one extra point of data that distinguishes them from normal objects. My plan was to put all of the data into that one line, (objectLifeTimer, for objects like campfires, itemData and itemCount for objects like chests and windmills, etc.) This means that I would need to loop through all placed objects every game tick, parse them to determine which parts I would need to change, and then make them act accordingly. While I believe this is possible, I don't think it is the most efficient way of going about things. Another approach would be to not have placed objects unload, only natural objects. Placed objects would be able to operate offscreen with little to no issue. The problem with this approach is that it severely limits the clone count, and it could potentially break the game if I don't limit the amount of objects the player can place. The third, and potentially best, option would be to create a separate list called PLACEDOBJECTDATA, which would contain all of the data for each placed object. When the player places the object, it would get it's own index, contained in the extra piece of data in MAPDATA, that would point to its data in PLACEDOBJECTDATA. PLACEDOBJECTDATA could store timers, itemdata, even the last time you interacted with them. While this uses an extra list, it would be far more efficient to edit object data. Branching from this, it may be possible to just store the last time an object was loaded so that when it loads in the future, it acts based on the time elapsed. For example, a campfire that was alive when it unloaded will store a time. A while later, when the player revisits that area the fire will load in, it will realize that it has been a while since it was last loaded, and realize that the fire should be out now.
