Latest Junk Picture

I just finished this little beauty this morning. Note the ropes and the pylon. It took FIVE HOURS, THREE MINUTES AND TWO SECONDS to render! That was with a number of time-wasting options enabled, particularly the Rope functions.

Pylons

I'm going to have pylons in the water for the junk to use in navigation. These pylons will have a sort of road map on them, leading to the island.

Things are moving much faster for me now. There's a thrill of anticipation that I'll soon have a second working example with much more substance to it.

Strategy Again

I am finding my slow pace of development irksome. I have today been thinking of strategies to get another short example game out quite quickly.

Among these strategies are:

Complete the first section of the game quickly, without further refinement, and forgetting the next section.

So:
- Junk
- Dockside doors
- Elevator

I'll just get on with that.

Comments on POVray techniques

Following up on the comments in the previous post, I should point out that I can optionally apply a grid to any scene. The grid is a series of cylinders, set 5 units apart and centred on the origin of the scene. That gives me an accurate measure of where to put an item. I build the item and rotate it at origin, then move it to the desired location.



The animation (which I may use for a multi-render batch file), briefly, works like this:

"POV-Ray supports an automatically declared floating point variable identified as clock (all lower case). This is the key to making image files that can be automated. In command line operations, the clock variable is set using the +k switch. For example, +k3.4 from the command line would set the value of clock to 3.4. The same could be accomplished from the INI file using Clock=3.4 in an INI file.

If we do not set clock for anything, and the animation loop is not used, the clock variable is still there - it is just set for the default value of 0.0, so it is possible to set up some POV code for the purpose of animation, and still render it as a still picture during the object/world creation stage of our project.

The simplest example of using this to our advantage would be having an object which is travelling at a constant rate, say, along the x-axis. We would have the statement

translate <clock, 0, 0>"

Green Shoots of Recovery

Last night, I dusted this project off, improved the staircase algorithm, and added a staircase to the Jade island.

One of the problems is the length of time each render now takes, even for a minor adjustment. However, once some new component is settled, I think it's probably going to be possible to set up a batch rendering job to produce all the renders anew, every time a significant component is added.

I have decided to inch the project forward in its incomplete state, adding as many of the individual stages of the game as possible, even based on an incomplete background picture.

For example, if a new bridge, building or piece of furniture is added to the island, then I might have to re-render a number of backgrounds later, and I might have to modify the positions of sprites to an extent, but better incomplete scenery at this stage rather than incomplete gameplay.