This is not an intro
Hello all, and welcome to my devlog. This first post is not an introduction to this project, but is rather an execise in collecting my thoughts about a problem I was working throught yesterday. Let’s say it’s in media res.
I will post something that is more of a "premiere" later this month, in which I will explain more about the engine I am using, what a "cell" means in the context I use it here, etc.
Circle back to this space around the New Year, and please feel encouraged to heckle me in the comments if you don’t see anything by then :)
It’s getting crowded in here...
I always knew that the 4mb constraint was just that, a constraint. What I didn’t realize is how tight that constraint would feel, and how soon!
Through some…
This is not an intro
Hello all, and welcome to my devlog. This first post is not an introduction to this project, but is rather an execise in collecting my thoughts about a problem I was working throught yesterday. Let’s say it’s in media res.
I will post something that is more of a "premiere" later this month, in which I will explain more about the engine I am using, what a "cell" means in the context I use it here, etc.
Circle back to this space around the New Year, and please feel encouraged to heckle me in the comments if you don’t see anything by then :)
It’s getting crowded in here...
I always knew that the 4mb constraint was just that, a constraint. What I didn’t realize is how tight that constraint would feel, and how soon!
Through some testing today and some number-crunching, I have come to realize that my budget for images is going to be around 250. This presents a problem, because my current way of handling cells is for each cell to be associated with 2 or more images.
To demonstrate, let’s say that the player is encountering a Boglin on cell L2-C03. That cell would need:
-
One forward-facing image with the Boglin present
-
One backward-facing image with the Boglin present (unless it truly was impossible to get to that cell before defeating the Boglin)
-
One forward-facing image without the Boglin (after it was slayed)
-
One backward-facing image without the Boglin
And that’s not including if that cell is later occupied by an NPC or other interactable! Or the fact that, in an ideal world, the player would be able to see the Boglin in that Cell from some distance away. You can see how this would eat up my budget quickly! A maximalist version of this game with this current structure would allow for roughly 20 encounters... And that does not a deep experience make! (The quick math on this by the way is forward and back, monster and no monster, and cell before and after; 250/8.)

Decision Time
Limitation breeds creativity of course, but these limitations are starting to feel less like opportunities for problem solving and more like obstacles to a polished and performant gaming experience.
It’s time to make some choices–here’s what I’m working with:
1. Do cells need a "forward" and a "backward" facing version?
2. Do cells with encounters need a "cleared" and a "not cleared" version?
3. Do the cells immediately before and after an encounter cell need to "foreshadow" and upcoming encounter?
4. Do "foreshadow" images need to be unique, or could there be a generic "shadowy figure" image?

I’ll start with #1. I just don’t think this game would be taken seriously if you didn’t have the option to turn 180° while in the dungeon. I could be wrong about this, but I think that would make this project harken back to a pre-Genesis mode of dungeon crawler and, on top of the association, could actually just be difficult for modern gamers to stomach. So right off the bat, my image budget is now somewhere in the ballpark of **120**.
Now #2. This also feels extremely important, I mean players gotta see what they’ve got coming up and then see that they don’t need to worry about it anymore right? I have toyed with the idea of having a generic encounter background, upon which all encounters take place. This might save me less than half of what the encounters take from the budget (it’s not *that* different from having a "cleared" and "not cleared" version of each cell). Ultimately, I am going to go with both "cleared" and "not cleared" versions of each cell, but I am going to get *creative* with my "cleared" cells (after all, they double as blank hallway cells, which can be reused elsewhere in the dungeon).
#3 & #4 While I think that the "best", or rather the most visually impressive version of this game would have this "foreshadowing", it also feels, in a strict sense, less necessary than the dimensionality offered by the ability to turn around (#1) as well as the visual reminder that you have "cleared" a task. We gotta make cuts somewhere, so here it shall be!
Perhaps I can accomplish my goal of foreshadowing using text instead? For example, let’s say the player is two cells away from a Boglin encounter. When they move to the cell one cell away, they could get a prompt that says "You sense a nearby presence in the dark." Not as elegant as the image, not as visually appealing, but it gets the job done.

As a final note to end on, I think that this game can surely be what I want it to be with this budget. I intend the dungeon to be a space the player explores multiple times, with each character revealing different secrets of the same space (more on that in the upcoming primere). This budget is going to force me to keep things small, and small is good if I want my players to really learn a space :)