Dungeon 137
With a handle on pre-planned dungeon layouts, we need to decide what to do next. Have we squeezed all the juice out of this program yet? No real code today, just one little experiment.
Yesterday’s spike on pre-planned dungeons told the dev team (me) that we can do any of the things the design team (me) have vaguely asked for in the area of special dungeon layouts. We would have to code them up, but we haven’t heard any layout ideas that we couldn’t develop readily.
There are, however, many capabilities that are not yet programmed. Let’s consider a few:
- Interactive Objects
- Puzzles might include the player interacting with objects in the dungeon. We have some tiles that look like they are weight-sensitive, with a down state and an up state. We could use those for simple door openers, for springing traps, or, in combination, as some kind of puzzle. We have some sprites that look like switches, that can take on multiple positions. We haven’t used any of these. In a “real” game we might have many such tiles and sprites, used in various and nefarious ways. Perhaps we should do one as a proof of concept.
- Doors
- We have no doors, gates, or other obstacles to travel. These might require a key, or the solution of a puzzle. There are some issues with respect to doors, based on the random layout of the dungeon: we don’t really know where the doors would go, because we don’t really know where the tiles are. Of course, in a pre-planned dungeon, placement would be easier. We do think we know how to resolve the door issue in a random dugeon as well.
- Mazes
- It might be “fun” to have a maze level. We could fairly readily produce a pre-planned one. Algorithms to create mazes are readily available. There would be learning but we’re not concerned that it would be difficult. We now know that we can plug in any specialized kind of dungeon layout easily.
- Magic and Action at a Distance
- All our items except for one just add to the player’s attributes. The exception goes into inventory and when you touch it, it releases the WayDown pathfinder. Since we are trying to avoid combat as much as possible, in the aid of inter-universal peace, it would be good to have monster-repelling stink bombs or items that would release ghosts to move on to paradise, or whatever. I don’t see any major issues with such items. We have the ability to find the monsters within range, so an event that affects all nearby monsters would be pretty straightforward.
- Dungeon Definition Language
- In a real product, we’d be imagining many levels, many sprites, many treasures, magical items, switches, dials, traps, and so on. We would have a staff of artists and level designers who’d be figuring out exciting levels. In the present situation, each such idea requires us to do some programming. In a real product, we’d like the development team (me) to be providing individual capabilities in code, and to provide some tools to the designers to assemble interesting levels by drawing maps and assembling sprites and items, associating them with capabilities. We’d want to provide a “dungeon definition language”, some way of defining a level.
-
I have some general thoughts on how one does such a thing. The trick is to do it incrementally, rather than spend weeks and months defining a language and working out a “compiler” for it. Instead, we’d want to put it into the hands of our developers as soon as possible, so that they could begin to pick up some of the workload, and so that we could learn what to give them next.
-
You can think of this as “developer defense”, and it’s a very positive thing. We all want to develop the system as fast as possible, and if all the design and product ideas come down to one programmer who chops up spritesheets and implements magical items and associates pictures and and and, we have a major bottleneck, and an unhappy programmer. So we all want repetitive tasks to be automated where possible, and handed off to other team members where possible.
Hm. I fear that I’ve convinced myself that what we have to do next is to start building up a dungeon creation toolset of some kind. One early task will be to give it a name. That will be difficult but other aspects will be
Hm again. GeePaw Hill has begun talking and writing about the “shipping app” and the “making app”. The shipping one is the product, the game in our case. The making one would be our dungeon definition toolset things. If it were to be a legitimate “app”, it would all need to be neatly packaged, but I think it’s a natural evolution from a collection of tools to a more integrated app-like thing. It’s an interesting parallel. If and when we go forward with some tools, let’s keep the idea in mind.
Codea/Lua, being a little language on the iPad, is limited both by Apple’s rules and by the limitations of the iPad itself. One Codea project can’t access the files of another. There’s one shared folder, shared among all your projects. There is a dependency feature, such that tabs of one project can be referenced by another project, as if they were present there. A Codea project can read or write an entire project tab from any other Codea project. There isn’t much more than that.
We can imagine “tricks”. Suppose we have artists producing spritesheets, monsters or treasures or something. We could have conventions, such as “store them in the Dropbox.asets shared folder, with names beginning with D2, and then the asset name, and put in an associated text file with the same name with “_txt” appended, which we’ll use to split up the spritesheet and copy it into the game.
Yucch. Doable but not incredibly fun. Still, once done, most of the work could be handled by little apps in Codea. We could even let them move photoshop files in, or let them edit their files on their office computer, so long as the files turn up where we can find them when we build the app.
If we wanted to get really fancy, Codea can do http type things, so we could, in principle, fetch items from a web server somewhere. I’d think, however, that keeping things in shared (real) Dropbox folders and moving them into the range of what Codea can access would be just fine.
Blue Sky
I’ve done a little reading. Codea has a thing called “Global Data”. That is, in essence, a keyed table of values. You can ask Global Data for a list of all known keys, and you can read or write any key. You can save any string or number.
And Codea can do JSON encode and decode, of strings, numbers, booleans, nils, and any object that implements its own __tojson
function. (It’ll be up to you to decode whatever that does.)
This test runs:
function testGlobalData()
CodeaUnit.detailed = true
_:describe("Global Data", function()
_:before(function()
local t = {a=5, b={10,20}, c="hello" }
local s = json.encode(t)
saveGlobalData("table_t", s)
end)
_:test("read global table", function()
local s = readGlobalData("table_t")
local t = json.decode(s)
_:expect(t.a).is(5)
_:expect(t.b[1]).is(10)
_:expect(t.b[2]).is(20)
_:expect(t.c).is("hello")
end)
end)
end
This tells us that we can use the global data capability to pass things from our tools into the application. It might get grubby, but we’re good programmers, and we can hide the grubbiness inside the objects that do the work.
A quick check tells me that I can’t save an image in global data. But we can certainly save images directly and pass their names in global data.
This bit of “design thinking” tells the team (me) that there is probably enough capability in Codea to let us build a “making app”, or a set of “making tools”, if we want to.
Down to Earth
Returning to our home planet, we need to decide whether we’ll do some work on a “making app”, and when we might do it.
Let’s do this. From now on, whenever we do some bit of work that could be done with no programming, or a lot less programming, if we had a tool or mini-app of some kind, let’s commit ourselves to writing that tool. We’ll keep things light, just doing enough to support whatever the current bit of work is, without a lot of generalizing. Instead, we’ll generalize when the little tool can’t do the next thing we want it to do. Over time, we should wind up with some useful tools, and a sense of what a “making app” might be like for a program like this one.
I think I’ll call a break for the morning. I’ve got errands to do.
See you next time!