If the options screen is becoming bloated and hard to navigate, perhaps it would be nice if I added a search function to that as well.
I mean, this is getting silly, but having the ability to search for whatever you want in any part of the interface has a value. I’ve written three different search guis in the last month for the game.
The time that you spend in the game looking for what you want is inherently wasted, so therefore the search has to be a good thing. I don’t mean searching for as in the exploration aspect, as that’s among the best parts, but futzing around on the GUI looking for the right button or finding one item or one type of item in a stack of forty thousand items.
This goes for the vehicle gui too, looking for a specific engine, I couldn’t be arsed to search for the specific part that you want.
I also fixed the recipe search so that you can search by name, skill used, component required, quality provided, quality required. This reduced your time that you required to find what you know exists, but would otherwise need time to search for.
Can any of you really justify calling this “Bloat”?
Bloat is a word that’s thrown around a lot. It’s not about the complexity of the game, which tends upwards, but about the amount of bullshit that’s required to do something.
Does it take thirty seconds to find the recipe, item, or part that you want to interact with? That’s bloat.
Bloat is a more “Serious” adjective to use to describe bad game features.
Bloat in the context of most software refers to the weight of the software, the amount of resources that are required for it to function. The game is bloated, it is a very heavy game if you build it with lua support and tiles.
The text version is faster to load, lighter on your resources, which would be enough if it was 2002 and you have around five hundred megs of ram.
The text version is less responsive, less pretty, even if you “like” the text. It provides superior hints for gameplay purposes. Playing with the chesthole tileset, you can see if your character has armor equipped and even some of the mutations show up on it. Is that bloat?
No, because those visual cues are helpful if you like them. They reveal state that has relevance to the game that would require going through a bunch of screens to make sure that you have all your armor equipped for your street samurai approach to taking down zombies.
It helps you see if your character has picked up a new mutation in the process of screwing about in the hazardous waste sites.
This makes the game heavier and slower to load, but if you don’t like having to go through a bunch of screens to check the state that exists in the game, then it is no doubt valuable.
This game is not a unix tool, it is not single purpose, it has no real “utility”, and its complexity makes it more fulfilling when you come about to understanding it.
I try to take time when writing code for the game to ensure that it doesn’t slow the game down during the game play, as slowing down the flow of gameplay would reduce the value of the gameplay.
The code I’ve written probably increases the size of the game in memory by around 500 kb if you have an immense number of items around you.
These features are not bloat in any reasonable scenario, hell you ought to be able to run it on a raspberry pi, so long as none of the libraries it uses have some mysterious dependency issue on ARM.
What’s more, the code that made clothing filthy probably took around 30 lines of code. This is a drop in the ocean.
It’s not bloat. It is at worst a bad game feature. Hell I don’t even disagree with it, it’s just another reason that I view the zombies as a source of easy cloth material rather than a clothing store.
Calling features bloat isn’t right. Features can be implemented in a bloated way, but in general a good (technical) implementation should be able to avoid most of that.