#development-updates

[grown-gato]

Update

I've got sounds and such working. While I thought to make another release, instead, I'm going to add some basic inventory and an in-game console for messages (such as for in-game events.)

At that point I'll release the next version. I've decided to hold off on enemies until the release after that.

[grown-gato]

Demo 1 Tomorrow

Alpha 1 for Legend of Grack is tomorrow. It's not much; preparing it for play as opposed to simply adding more features was a bit more daunting than I originally thought.

[grown-gato]

Something this weekend

We've got a few more pieces of concept to share, and then I'll get the demo to the point where I feel comfortable letting people play it.

I mean, it is ready now, but there's not really anything to do. Boring.

[grown-gato]

Work Update

Working on WorldFactory at the moment. You should be able to create fixed worlds, ones which are fundamentally not grown from seed, as a series of png files, one for each zone.

The general rule is that worlds are divided into three levels:

Blocks, which are voxels / atomic 'units'

Regions, which are the fundamental partition - saves will have one block of data per region and worlds are loaded and updated per region.

Zones, which are regional partitions. In unlimited worlds they function as the outer partition for world storage and some of the director process' actions use zones to calculate wider 'functions' like whether water is salt or fresh, level of water table as a function of the distance from mountains, river flow directions, etc. In Fixed worlds they can be used to partition boards or levels; creatures can be bound to a single zone. You can also force the loading of a whole zone regardless of the radius (based on render distance.)

Worlds can override a bunch of game rules for convenience (such as clipping, various normal player effects like hunger, etc.)

The main purpose here is to set up the world loading process from-file/jar (no url loading yet) and to get the geometry, collision and raycast properties of solids, light and fluids working decently so I can create a working demo.

Eventually you'll be able to create cells using the variant almanac format (the one that lets you declare variable bounds for each texture in the file) which are a variety of prefab 3d objects such as brushes and room shapes for caves, as well as brush patterns for ore distributions and structure parts.

The ultimate goal is a person with skill and dedication need not buy heavy handed licenses to create high quality, 3d, block based games. The main person this benefit is intended for is me.

We can just be honest here.

[grown-gato]

Back From The Dead

We really weren't dead! We were just refactoring our whole lives and game engines.

Soon I'll get the new engine up to the state that the old engine was in.

Features:

- PLANEWALK: Built in world testing tool (note: not world EDITOR, System's worlds are either generated from plain files that can be edited without special software, or from algorithms whose inputs can be altered without special software.)

- MODELVIEW: Built in model testing tool. View and test models in jar and out of jar; reload them as you tweak the settings and image files until you get the right look and feel.

- GENIE: Game Engine is an Emulator. Based on the way the game modules are programmed, the system functions somewhat like MAME or a console emulator. For instance, while working on a title, you can place links in the configuration menu to go to PLANEWALK and MODELVIEW (or any other tools you need, such as the upcoming ARENATEST.) You can also include multiple games in a package.

In general, the new engine is far more sane and better organized. The 'ip' directory fundamentally assumes you will start by creating a title driver (ip.gamename.GameName.java for example) that extends the Game class. You can then load it by passing the command to the init state title=GameName. I don't yet have the ability to find and include an external jar, partly because I want to have versioning more fixed before that point, and also I want to fix some points of the API more firmly so building modules doesn't require insane refactors just because I wanted to change some underlying behaviors in the main game I'm building.

I've moved over to 'sprites' instead of regular 3d models for objects. Regular 3d models are still possible, so long as the 3d model class properly interacts with the ModelController and implements the Model interface. I don't currently have a means to easily add new model types to the ModelFactory and I'm also trying to work out the degree of stasis for Model assets. In short that means, if there are fifty goblins are there fifty goblin models, or just one model asset with fifty instances of settings?

The latter is better but complicates models because you have to determine what parts of the model should be static and what should be hypostatic (i.e. specific to the individual instance.)

---

The biggest breakthrough is that System's world system should be flexible enough to be used in a variety of games, despite being 3d-grid based. Warping the grid or the points of the grid for individual blocks according to simple rulesets (in the block's geometry method) that result in VBO (vertex buffer) friendly geometry is easy.

By maintaining a central thesis that the 3d-grid world is superior we eliminate a lot of 'what-ifs' and guarantee that the world is as destructable/constructable as necessary according to the game.

---

While I have simple lighting created, I will not do as I did before and maintain an exhaustive list of what lights are at each point, with their direction. In any case, there is a relationship between the physics light class utility and the lightmap interface, however the lightmap interface is implemented is of less consequence than whether it works or not. I found that liquid light, which is light as a simple fluid-spreading automaton, has a lot of advantages and few problems.

- It automatically creates the feel of reflected light

- It is simple to regenerate from a given point without reference to the originating point

- Small tweaks can make it behave more 'realistically' without breaking the bank computationally.

The nickname I give this automata, which I believe is similar in concept to Minecraft's light, is Liquid Radiance.

---

Terrain generation has started with cave carving. Cave carving involves three elements:

1. Tunnel digging

2. Room carving

3. Chain reaction

If you play Minecraft you may know how subtle and quite advanced Notch's cave algorithm is. It is potentially the oldest part of the code (the game started as a cave test) and therefore has probably seen the largest number of tweaks. I can't vouch for that, but it does seem to have subtly improved over time.

Digging involves a start and end point, a noisy brush, and the ability to iterate in a fully arbitrary direction without recourse to mathematical rotations. I have a sort of rudimentary form of this, though it tends to fall apart at angles close to 45 degrees, requiring some secondary filler carving due to the fact that moving 1 x, 1 y and carving perpendicular to this causes you to miss almost exactly half the blocks you want to carve. In theory the solution is to always move a distance of 1 (rather than 1.44 as in the 45 degree case I've shown) and let the carved position be rounded so that at all angles you see a smooth expression of the chosen brush.

Rooms are simple; they usually have four orientations (more is possible) and may be nothing other than a 3d primitive combination with some noise.

Chain reaction is the trickiest part, where as in the case of all Cellular Automata, starting values have far wider possible ranges than useful ranges. Unlike Minecraft, generated caves and tunnels will have abstract properties that will allow the generation of navigational nodes and a control over growth that will permit a wider variety of expressions. In some cases, to get some types of caves in Minecraft you'd have to put the caving algorithm into 'unsafe' ranges where it might hit a point of infinite regress.

Not all caves carved will be separate entities, some tunnels or rooms may be common to more than one system.

[grown-gato]

Brief Update

My development box has a case of the 'water cooling system not working properly' - It's going to be replaced by a Thermaltake Frio and some 88CFM aluminum fans (all probably, realistically, much louder and more power-consumptive than the current setup) all so that my CPU temperature runs less than a deadly fever.

The model translations and lighting work well; I'm working on a simple way to animate points (this is required for several things: torches, candles, smoke, etc.) but I'm royally screwing it up trying to modulate the point size and adjust the texture position on the fly. Someone message me and tell me to just keep the point the same size and move it semirandomly around a set of flame images - thus creating the pulse and waggle of a fire.

Or not, whichever. Either way, you'll get models soon enough, then player models.

[grown-gato]

Minor Weekend Update

This weekend I worked on the code to make the world destructable. The bulk of the work actually involved rewriting my face creation code; given that you need to be able to programmatically generate the faces of the newly subdivided solid, it's pretty important that the face creation make sense.

The major issue I've run into is that I used a different coordinate system than GL. My original decision to do this was because I thought that a map coordinate system would make the most sense; i.e. x and y are East/West and North/South, and z is depth. Whenever dealing with world objects, You can reliably know that x,y and z are an absolute coordinate system with the logic of a map.

The trouble is translating this to GL, not because x becomes -z and y becomes -x and z becomes y -- that would be fairly easy to handle; but the fact that whatever world coordinates you use have to become face verticies first, and unless you feel like doing a lot of hardcoding, you need to make some functions that can figure out 2d faces (with texture coordinates, always in 2d) from a 3d object.

Obj format files are helpful here, as they already give you all of your points and their relationships as faces in the 3d object. Sometimes it even contains the normal directions of the faces themselves.

But when you get into editing the objects on the fly, especially in the case where you can break apart a face, this isn't much help for the task. The only thing that seemed to make the problem solvable in a way I could read and understand later was to make face creation done by a 3d point, three lengths, and the texture alignment values, plus a few flags. When dealing with cubes (which all destruction results are, anyway) it becomes very simple to iterate through the possible accidents to the solid for each face (if the solid has any) and create subfaces with the same orientation, a fraction of the size, over every point that doesn't have an accident.

The final step is to render each accident as an inside-out cube, and omit faces where other accidents touch the current one, or where the current accident borders the edge of the solid.

Since I don't bother hiding occluded faces (yet, anyway -- we'll see how much its necessary later) this process can pretty seamlessly expose hidden solids.

The bugs I've run into involve properly re-aligning the textures in the updated solids (for some reason, the non-outline style textures are misbehaving) getting the interior faces to have the right texture alignment, and dealing with solids smaller than a half block in one direction. That will also involve creating accident 'interiors' of smaller than 1/2 by 1/2 squared.

But it is sort of weirdly entertaining having the left mouse click button be the equivalent of a high-powered solid state laser.

I still haven't updated the occlusion and light maps (though the new faces do pick up light properly) nor can you pass through the holes you make -- some updates to the clipping code are necessary to handle accidents to a solid when running the clipping algorithm.

I regard this as wholly necessary, even though it seems to delay making Grown an actual game, because I find destructability to be an integral part of making the game play the way it should.