Or more to the point, is it overly complicated? IF creating software like Quest and Adrift, have extra features such as hit points, weight, maybe a clock cycle, etc. It seems like a simple click on the check box and it’s added. Of course you’d have to put weight for each item, if “weight” was the option you added later.
But is it really that simple? The system just snuggly fits in the new parameters or you have to delve into and correct coding or do other more complicated things, if you had not chosen those options in the first place? Thank you.
It really depends on which system you’re using and what you’re implementing. If you have a specific system in mind, you can get more specific answers. If you’re planning on picking a system based on its ability to add features later, knowing what you’re planning on implementing would also be helpful in suggesting a system.
It will always be more work to implement an integral system later on than at the beginning. Simple systems are a lot…simpler and can probably be implemented whenever in the development process. But again, it’s really a case-by-case basis.
I think it helps to sit down and plan out your game. If you know you are going to have certain elements, you should plan for them and even if you don’t implement them till later, you code in a way that allows for their addition. For example, if you want a dialogue tree that changes depending on what the player has done, has in their inventory, etc. Then design your dialogue structure to be able to take in the game state and history and also design your game around keeping track of said state and history.
But is it really that simple?
Sometimes, but it is often not easy. Sometimes you will have to refactor large swathes of code when you encounter something you didn’t expect. But that’s why concepts like encapsulation, design patterns, SOLID principles, etc. exist so that it helps you to write modifiable and maintainable code.
It’s generally easier to add any feature earlier than later. If you have to add a feature later, you have to get through more code to implement it (unless it’s a built-in feature) and you’ll certainly have to do more testing to check for edge cases.
The price is time and effort, however, so it’s perfectly possible if you are OK with the payoff.
It is always easier to scope your project in advance - figure out all the systems and features and how they will interact before coding them in the game. I also recommend if you have a lot of systems to make simplified mini prototypes to test and clash them together and work out bugs in obvious fashion before incorporating them into a more complicated game where it may be more difficult to realize what’s going on when problems occur.
If you think about it like building a house, you want to know where all your electrical outlets and plumbing should be in advance so you can install the wiring and the pipes and faucet outlets before the walls go up. It’s much more difficult to then add ethernet wiring after drywall is up and painted.
Occasionally you’ll have a good retrofit, but there will always be something you didn’t account for that hopefully your beta testers will find “the time travel system you incorporated now makes it possible to solve the last Uber-puzzle and win the game just by flushing the toilet instead of going on the three-part quest sequence it originally required…”
I broke Fair two days before the IFComp deadline. I was almost done but got all “sure I can throw in a Time Machine; it’ll take an afternoon maybe lol”
highly scheduled narrative suddenly becomes a singularity with everything trying to happen at the same time
I start before actually coding. When I have an idea, my first question is “what language and/or libraries is the best for implementing this” (and this in all my coding, not only IF related…) and I have in past posted my broad cataloging of IF languages/libraries stemming from this type of analysis.
Then, I implement the general layout, map first, then items, eventual NPC, and lastly the puzzles, then throw the alpha to hapless ßtesters, which endure the inescapable bad english, hopefully doing also a good proofreading in parallel… rinse and repeat with the ßeta, then with the RC (Release Candidate)…