Tuesday, March 20, 2012

State of the project: 3/20/11

This is rambly and questionably edited, but I wanted to get something out there about the project and what's up with it.

There hasn't been a lot of comment here recently because I've been thinking long and hard about the design, and about what I'm happy with about the direction In Profundis is going, and what I'm not so happy about.

Because of this, a semi-radical redirection of the project is underway.  Many computers are not fast enough to run an automation of the size of the game's world as an action game unless I only simulate a zone around the player, and I've been unhappy with my efforts to make a platforming engine. As Miyamoto has been known to say, an idea is something that solves two problems at once, and I think I have the solution: to make In Profundis a quasi-real-time, turn-based game.

So how will this work?  Well, first off, character movement won't be on a pixel level.  Instead, like in roguelikes, the character will move one cell at a time.  There will probably be an animation between cells and some concessions to playability, but you won't be able to stop "between" spaces.

The game will attempt to simulate the entire field each frame.  This will greatly reduce framerates, but will mean that the engine can support one of the features I consider to be essential: continuously flowing water between points.  If I don't simulate the whole field then liquids will tend to accumulate at the edges of the execution frame, meaning flows like waterfalls and rivers will eventually cease if one end of the flow is outside the frame.  Obsessive thinking about the problem has identified no solutions that themselves won't cause bigger problems, so I've come to the conclusion that cheating this isn't the answer.

This means to a degree actually abandoning the platforming physics engine, but I'm okay with it as it has taken a disproportionately large amount of development time to implement, and it's still pretty bad.  By simplifying the physics here, I can avoid some of the annoying edge cases that result in frequent character wall embeds, or at least handle them more elegantly.

However if you sit and do nothing, I'm thinking that game time will not freeze, although it may slow down.  Not only does this still provide some time pressure, but it also makes it more obvious what direction flows are going without having to add new visual elements to identify them.

What will probably happen is I'll run the world simulation and character turns on different threads.  One problem with this, however, is that Python threading is a odd.  To my understanding, due to the existence of a thing called the Global Interpreter Lock, threads aren't like real operating system threads, but cannot execute more than one process at a time, even if Python is running on a multiprocessor system.  (There is a module to get around this, multiprocessing, and there are versions of Python that either remove the GIL or make it less onerous, but I'm not sure how compatible those are with Pygame.)

But one good thing about this is, since the game won't be so dependent on processor speed, we'll be able to abandon Psyco.  Honestly it has been the source of many technical problems.  It works great as a drop-in solution that just "works" to make Python faster... so long as all your modules work with it (at least one has mysteriously broken in the past when Psyco's been enabled, which took some time to discover)...  and so long as you avoid esoteric language features like generators... and don't use Python versions after 2.6.  I've at last reached the point where I'm ready to declare it's just more trouble than it's worth.  Fortunately, it's just as easy to remove as it was to add.

As an aside, I am thinking hard about the nature of fluids.  The game can currently simulate up to eight kinds of fluids with random properties, but that might be a case of too much randomness.  It might be best to stick with water, sand, and a couple of others in each world.

5 comments:

  1. Funny that you're thinking of going the "turn-based platforming" route...As if you want to see a turn-based side-scroller in action, you can check out my latest 7drl, which is exactly that:

    http://roguebasin.roguelikedevelopment.org/index.php/Fuel

    Hope you manage to get everything sorted out :)

    -Ido.

    ReplyDelete
  2. Have you considered only processing cells near the player, but also any liquid cells (that are not settled) in the whole world?

    Also, do you plan on writing any more @Play's? I guess not on GameSetWatch due to its demise, but somewhere?

    ReplyDelete
  3. If the benefit of a turn-based game is that you can take your time with calculations, it seems to me that having game time advance while you are idle would defeat that benefit, or it would mean that time flows faster on faster machines.

    I think I mentioned ways around the GIL earlier, so I'll not repeat that.

    I'm not sure how to make practical use of this, but you might want to consider that parts of the simulation of a frame could theoretically be run ahead of (or behind) the turns the player makes, given that what happens at one call at one particular time can only have an effect on cells within a distance of (speed of light * time difference). Even if you just simulated most of the world a frame ahead, that might make a turn-based implementation a bit more responsive.

    ReplyDelete
  4. I am aware of the problem of machine speed. There will probably be a frame rate limiter while idle as future-proofing at least. Feel free to re-mention the GIL lock things if you want as that was months ago, if you don't though I'll just look up the old message.

    On @Play, it's not like its update frequency as all that great in the months before GSW closed shop. I think I've said most of what I've had to say about roguelikes at the moment, although I do participate sometimes in Roguelike Radio. While I decide what to do with @Play you can sometimes catch me over there (although also infrequently).

    ReplyDelete
  5. Less liquids is probably not that bad at all. As long as you can explore different worlds on the same character. It would help the different worlds to be more unique.

    Rather than having worlds be like 5-6 different random liquids(which would often overlap). You could have 1-2 different ones, which could lead to certain worlds having that unique useful resource that you may want to come back to in the future.

    ReplyDelete