So for context: I'm a programmer and I like the idea of not using a game engine, but I have no real prior experience with game development specifically.
I thought it was a good idea to make a text adventure game (think Zork) in C, since the language offers great portability, including the ability to run code on the 6502. Also a text adventure game made sense because I can't make art and idk anyone else who wanted to work on a game with me.
This was a terrible idea for a few reasons:
A text adventure game is impossible to make with a small scope
My from-scratch engine wasn't really designed with modifying the game data mid-development in mind
I have no clue what I'm doing.
I just don't know what to do now. Any ideas? @gamedev
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.
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.
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.
Add comment