Sunday, July 31, 2011

In Profundis Progress 7/31

Work on the game has been rather hard as of late, but I have basic level building working now. What this means is, the game will now construct a roughly naturalistic-looking maze to explore. Getting around in the maze is for when equipment is implemented, which is moving closer.

Although the game has maze-like caverns now, they aren't very interesting yet. Next is to flesh out the world builder a bit. This is a multi-stage process involving dividing the maze up into regions, styling each region according to a generation theme, tweaking passages, making the ends of the maze into places worthy of discovery, and making loops in the maze so as to give players multiple ways of access in case one proves too difficult.

More soon. I intend to post a new video once caverns become more interesting looking.

Friday, July 29, 2011

In Profundis Progress 7/29

Still working on generation. Spent today tracking down a mystery bug that turned out to be caused by my misunderstanding of numpy's workings. Hopefully more to show you guys soon.

Sunday, July 24, 2011

In Profundis Progress 7/24

Been a few days since the last report.

The big thing I've been working on has been random substance support. Part of this means retrofitting the fluid physics code to generalize a number of prior assumptions. At the moment there are five fluids: water, sand, oil, "fire" (which doesn't burn anything yet, and burns out almost immediately) and "sediment" (a kludge to create smoothed rock floors). Under the new system, water and fire, and maybe sediment, will be the only hard-coded substances. (And I'm considering towards removing water's privileged position.) The others would be possible options that could be randomly included in a world, or could be "mutated" so that it works with different physics, or there could even be entirely random fluid types, made of different properties like density, flow mode and interaction types. Gas and stone would be similarly scrambled, although their workings would be less complex than fluids.

A second thing I've broken ground on has been the world generation. At the moment the "Terrain" world generation has been surprisingly interesting, but it's time to construct some actual play territory now, bringing in a semblance of game design to what up until now has looked more like a tech demo.

I've started on building the world "pieces" that the game will piece together to make worlds. The terrain generator is a further elaboration of the stuff I did for Mayflight, which is in place unfettered as the current generator. So, the "world pieces" I'm talking about are more accurate described as influence templates.

One problem that lies in this direction is that while the Mayflight terrain generator is awesome at producing nicely corrugated terrain, it's not so great at producing solid, pre-set puzzle areas. I like of like that though. I want the game to be more about making terrain which might sometimes be too easy or too hard that taking a strong design hand and making a bunch of pre-made situations, situations that might be interesting in themselves but by their very nature are still finite in number.

Thursday, July 21, 2011

In Profundis Progress 7/21

I've got gases partly reimplemented, they aren't displaying properly at the moment though.

I'm also putting in some of the infrastructure for randomized material properties. To explain:

One of the basic ideas of the game is that you encounter liquids, gases and even walls with unusual properties. They might be bouncy, or sticky, or flammable, or explosive, or poisonous, or have any of a number of other possible attributes.

Here is my plan for implementing this.

First, there is one of each type of substance (fluid, gas, stone) that is not random, but is otherwise boring. For fluids this is water, for gas this is "breathable," for stone this is "inert." My idea is that this substance is the most common of its type in each world, except maybe in the weirdest areas, just to keep down player confusion. (If everything you touch immediately explodes it doesn't make for a very interesting game.)

There are also a number of other predefined substances. Sand and oil are the two major types of these we've seen to date, both holdovers from World of Sand.

Each world also bears a difficulty value, which increases as the player explores more worlds. As difficulty goes up, at world generation time the game will randomly switch out more of the stock substances. So a game might not have sand, but another fluid. It might clump like sand, or it might slide around the ground, or it might slowly eat through stone, etc. Higher difficulty values also make it more likely that dangerous attributes are selected. Later on it would be possible for each substance to actually have two such attributes.

My problem here is: will this make for interesting gameplay? This is the biggest question of the design. My hypothesis is that it will if the player is given a limited number of ways to figure out what substances do, akin to the rogue like scroll of identify and Nethack's many ID tricks. I think this should be balanced so that players can't test out *everything*, just some things, forcing him to put up with whatever special attributes other things turn out to have.

Even if it's interesting, will it turn out to be enough to carry the game? The exploration aspects, the navigation and treasure seeking, and the resource management game of making efficient use of your equipment, all of these things together are what I consider to be In Profundis. If that turns out to be fun by itself then we can make an initial release and add in stuff like fighting/communicating with aliens later. If it doesn't, well then we might have to add in other actors earlier rather than later.

Sunday, July 17, 2011

In Profundis: New Video

The work on the graphics engine has borne a bit of fruit.  Have a look:

This is the first time I've shown off the engine using larger tiles.  Of course the graphics for walls are fairly plain right now.  What isn't shown is that there are now up to eight kinds of stone, which will have randomized properties.

The big thing that's visible here is that sand and water now has a smooth surface.  In particular this looks nice when a single level of water is moving around at the surface of a pool.  At the moment this is only cosmetic, and a bit glitchy at that.  Notice how, when water meets up with sand at about the same level, the sand angles down but the water stays level, and so it looks like it's being held up by air.

Also, the known "map" areas out of sight but still onscreen are now displayed using outlines.  There is some intelligence there that outlines the edges of the region but not the tiles in the middle.  It's not perfect yet; you can see some dots in regions where aborted walls are drawn, and the line isn't complete at the right-hand sides of slopes.  Not to mention, in some cases where sand is underwater, a black corner is drawn on the sand.

The update engine now uses a hybrid of the first system, which was a simple for loop, and the second system, which kept a list of all the tiles that might change this turn and iterated through them.  Now it iterates through the cells in a spiral pattern from around the "focus," which is either the player's location or the cursor.  It keeps a "dirty" flag on cells that might need updating next frame, allowing the game to avoid looking at every cell with complex interactions, like fluids, just to determine that they don't have anything to do this frame.  There are a couple of bugs with this too at the moment: sometimes the game forgets about liquids on "steps" and they are left to just pool there, and in edit mode placed fluids don't do anything until an adjacent space is modified.

I've also started planning out how gasses will be returned to the game.  They probably won't be updated as often as liquids, which befits a more diffuse way of spreading.

Friday, July 15, 2011

In Profundis Progress 7/15

1. Considering redesigning the character some more. It's not that it's not okay, but it's more like, we already have a CA-type game with graphics of sort of that style (Terraria). I'd like to distance this game as much as possible from that.

2. Abandoning the "coordinate list" more of keeping track of updates. The sort is just too much of a performance penalty. Someone MeMailed me a while back and suggested using a quad tree to keep track of which cells needed to be updated, but I frankly don't see how I would get substantial advantage from that. I will admit I am no expert on the structure though. It seems to me that any advantage gained from that wouldn't be greater than just iterating through them and using update flags to rapidly skip by any cells that don't need calculation.

Wednesday, July 13, 2011

In Profundis Progress 7/13

Some heartening progress over the past couple of days! I've somewhat successfully gotten the graphics rendering to display more smoother graphics for liquids without resorting to making hundreds and hundreds of tiles covering every possible liquid state. I'm not sure as to what the performance hit is for it yet, more news soon.

Tuesday, July 12, 2011

In Profundis Progress 7/11, pt 3

I think I've discovered the best way to smooth over the liquid tiles. It does require a fair amount of extra tiles to be generated, but it shouldn't be any slower than the current system.

I did a bit more looking into the state of Python. There are some very promising avenues on the horizon for it, that should be of interest to other Python game developers:

1. There is an optimizing compiler for Python coming up called, in the style of Monty Python references, Unladen Swallow. It's developed by Google so it has some strong support behind it, and the word is that eventually it will make it into the stock CPython distribution. That, coupled with the existence of Cython, make it clear that there is strong hope for dropping Psyco in the future.

2. There is some murmuring in the community about creating a version of Python for iOS. That's a target platform for me. I don't know what the performance will be like (word is that it's not bad), and anyway the "gold rush" phase of iOS development seems to be over, but it's still a bit of a vanity thing for me to make an iPad version. We shall see.

Monday, July 11, 2011

More In Profundis Progress 7/11

Additionally, I reimplemented an extra little quirk of vision: you can no longer see through sand or sediment more than a full layer (meaning, for example, you can no longer see the stone floor beneath sand dunes), and full tiles of other liquids halve vision range through them.

In Profundis Progress 7/11

Today, I'm working on a bit that will simplify liquid tiling. Instead of drawing each tile and referring to them all one at a time from the source, I'm just loading in a mask for the liquid, colorizing and saving it for later use at startup. This means, instead of having 16 tiles for every liquid in the game (8 for visible, 8 for map), I just have to have 16 tiles, period. The game makes the colors itself.

This is important because one of the biggest complaints with the videos was the blocky graphics. Smoothing them out is not as simple as some people seemed to think it would be. The easiest/fastest way to do it would be to create tile graphics for every possible slope of liquid surface, but with at least 8 possible liquids in a world, maybe more, that quickly runs into many, many tiles, which would take a long time to draw. This way, I just have to draw a basic set of tiles and colorize them ahead of time. The biggest drawback is that adds up to a lot of tiles; over 1,000 by my reckoning per liquid, but compensating for that is that each is only 32x32 pixels.

Well, we'll see how it turns out.

Sunday, July 10, 2011

In Profundis Progress 7/9

Current work on the game concerns mainly refining the platforming. One of the complaints people had upon seeing the videos was that the world looked blocky, especially falling water. While I haven't decided on the best solution to illustrating falling liquids yet, the platforming change should make sloped surfaces a little more feasible. Emphasis on "should;" it's going to take some work regardless. Sloped surfaces are deceptively tricky to implement in the way one would expect (which is largely based upon Mario 3) in a tile-based world.
Also, I've switched the internal representation of the world fro a Python list-of-lists to a numpy array. The result is a very slight performance boost coming from reduced overhead, but more importantly it simplifies the code a bit, and should be easier to optimize in Cython.
Both these things took rather longer that you might expect, from tracking down bugs and charting out code. Still, progress is such that morale is up at the moment.

(EDIT: Fixed date, which was incorrect [again] due to confusion over the current Peanuts Roasted date.)

Thursday, July 7, 2011

In Profundis Progress (7/7)

More bug fixing in the wake of the switch to more integer-based math for platforming. Internally actor coordinates are switching from pixel-based math, with decimals handling sub-pixel movement, to 16 subdots per pixel. This means tracking down a few places where values are translated between pixel-level representations and cell-level.
The next thing I'm working is making platforming as bulletproof as possible. Sorry if it seems like it's going slow, I am but one person. It is happening though.

Wednesday, July 6, 2011

In Profundis Progress 7/6

The past two days of work have been oriented towards ripping out as much of the floating point math as is convenient from the platforming engine, and switching it to integer.  It's a general code improvement thing; relative to the amount of time the game spends updating the world state, the performance gain from removing floating point math is slight, but it'll make collisions simpler to detect and handle by not having to worry about piddling small decimals riding on the value.

Sunday, July 3, 2011

In Profundis Progress 7/3

I had a bright idea.  What if we didn't draw every tile every frame?  What if we just scrolled the image from the last frame, and drew in tiles that changed, those scrolling in from the edge, and those around actors?

Today I tried this out.  And you know what?

It really didn't make all that much difference, while it cluttered up the code with drawing flags and checks to see if the tile scrolled in.  I think the scrolling, even though handled by SDL, end up taking almost as much time as it took to just draw the tiles anew each frame.  D'oh!

In Profundis Art: Character Idea

To replace Placeholder Guy as protagonist, here's a sprite I've worked up.  Tell me what you think:

Points of interest:

It's a girl, but not ostentatiously female.  In the final game there might be a gender choice, depending on how much time it takes to make alternate versions of every frame of animation.

Shoes are a bit oversized.  I like to think of them as "clompy boots," in the style of the Iron Boots in Ocarina of Time.

Realistically proportioned body, with a big head. 

Orange backpack, ala Earthbound, explains freakish carrying capacity.

Clothes functional, a bit baggy.

Dammit Blogsy

Sorry about the Peanuts post here.  Been trying out a blogging client, and it makes it easy to get blogs mixed up.

Friday, July 1, 2011

In Profundis Progress, DIrection

So, here is where we are:

I have changed the graphics loading mechanism to use "atlases," large images separated into tile blocks, instead of the many individual images used before. This will make improving the graphics a lot less annoying. The tile size has also been increased to 32x32, which fits less onscreen at once but gives a better view of the world. We'll see if it's a good change with play testing, it won't be hard now to change it back.

The two most promising leads for performance improvements are Cython, a Python-to-C converter, and OpenGL. In the first case, that is something best saved for much later. In the second, the PyOpenGL library has a bug that prevents its installation under Python 2.6, so that's going to have to wait for now.

Today is mostly devoted to graphics work. I'm considering character designs for the main guy. I might temporarily import Aurora from Mayflight to fill the role, but she's 16x16 anyway. She'd make a good placeholder though.