RAPALA design blog 004 - 2023-02-13

Taking the time to periodically reason about next steps will become a central part of my work process. The reasoning in the RAPALA 003 blog has saved me a lot of time, and in the last month I have seen a lot of improvements with little or no wasted effort.

Part of the discipline for me here will mean reading my last dev blog before starting a new one, which I've just done.

Last time, I came to the conclusion that I probably wanted arrows, which would be designated points on a map that you could step on to (somehow) travel to another map. A staircase might link to a basement or attic, and a hallway might link to another hallway semi-seamlessly.

I didn't tackle that last cycle because there were too many other, simpler, more definite problems-- like the inability to scroll menus. As I said above, overall these priorities felt correct and I'm very happy to be here after just a month hacking on this a bit each night.

Do I do arrows now? Or wait?

The other thing I considered last was the tradeoff between tackling the "train" mechanic, i.e., the ability to link worlds created by different players. The more I think about this, the more it feels to early to worry about. There just aren't enough tools to create a compelling map, yet.

I could try and add a bunch of block types, items, material, and so on, which would create a much bigger toolkit and probably make some interesting-to-look-at places possible. I'm not sure the best process if I went this way— should I just list things randomly, let myself semi-unconciously copy things that are in other games? On that last point, I've already started down this path by implementing keys/doors, but actually I feel good about this, as the specifics in how it works is genuinely new. But I'm not sure I want to proceed on that for too long.

One problem I have encounted with Paradise Never is that it's ultimately hard to add details without a larger unifying vision, even if the intent is that the details sit loosely and in the foreground, and that the unifying vision is not necessarily important. Paradise Never, for instance, has a bunch of objects with interesting functions, and a bunch of NPCs with interesting dialogue, but I'm currently struggling there to tie them together in compelling ways. (Part of my reasoning for pivoting here, but...)

So the approach I have taken in Paradise Never is the same one I think I will probably take now, here, which is to start to focus on a unified, straightforward game design that will pull the player along. This design should never be the point-- the true reward was the fun we had along the way, kind of thing. Or in other words, sure, make a game about rescuing a princess (but actually, please no, it's a harmful, sexist, stupid trope-- just drop it) but make sure you don't care about that-- the game doesn't live there, it's in the minute to minute actions.

(Digression: I think you should actually put a bit of effort into the over-arching structure or motivation. It's not the point, but it doesn't have to be terrible. I absolutely loathe how Nintendo approaches this, drawing everything in the broadest possible, stupidest strokes, in all situations, no exceptions that I am aware, but anyways, I really don't want to be negative and I am greatly enjoying BotW right now...)

Where was I. Right-- so the thing is that designing the small-scale stuff, which is what actually matters, is ultimately just easier creatively when you have a large scale structure to drive your design. So even though, in Paradise Never, I want the main point to be the general feeling of looseness, NPCs sort of just living their live, the absence of any major crises, I cannot really design a game that way. I need to create a basic plot or sequence of things that everything else can fit around, if only because I tend to come up dry for ideas otherwise.

So in Rapala, my best idea right now is to lay out a simple quest or story and implement it-- this, even though the game is intended to be an open-ended, intricate, interconnected, directionless city, without a set story or objective.

The question do I need to commit to arrows?, is a lot easier to answer in this context. If I sit down and try to design a short game, it's very, very hard to do without creating separate areas you can travel between.

You might think, "there are lots of one-screen games", but this is only sort-of true.

Some games are one-screen, but have changes happening on that screen. That doesn't really match how Rapala works— there aren't waves of enemies, or other things that would come in and out of the map. The core design intent is a more static map, the thing moving being you, as you poke around and investigate. (Examples of what I'm thinking of: space invaders/galaga, original mario bros., the non-super one, and now that I think of it Tetris, other puzzle games, I guess... all depend on things moving and changing on that screen...)

Other games are one-screen at a time, for instance Lolo. You have to solve each room in order, you don't travel between them. But there is a progression from screen to screen as the game progresses. (Zelda I is not "one screen at a time", in this sense— you move freely around, the separation into discrete screens is important but just not what I mean here...)

For that matter, relatively few stories are set in one location only. That said, there are surely some quality examples, and it might be useful to mine them for ideas of how to handle this problem in games.

Anyways, all this is just to say:

- I know I don't want to use spatially consistent maps (I agree with my reasoning in RAPALA 003)
- I know I want gameplay to be about moving around spaces
- I know I want to tell stories
- I know I want to give the player/creator flexibility in how big the canvas should be
- I know I don't want to burden the player/creator with filling in every detail to start (I haven't talked about this, but this is one complexity with spatially-consistent maps— you can't cheat, you have to show what is everywhere, somehow...)

And last, skipping ahead a bit, I have sketched out a possible first game structure, and it requires moving between maps. So my initial idea, at least, certainly naturally oriented itself around creating areas you could move between. I.e.:

- I know the one idea I have had so far, I want something like arrows, at least...

So, I am pretty certain I want this.

There are some elegant things I can do.

Since the map is fixed-size, I can draw the boundary in some unambiguous way. Think: some kind of border around the map's space. But if I have an-edge-of-map arrow, I can just extend that past the edge. This makes it immediately obvious where you can travel off the side of the map, and where you can't. It also makes this seamless— you always know that stepping on that tile (in an otherwise illegal, off-map space) will take you to another area. The visual cue is always consistent and you'll never create a situation where people are wasting time "bumping" off the side to see if there is maybe a way to walk down the given path.

For other arrows, for instance stairs, I'll have to figure out what kind of visual language I want to use. This case is (probably) different than edge-of-map, design wise. Designing a map, it's optional if you want to draw walls around it. This is a good thing narratively— what if you are at a meadow in the middle of a forest? A gas station along the highway in the middle of the desert? Maybe we can draw walls with trees in the first place, but it feels unnatural. Certainly it's annoying to imagine every map needing to be concretely ringed-in by something solid. Frankly, a lot of games do do this, which is, in fact, always unnatural and awkward. Maybe part of the reason what spatially-consistent maps feel so better by comparison— no (or fewer) artificial or invisible walls, only (or mainly) natural ones like steep cliff faces, chasms, and so on...

So yes, the case of stairs, teleporters, or whatever other thing that might be present somehwere inside a map is different than edges, because we want to allow the player (as author) to create maps that are open everywhere on the edge. So the player (as visitor) will not know where they can walk off the edge, unless we create a simple and consisten visual language.

But I think there is a strong case to allow hidden passages that aren't immediately obvious inside a map. The mechanic of exploring this space and poking around is already the main design idea. It might be tedious to check every box to see if there is hidden staircase underneath it, but this is just inherent in the original design— there's going to be many possibilities, and exploring them intelligently (rather than by brute force) is sort of the point.

So, perhaps, I can use an icon of some kind to show a map transition— I'm thinking of just copying what Final Fantasy 7 did, which is have a white arrow of some kind— but the white arrow or whatever doesn't necessarily have to appear. So once uncovered, or if it was never intended to be hidden, it is still very clear where the map transitions lie, but unlike edge-of-map transitions, they needn't be visible to start with.

Pausing for a moment here. I'm pretty sure I like this design, but I'll sleep on it.

First, I don't think it's important to allow interior arrows to be hidden at this point. It might be an interesting mechanic, but the potential to just use interior arrows for edge-of-map transitions is ugly to me. I really want to make sure the player (as visitor) can trust what is or isn't at the edge of a map.

I can always make them hide-able in the future; so the easiest thing to do is, for now, to just ensure any transition on a map is always evident and unambiguous to the player.

Tangent: I might start to use "visitor" and "author" in place of "player" in my reasoning. This is interesting too-- do we need to use the catch-all "player" or (worse) "user"? It's after all only a short jump from there to "consumer"... of our "title"... kill me now. (Don't actually.) Videogames are a communicative medium, as a designer you don't have to commodify the other party to your communication, you can respect them more than that. I'll stop.

Not-really-a-tangent: I should spell out the role "visitor" and "author" have, because there is a related problem.

When you create an area, you are the author. Right now, I'm considering that there will only be a single author for a given area. So if you aren't the author, you are a visitor, and you lack edit controls. Each visitor has their own instance of each area, so if you drop an item, it doesn't appear for everyone else who enters that area.

For the future, I can envision some kind(s) of shared control, even for example transferring permanent control of parts of a map: person X is author of map A, but building B in map A is authored by person Y... person X gave control (permanently) to person Y of building B. It's interesting... but does this just mimick slice-and-dice land-ownership and colonial capitalism? Does it only seem exciting because we'd love to own and exercise control over some domain in real life? Authoring anything is a kind of power, sure, but it's not necessarily a power fantasy— you write a story not necessarily because you want to describe how you wish your real life experience is, you could have a lot of different reasons. However, ownership of objects or land in videogames does strike me as a kind of capitalist power fantasy— says the videogame user-consumer: "I would like to have a huge castle of my very own and get to decide what happens in it, who enters, perhaps even what happens to those who enter, and in it I shall reside." So much the better if this unreal estate exists in a shared world, where there is some scarcity, so others can bear witness to what I have/control, and be impressed by me. "Worship me," says the videogame user-consumer, "and for that, or the promise thereof, will I shork over twenty thousand U.S. dollars in exchange for a Very Great and Impressive Star Ship." I'll stop, but maybe I should save myself the trouble of shared ownership...

So then what do I want for author and visitor? Author should be able to communicate ideas to visitors. At least this is how I see game design, it's a conversation where I am laying friendly traps for visitor to walk into and feel some enjoyment.

Author should be able to experiment-- "can I make this?" "what happens if I that?"

Visitor should feel a sense of curiosity, a desire to feel and to find out whatever Author had in mind for them. Visitor should feel a sense of being lost at times, or at least, being inside something large and not-fully-known. So, a sense of mystery and discovery.

I had good success with the door mechanics, by making at least part of the process of configuring the lock/key mechanism simply an in-game mechanic. The edit controls, which only Author will have, are the super-powers. But the world can be malleable, both for Author as well as Visitor, when they enter.

Activities like configuring puzzles, hiding objects inside other objects, arranging things in specific ways-- these can be done by Author but don't really require Author powers. Edit mode is really the majority of Author powers-- Visitor can't creat things out of thin air, reconfigure blocks and so on.

This approach will probably prove itself out. Rather than create a special editor for every little thing (e.g., a special edit-mode menu for keying a door), figure out if an approach is possible that is Visitor-only. If that works, then we have something interesting for both Author and Visitor, we encourage creativity for both, and I also probably reduce my workload. It solves multiple problems at once so it is good. (And if it doesn't solve multiple problems at once, well, it might not be good...)

Is the same possible for arrows (map transition spots)?

Hmn. I don't think so.

As Visitor, the layout of individual maps is currently firmly in control of Author. I'm not saying you won't be able to destroy walls, but the mechanics for creating walls are all in edit mode and it feels right there. Similarly, then, the way maps connect need to also be in control of Author. It doesn't make much sense to be unable to change how a map is laid out, but then to be able to change how it connects to other maps-- the two things are too dependent on each other, too closely related.

It's simple enough to grant Author the power to place arrows-- they are just a special type of object. But how do we control where they link to?

Some obvious problems:

- How do we group maps together? Do I need a new abstraction "area" which just is a collection of maps which can be connected? (First thought: yes, probably this is it...)
- How do I define which map an arrow takes you to? How do I define where on that map you end up?
- I would like to add a completely new, narrative-only map; how do I link to those? (More on what this is in a future post...)
- Does adding an arrow automatically add a reciprocal arrow? If not, how do I avoid keeping two arrows in sync? Do I need reciprocal (e.g., doors) as well as one-way arrows (e.g., for falling down a pit?)
- For reciprocal arrows, how do I manage deleting/adding so that they always stay in sync?
- What happens if things move around, but an arrow drops Author onto an illegal position on the map?
- What should the visual language actually be? An arrow?

Not related to arrows, but another problem relating to Author/Visitor dichotomy will be, as Author, deciding what a "revision" or "commit" (to borrow words) is and how to make it. Since a big part of the creative process of making an area will simply be walking around, arranging things, and setting things up, we need a way to make a cut and freeze it in a state that can then be instanced by Visitor.

Fortunately, for this problem at least, I don't need a full solution at this point. My goal right now is just to implement one such story/area myself, not support the Author in creating and sharing them. So whatever I figure out here will probably morph in this direction.

All this considered, what I think I need next:

- An abstraction, area, which is a collection of maps.
- In the future, areas can hold narrative-only maps.
- Reciprocal, interior arrows, which can be anywhere and are used for e.g., stairs, warp plates, whatever.
- Edge-of-map arrows, which are a kind of reciprocal arrows.
- Some way to create a new area.
- Some way to select/review maps within an area, for instance when creating or defining arrows.
- Some way to manage reciprocal arrows and keep them in sync; this might be managed at the area, not map, level.
- Some way to create an instance of an area, versus just an instance of a single map. I only need a partial solution here.

This is more than enough for me to move ahead, and I don't think I'm making any obvious bad movies, so I will start.

Deciding on which terminology to adopt.

Zone
- Feels more technical, specific
- Evokes other good, fun, videogames (Sonic)

Area
- More generic, ambiguous
- More likely to be used conversationally
- Less rigid-feeling

As a mental exercise, I felt initially that these put "zone" firmly into the lead, but my objectives are a more natural storytelling. Evoking other videogames doesn't really net me anything other than style, however using a word that is common conversationally means discussions around the game can maybe flow more naturally. "What area are you in" is something you would ask another person. "What is your zone" would always have to be related back to something specific.

Area it is.

However... after starting to implement this, I am having some second thoughts— do I really want to add this layer of organization? Without re-reading my rationale, I think I really do. Ultimately, the solution here is in opposition to either having huge maps (which add a large design burden on Author) or having spatial consistency between maps (already know I do not want.) A loose collection of maps without a concept of area to group them might be interesting, but makes questions around reciprocal links, commits/revisions, and others harder. I think it's also harder for Author, because it's not as easy to organize their maps. So ultimately areas are solving a creative problem (reduce the design burden by letting Author grow an idea outwardly bit by bit, without having to "fill in" every gap which very-large-maps would sort of require) as well as technical ones (give us a large unit of consistency.) So I think it's probably worth it.

Another point in favour is just that looking at the code today, the map catalog is not very fleshed out. However, it's starting to seem even after a few minutes like organizing maps into areas will fit relatively naturally.

Continuing on this path for now.

◀ Back