Saturday, November 19, 2011

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.


  1. Hey John,

    If you'd ever consider allowing some one else to help you out shoot me an email. I've been following Profundis' development for a while now and I'd love to help you reach completion. If you want some programming help or advice just send an email, I'd be happy to oblige.

    I've got quite a bit of experience in C / C++ and my experience with Python is light. But I am a seasoned programmer, just most of my time has been PHP and Javascript.


    - Ryan Badour

  2. Hey John,
    my english isn't that good, but I hope you understand me. I commented on one of your last posts that I was inspired by your work and started my own little simulation. I started my project using Ruby, because that was the only language I really knew until then. Soon I had serious performance problems and looked around for other languages and restarted it in Python, again performance problems. Then I read a C book and learned more about SDL, started again... got stuck because I couldn't solve water flowing problems and still can't find a good solution after 3 months... I'm not the best programmer, but I know that I love programming and it doesn't matter what language you use or how you solve a problem... all that matters is that you have fun doing it. Pointers are very confusing at first, but once you know when to use * and & it gets easier. I found it much easier work to with C because I already knew how to do it in other languages. I still don't feel like I'm that good in writing C code but it gets better and better. The more code you write the more confident you get.

    And for the 1, 2 or 3 part:
    I'd use #3, this more or less the same that I did for all cells.

    struct Cell {
    unsigned cell_type:4;
    unsigned direction:2;
    unsigned mass:4;
    unsigned calc:1;
    } cell[TOTAL_CELLS];

    Every cell has a type that I set for each block/liquid. That way I can delete or change it. If you would add a tool field, that could get ignored by liquids/gases flow.

    Good luck ;)

  3. I felt the same way about pointers (I think lots (most?) of us do at least at first) for years. I honestly can't remember what I was reading at the time, but I can actually picture the moment I truly grokked pointers. I was learning how to write OpenGL code, using SDL. Some article I read seemed to tell me the same things I had read many times before, but this time it all just made sense.

    Sorry if this comment is kind of rambly, but all this talk of pointers brings back both horrid and happy memories. Also, I just spent way too long coding, and it is now 0500 and my brain is mush.

  4. My initial thoughts for how to solve this would be, rather than shoehorn a field into each cell, create a second layer of cells, one for the 'world contents' and one for the 'object contents'.

    You may also want to look into 'data oriented design'