GameDev

1. Isn't true. You can make a short, linear(ish) game. Game dev is hard work and takes a lot of time and planning though.
2. You might need to make changes to your engine in that case. It sucks, but you won't make that mistake again.
3. No one really does. Keep making mistakes and eventually you won't make as many big ones.

@ch0ccyra1n @gamedev are you considering switching to using a game engine? Or are you more trying to figure out how to proceed with development of your own implementation?

If you’re developing a text adventure and you feel stuck, the library of ZIL (Zork Implementation Language) games here might be a good place to find inspiration: https://github.com/historicalsource

I don't see a way out of this other than refactoring until #2 isn't true.

#1 isn't really problem; a text adventure needs a lot of written text, but you can keep the actual programming limited in scope and just sit down and write the text. Think of simple Twine games where all you can do is move from page to page but it's still a full game because there's a book or a short story's worth of text in there. Compare the text adventures that limit their parsers to two-word commands like talk guard, versus the ones that expand in scope to make sense of ask guard about bell, book, and candle. One is way easier to code than the other.

This ties back into how you absolutely need to fix #2. You can get away with not using something like Inform or Twine or TADS to make a text adventure, but then you really do need your own data-driven engine to do what those systems give you for free in terms of simulating an object physics and a room map and the connections between them. You do not want a bunch of switch(room_number); you want structs or on-disk files or macros that let you define the rooms and objects and so on in one place, and then you want a bunch of code for parsing commands and interacting with the room and object databases in a different place. Even if you don't want to write a Z machine game, learn about how the Z machine or other similar systems work under the hood, how they model game worlds, and generally why they chose their solutions to the design problems you are also going to face.

#3 is the underlying cause of #2 and will resolve on its own. There really is nothing that helps you develop a good design sense like the fear that comes with having had several prior projects collapse when you lost the ability to keep track of everything you put in them.

Hey, I'd advise you to try and do a very small project on a dedicated game engine, so you can get an idea of how they structure the data and why. In my case, I had a traditional education in programming, and when I first used Unity, it was really hard to understand the logic behind game objects and why they did it that way. Once it clicked though, it made sense, and if I had to do a custom game engine today I know I'd take inspiration from it. Could help you unlock your situation. In any case, don't despair, as you had a great learning experience! People's first game rarely get completed.

Other people have already suggested starting with an engine, I'd like to go a bit further and suggest you start with Raylib. It's an open source game engine that fits into a single header file, written in C.

I think it would allow you to build a couple of small games, while inspecting engine internals in your favorite editor at the same time to learn the ropes.

Wish you the best