In Profundis Progress: Tools, Inventory and personal coding deficiencies

This is about the place where my general lack of experience with modern (that is, post Commodore) development is biting me hard. Something I've been worried about is the representations of user-placed items in the world. There are three general possibilities here, and I've messed around with each one to some degree. Possibility one is to implement them as sprites, that is, as moveable objects that can move independently of the cellular grid, like the player can. This is what I tried first, but after a bit of that I realized that it really wasn't a good solution. Part of what makes tools interesting is how they can interact with the game world, and every object that isn't part of the basic world model, even if it's grid-aligned, complicates the code. However, it gives rise to the problem with possibility two, which is, define special tiles for in-world tool objects. It looks weird when water flows around a piton as if it was a full-block object. And a lot of tools are like this. It's the existence of liquids and gases, which are just cheat analogues for sub-grid-level phenomena, that makes this an issue. The nature of the game is such that, if push came to shove, I could probably get away with doing it that way anyway, but instead I'm opting for possibility three, which is to give each cell a tool field that can contain its own object. This way liquid can flow past a piton without overwriting it or flowing around it, and objects in lakes can rest there without making an air bubble around them. Now the better programmers out there are probably wondering why I'm spilling words on such a decision. It's because, really, this is the most complicated project I've ever worked on. Mayflight's world builder was more complex, but its world simulation was just a platforming engine. I'm somewhat out of my depth here. At least writing this in Python means I don't have to muck around with (overt) pointers and worry about the myriad bugs those can introduce. I visit anna anthropy's blog pretty frequently, and I've been known to chuckle to myself when I read about her aversion to coding. I really can't imagine doing a whole game using, say, Game Maker's abhorrent drag-and-drop scripting functionality -- I always tie each event to a text script. But really, I'm just one step further along the path than she is, and there's a dozen ahead of me. What is funny is that I was a quick study back in programming classes, but there's something about pointers that screws me over. It's not that I don't understand them -- far from it, I have a strong processor-level understanding of the things. I did a fair bit of assembly programming back on the C64. But something about the way C-style languages approach them trips me up hard. I'm constantly confusing where I need to use * and where I need to use &. I know that * is a pointer to some value, and & is the value that a pointer points to, but I don't seem to have it internalized to the point where I can write code with those symbols confidently. I wouldn't be surprised if I had some form of dyslexia tripping me up there. The language is such that you must know what is a value and what is a pointer to a value, but I nearly always get them mixed up. This, coupled with the fact that I was continually stymied by import errors, was probably what sabotaged my attempts at restarting In Profundis in C++. Game Maker is really not that different from C in syntax, but its garbage-collected, reference-counted scripting was the breakthrough feature that got me productive with it. I'm just blabbing here really; I felt guilty that it had been a little while since I made a post here. Anyway, working in inventory and tool simulation now. I hope to start putting in the backer treasure data before long, so that'll be fun at least.

In Profunds ideas: Flags

So here's something big that I'm playing around with....

In Profundis gives you a limited inventory for carrying around equipment. You tend to use up resources while you're exploring the game world, placing pitons, hanging ropes, and so on. Eventually you have to travel back to base and resupply.

A concern that I have for the game is that this travel back and forth, between base and the frontier of exploration, could get annoying, or worse, boring. But the resource and time costs of getting around the game world are the primary obstacle to exploration. How do I reconcile the two?

My idea is a special inventory item: flags.

After you explore for a while and figure it's time to return to base to resupply/get some rest/buy new stuff, what you can do is plant a flag at a place you'd like to return to later.

After this is done, the challenge is this: return to base without using any other items in your inventory, in order to "establish" the flag. It's like a mini-game in a way. It is okay to use items you've already placed, so you can sort of pave the way for your return trip. If you're forced to use an inventory item the only thing lost is the establishment run. In that case the flag remains where it is, and you can try it again just by returning to it.

The reason this has to be done is because the game is recording how long it takes the player to do it, in order to figure out a realistic travel time, and using resources along the way that might not be available later would spoil the experiment. (It's possible that this might just be "shallow travel" equipment, like jetpacks, rather than things that change the game world to make it easier to traverse, like pitons and spanners.)

After you've established the route, you can later "instantly" warp between base and the flag. Instantly is in quotes because this is only immediate to the player -- the game clock is set ahead by the amount of time it took to make the trip. Since the expedition is charged rocketship rental by the amount of time spent on the planet, this is a substantive cost, but it's your character who has to pay it, not you. The character is still making the trip, in effect, on autopilot. (In fact, I'd like there to be a "montage" of still shots of the trip, that takes a few seconds to play out, whenever warping.)

Continuity of the game world is very important I think. The problem with teleporters is that they basically make a mockery of the spatial extent of the world. I consider this bad because, as the player makes longer and longer expeditions, the increasing time required to get from base to the exploration frontier is, itself, an increase in difficulty. Exploring the other side of the map takes more time, which incurs more spaceship rental costs, which means the player can't afford to waste as much time.

Some of you are no doubt reading this and thinking something along the lines of: WTF? I think I can understand that. But I look at it this way: I've played hundreds, if not thousands, of video and computer games, and I've never known a game to do something like this. Maybe there's a reason for that. But it's a very interesting game mechanic to think about, and I think that will transfer to play. What do you think?