I made a horrible mistake with my first game

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:

  1. A text adventure game is impossible to make with a small scope
  2. My from-scratch engine wasn’t really designed with modifying the game data mid-development in mind
  3. I have no clue what I’m doing.

I just don’t know what to do now. Any ideas? @gamedev

  • planish@sh.itjust.worksEnglish
    2·
    1 year ago

    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.