This was supposed to be submitted as a Text-Adventure FPS, but due to me not knowing what I was getting into it will remain unfinished for this LDJam. If it's possible to publish later, I certainly will but now it's just a matter of seeing how long it might take to do what I wanted to.

So this is sorta turning into a pre-postmortem for now.

There's a few points I didn't expect to be such big deals when I originally took on this idea. The first being a parser. Parsers are everywhere, used in so many things, there's countless text adventures out there with many unique approaches to this. Turns out they aren't easy to make, and I wasted a full day trying to build my own among over-engineering many other aspects of this game.

TIP 1 if Game Jams: Do the baseline. Do the most simple approach. Find the appropriate tools and libraries where you can to avoid remaking them. It's about doing it quickly, putting your idea on the screen as fast as possible.

The other point I didn't realize what I was getting into: this is supposed to be an FPS. Now, Text-Adventures are typically fully self-contained boxes/squares/grids without any form of updates until an action has been taken; everything you see is described to you in text and you have as much time as necessary to decide and react - only a max number of turns might work against you. On the other hand an FPS is constantly changing, there are recognizable 'boxes' of space, but you can move freely in them; you are not held to a grid really. The other thing is you can always see the world in front of you, with it constantly changing (while you move or other things move). You have a visual you can take in, and sound, to process things.

How do you reconcile those differences? They are complete opposites. Slow vs fast. Perceptual vs described. Reactive vs meditated. Contained vs free.

That's hard to figure out. At first I went with the idea of having a real-time world in which you use text to send commands: I ran into the problem of updating the map and player. Having it in real time, means update text of everything happening way too often. Impossible to keep up with if anything is happening or I just don't know a good way to do it without visuals or "raw data" visible (e.g. wall 2ft away, 1.9ft away, etc). This isn't GUI based though, it's a pure text-adventure format. Pretty quickly I learned there is no options other than turn-based, or like FFXIII semi-turn based. In the later case you'd be able to move once per map-tick with the same being true of opponents; if you don't know the game well or aren't a fast typist you get put at an unfair disadvantage, so that ended being kicked out as well.

Then I considered a sort of free-motion instead of predefined rooms as are typical. Being able to freely move around ran into the same issue as real-time, with the added issue of deciding how the player can move. What distance of movement counts as a turn? If you don't move the full distance is that the end of turn? Do you compensate with bonus actions per turn? How do you balance bonus actions? How are movement commands made? What do you do if the player is blocked or makes almost-valid commands (like trying to move past the corner of an object)? Making A* just so players can move in an text-adventure properly seemed silly. So 1-to-1 grids it is. Grids are easier to update the player with and the map. There's a possibility of doing grid with offset though to improve - make more interesting - the later issue of the actual FPS portion of the game.

Speaking of updating the player, meaning you. I still haven't figured out a good, clean way to implement this. The goal is to give a field of view the game knows about, takes into account anything in that field of view, then translating it into text that provides useful information. I have a fairly strong theory of how to do it. In the end it ends up being like building a mini-renderer: take in a cone of vision by the "camera", go through the list of grids obtained, filter out what would not be visible vs what would be, then describe. The describe part is rough. My basic idea here is to go through and say "You see X (distance from you, left or right)", created as a simple line from the results of each grid space. But this is a text-adventure. You don't get lines like that from any good ones because the point is to be immersive. You would expect to see something like, "Taking a solid look at the area in front of you, you appear to be in a corridor. Nothing is in front of you except for the faintly visible wall some distance away from you. The walls to your left and right have gaps at the end of them, at the wall. You hear very light footsteps coming from the gap at the left." My first finalized version of this game probably won't be that though, realistically, even if I want it to be.

It may be really obvious by this point, but this was a major learning experience. In the end I came to this LDJam with two things in mind: making a game and learning something new. I sort of accomplished the first, but I left with way more of the latter than I expected. I already enjoyed and respected text-adventures, but I had no idea how hard they could actually be to make. I've also gained quite a bit of interest in how to make a parser. Maybe I'll try to pick up the proper way to do it for this genre and do a write up. Off of my searches there's far too few actual helpful articles on how to do it, in spite of the countless sources of good ideas and theory.

I can't decide in the end whether I just wish I went with my other "Idle Platform Adventure" idea. Right now I'm just a bit burnt out.