RAPALA design blog 003 - 2023-01-12
The immediate problem that faces me now is whether or not moving off the side of the map should open up a new area. In other words, if you have designed a map, can you expand it off the four sides?
My original concept was, as well as I can remember, that the answer to this would be no, and instead each map would be self-contained and relatively large.
Should I abandon that concept? Why did I decide that?
Core to Rapala is the idea of connecting maps made between different players. If you own a map, you can choose to put a train station in and connect to other players' maps (note: nothing remotely like this is implemented yet.) They have to agree to this somehow.
Then, anyone visiting their map can in turn make it to yours, vice-versa, and so on. Hopefully this then turns into an interesting, ever-expanding game world connected through mutually-agreed-on rail lines. I'm sure there are 9,000 problems with this but it sounds good to me.
Playing the game where it is at now, though, it's hard to not want to just walk off the edge of a map and go somewhere new.
I've always liked spatially-consistent games-- this is more common today, but for instance if a house is the same inside as it is outside, or if I travel some distance in a cave and emerge at a spatially-correct location on the other side-- I find this kind of thing compelling.
I probably lean too heavily on it, but I'm thinking of Ultima VI where the cave system connects to the overworld intricately and in interesting ways. You can enter the dungeon under the castle and after a long trek emerge in a secret closet in the town's pub. For that matter, we can experience this sensation in real life. An unfamiliar place can connect to somewhere familiar, and we suddenly experience the relief of "I know where I am now."
Since I'm musing on it, Caves of Qud has a really interesting solution here, where everything is spatially consistent, including the underworld, but the overworld also has a "travel" map that is basically 3x zoomed out. So one step on the travel map moves you 3 full zones in any direction, but you always have a risk of getting lost on any one of those zones. Become unlost is a process. Anyways-- it's a great design but cannot very much inform Rapala.
Anyway, what do I really want here?
Very large maps have technical and design challenges. Rapala can support "large" maps, but "large enough to satisfy anyone's desire" is going to be hard.
Infinite maps are out of the question. This is just not something I want to do. The decision to divide the game into a fixed zones was made early on in order to simplify a lot of things. Infinite maps are the kind of thing where you really need to start there, if you think you want to go there.
Smaller, fixed-sized maps might encourage higher densityinterest, and more careful design on the part of players. If you can grow your map in any direction, there will be a tendency for people to create long walks, or to make large empty areas which may not be very interesting. This may come to dominate the game in terms of time spent.
Another tangent: I recently read a blog post on Cogmind-- a game I haven't played-- but one of the key points that he made was to try and stick to the original design intent. This is a discipline and maybe I'm simply coming up against it right now.
If I support walking off the side of maps, then in order to keep things spatially consistent, every map you can walk to needs to have the same dimension as the first zone. This may feel wierd if there are differently-sized maps, so this decision may mean that I would need to settle on a fixed map size. This is probably OK, but it also cuts down variety just a little bit. I also did always intend to support "large" maps, but if every map connected to a large map also needs to be large, this is creatively a problem as you may not want to commit in that way.
Suppose you are visiting a large urban area. It's reasonable you could take the train to a small, dusty side-stop with just a few things. This is pretty good variation. Giving the player who designs the dusty side-stop the option to do it on a smaller canvas is a good thing. If both of these can be walked off in any direction, what is the point of having them different sizes? But then there is effectively no constrained canvas.
Another point against this, is I already know I don't want to be spatially consistent. Not really. The areas will be connected between players in an abstract way, not a concrete way. So the interest gained by allowing to walk off the side of the map is not really complimented by the other, more interesting aspect of the game design.
Well, I think I probably know what I don't want.
If I allow the player to simply create a new map at any of the sides of their existing map, I get the following:
I lose a lot more, though:
So with that in mind, I'll just park it. And in fact, these days I have so little time to spend working on game development, I need to weigh the first point above very seriously. What if I spend like an entire year implementing this? What do I have?
If I want to allow maps to be expanded, I will do a lot better to stick to the original intent. It's absolutely fine for the player to create multiple maps, so expanding in a spatially-/inconsistent way is probably OK.
Maybe the real problem I need to solve, to move Rapala to become something more game-like, is: How can I move from map to map? (Right now you just select maps from a menu when you start the game.)
I'll think more on this.
It might make sense to give "arrows", i.e., specific spots where when you step off them you connect to another map. This could be used for updown as well as following a pathway. I don't think this has any of the drawbacks of the spatially-consistent approach, although it might also encourage long walks or empty, uninteresting areas.
It might give a nice intermediate way to start to think about linking areas created by different players, i.e., a midpoint step to getting to the trainrail system. Once I have the logic to move between maps via arrows, it's a more natural step to move via trains.
If I do implement arrows, maybe one limitation is that arrows can only move you to another map owned by the same player, or otherwise grouped together with the current map. Or do I want to let an arrow take you to a map owned by another player?
Another option: arrows could be updown only.
Another option: no arrows, you can only link areas by train, and you can't link two of your own areas together.
Stopping here for tonight.
I've had a few more random thoughts on what makes sense to tackle next.
If I drop spatial consistency, then using arrows can also become a narrative device. For instance, walking north along a path, I could allow for a transition screen describing what you see on that walk, which then dumps you at a new location.
Arrows also represent a commitment— so if I do them now, I always have to have them (sorta...) But I could always leave them on the table and work on other features first. This probably makes the most sense, even if I plan to do arrows, because the larger missing pieces are around interesting mechanics. For instance, there is no facility to create NPCs, no key-door logic, not very many options for creating blocksobjects yet, and so on.
Going straight for the train mechanic of being able to connect between maps is a little bit tempting because that is a more primary design idea for the game, and opens the door to testing out sharing maps across players. But I'm on the fence as to whether it makes sense to implement "arrows" first.
I should experiment a bit with larger maps than I have been doing so far.
There are some menu issues, in particular menus can't scroll.
I think the movement model should change, the idea of facing a direction first before moving in it is interesting but doesn't really belong in this game. (I think I stole this from dwarf fortress.) A button to hold that lets you change your facing direction instead of moving makes more sense.
Gamepad support needs more work to keep it up; most things still probably work but I need to refresh a bit.
NPCs could also make sense. An initial pass would probably be create a body, face, and a single bit of text they say.
Together with a "train" mechanic, I would be able to start to put together a more final menu flow. Right now you sort of create maps in a prototypey way, but if I solve some of the problems with the train mechanic then it moves to being closer to a full game.
I will definitely not do spatial consistency, but I'm not going to worry about arrows or the train mechanic just yet.
Instead, I will take the easy stuff next:
Some other niceties I may consider:
Near on the horizon but not yet
I am pretty sure I will implement arrows before the train stations, but probably after most of the above the above.
Having arrows (being able to move between map at designated points only) feels necessary to me to build small playable scenarios, but I would also like to try and discipline myself to creating playable scenarios on a single map and see how it goes.
Train stations are a core design goal from the start (arrows are not), but involve some kind of network support. I had considered the dat protocol previously but after looking at the state of the project I am left a little bit less enthusiastic about using that as a possible network layer.
The logic around the stations themselves will probably be easier once I have more mechanicsblock typesitems in place as well.
I have enough to move forward with confidence for now.