Date: Dec 17, 2010
Screenshot #101: With most of the terrain generator up and going (saving progress (very easy, quick), collision detection (medium, slow), adding the grass effect in (easy, fairly slow), enhancing the controls to speed up the process (mostly easy, moderate), getting numerical input functionality added (easy-medium, slow), adding in the cursor (very easy, very quick), and a bit of other fine-tuning still remain), I thought I'd take a screenshot and show what the initial draft layout is. Of course, what you see here is not the real terrain itself, but it gives a good idea as to what I went through during the time I began designing the terrain. Since I resolved the platform colors issue a long ways back, I freed up a ton of memory, opening up the possibility of the terrain
Without saving the progress, I'd have to redo the terrain every time I start the engine, but that's quick and very easy to add in.
Collision detection is the most complex part of what remains to be done. Without collision detection, you'll fall right through the ground like nothing was there. Determining the height of the ground at any given point is quite easy. Having the acceleration increase while going downhill or decrease when going uphill is also easy. The real challenge is when it comes to jumping or bouncing on slopes that are not perfectly level. What's the problem? Figuring out a way to adjust the horizontal and vertical speeds upon a jump or bounce. Here's a situation to consider. When going uphill on a 32H4V slope at, say, 20 mph, and I jump at 20 mph, what would the new horizontal and vertical speed be immediately upon the jump? What should happen is that some of that horizontal speed gets lost in exchange for a greater vertical speed. When going downhill instead, vertical speed is lost in exchange for horizontal speed. Bouncing is similar, except the speed is cut in half... when exactly perpendicular. It's easy with perfectly flat terrain like I had until this point, but it's harder with uneven terrain. Hitting a rather steep 32H32V slope while coming straight down should eliminate most of the vertical speed (should still be going down) and cause a huge amount of horizontal speed. The actual speed should be probably around 70% of what the original was. I do have an idea for resolving this though - temporarily "rotate" things to that where the slope would be perfectly level, get the updated speed data, then "rotate" them back. Those sine and cosine functions will get quite a workout with this part.
The grass effect had to be removed for the terrain editing simply because I need to change the image so that it matches up with the slopes. This is easy to do, but quite time consuming.
Enhancing the controls is where I add or change controls around to allow for the terrain editing to be faster and easier to do. One example is cloning. For example, let's say the cursor is on block number 4 (a position spanning from and including 128 to and not including 160). It has a slope of 32H3V (very gentle). The next further terrain spot where nothing is present is at block number 7. Cloning will copy the slope data to block number 7. Doing it again with copy it to block number 8 and so on. Another enhancement is bulk copying, done in a similar way as the cloning method, except a range is involved. This is especially useful when level terrain comes in great quantity.
Numerical input is actually a menu-related functionality and really has nothing to do with terrain. However, since I don't have it and need it, I'll need to add this functionality in. Why? The Sentus Mountains is an excellent example. The whole scene takes place very high up. The starting height cannot be zero so I have raise it. Now, who wants to hold the up arrow key for not a second or two, but an hour or even longer? Also, what about the minimap? The 1:16 scale is decent at some times, but not all the time. The fix? There's 2 actually. The first is a set of predefined values (powers of 2 are usually what I'd use), or numerical input so I can use essentially anything.
Cursor? Mouse cursor? No, I'm not referring to the mouse cursor, rather, I'm referring to a simple partially transparent black square that marks the location of the terrain that is being edited without having to guess at what is being edited. This is both very easy and very fast to add.
Other fine-tuning includes things like having a number above each block that indicates the slope's height and slope steepness. This makes it easier for me to gauge how the slopes are progressing. There's probably a few others that'll come along down the lines as I develop the system further.
There's a few things you might be noticing that look a bit different. First, the debug panel has been widened. This is so I can view the slope of the current selection and heights of the edges and know what I'm changing it to. This may change if and when I add the fine-tuning effects.
The minimap isn't anything new to me actually, but it being automatically generated (at a hefty cost of up to 400 draws per frame) is new. This way, instead of actively generating the terrain and looking over it from time to time, I can view the overall shape in real time, using the menus to adjust the zoom and stuff. This is essentially miles ahead of what "The Supernatural Olympics 3.x" used.
Even the terrain itself is very detailed and impressive - the slopes are very fine in detail and resolution and even have realistic lighting effects too!
What you see here is merely more of a demonstration. The actual slopes in Ronnisa Plains rarely ever get this steep or rough. Worlds 1 and 2, though they technically use a terrain map, have only perfectly flat ground since slopes haven't been introduced to the player yet. World 3 is the first to introduce slopes. The very steep slopes are not seen until world 10, but climbing those is another story.
Date: Jan 17, 2011
Screenshot #102: For a long time, I've debated on how to align the waves - all the same X offset value, alternating X Offset values, or purely random. During the pause in development, near the end of the pause, I came up with a different idea. For reference, look at the lake below. The color is off (too bright and too blue) because I'm, yet again, changing the color for a more realistic appearance, but see how the waves for the closest part are interlaced? This is the alternating X Offset values method which was the best looking that I could come up with. That is, until I thought of a solution that I rejected about a year or so earlier.
Date: Jan 17, 2011
Screenshot #103: The solution? Have the ground texture extend closer to the scene. Why did I reject it? The pixelation effects and the seam between tiles would get quite extreme for the very close stuff. Lake Keveran isn't all that bad, with a 4x scale up, but there are some worlds, such as Keveran Reef, where this pixelation will get quite extreme. Take an image that's 128x128 or some fairly small size like that and scale it up to 1024x1024, 8 times the original size. There's no need to zoom in - even at 1x size, it's quite easy to see the pixelation effects. The seams, however, are quite bad and, being 2D, there's really not much I can do about this. 3D games actually do this when the camera is very close to a texture (try it yourself - not all games, especially older ones, do this though). The clouds use it and have used it pretty much ever since I first made them, but you otherwise don't notice it because the contrast is so low. The water is a different subject - the contrast is quite high which makes the pixelation easy to see.
You might be thinking that, because the ground is now being used, the fade effect is gone. For now it is, but it will still be present. I just need to modify the drawing function that handles the drawing of water. Making this change to this method also has a hidden bonus - the opacity can vary not stricly by height, but also by distance, providing an even more realistic effect.
I'm still debating on how to approach this problem, but since I've seen it, I'm leaning toward using this method instead of several waves. Because the ground has 96 dedicated channels and the waves require scenery, this opens up the possibility of more detail in Lake Keveran as well.
Before making this change, the game's story got rewritten, mainly to improve the quality and increase the chances of an E rating as opposed to E10+.
Date: Jan 19, 2011
Screenshot #104: Still struggling to figure out the base color for the water, I thought of a solution, as explained earlier. I use simulation screenshots for many things, not necessarily to get a sense on what the world's scenery will look like, or how the game will feel, rather, there are also worthy productive uses. This is one such case where "why didn't I think of that earlier" is true. In revisions 5 and 6 (this is actually the 7th), I used the sky to help gauge how the water will look. Apparently, this method didn't work very well. After a bit, and 5 hours worth of worthless work, I needed a redo. This is about when I thought of using Lake Keveran for a simulation screenshot. Lake Keveran has a quite a variety of colors (not a big variety though), and also the sky. The screenshot was taken from the engine itself. The only change I made to it was to make the part where the water is to be completely transparent. This will allow me to fiddle around with the texture and get a close approximation as to what the end result will actually look like.
Why use a simulation screenshot instead of the game engine? There are several reasons. First, each channel for water will require 6 draws and Lake Keveran uses 60 channels (meaning 360 draws). Why so many draws per channel? I'll need 4 draws just to set the hue, saturation, and value (which is what each platform requires). The other 2 come from the lighting and sun reflection effects (these could be combined into 1 though). This system would forbid the use of transparency needed for the special effect when close to the water, as demonstrated in Nodera Ice Shelf a few dozen screenshots back. However, it would work for quickly fine-tuning the color of the water. It does come with a catch though, a bad one. What is it? I have to spend 5 hours repeatedly scaling the lighting and sun reflection layers just to even start the test (or, I could I have a select few or even just a single done). I'd also have to add in extra scenery elements to account for the 5 images that are being used for each channel. Using the simulation screenshot, however, is pretty much just as good and I don't have to make any big changes to the loading of the world.
In the background is the Excel spreadsheet I use to process the 96 (!) ground layers needed for the water. This may have been covered before, but the spreadsheet since that time has been updated considerably. What's with the orange highlights? This indicates to me that I need to tile the base image vertically since the vertical offset plus the span needed will go off the edge of the image (and 1 pixel is all it takes). From design changes, to account for the upscaling used with the water texture, and various other enhancements to accelerate the rather boring workflow of doing this (it's the one thing I was rejecting 12-channel for).
From the recent video (see directly above) and a search on Google Images, I figured out that, instead of matching the same hue and saturation for the sky, I needed the same hue and a somewhat reduced saturation. Not a 50% saturation, but 40% (giving the water a grayer-looking appearance). This reduced saturation significantly helped. The end result is actually a combination of all the previous revisions.
Date: Jan 19, 2011
Screenshot #105: Spending yet another 5 total hours' worth of boring work to repeatedly scale the layers (since I have no known way to automate it (If I did, I'd set up a 30-channel system real quick.) and it's too complicated for me to program (the scaling down of noninteger ratios (X:1 - X must be an integer))). I got the finished version of the texture and this is what it looks like in the game engine. Here, it looks like the water is refreshing and crystal clear, at least to me (I'm rarely around large amounts of water.). The only thing not updated in this is that of the waves in the foreground.
Date: Jan 22, 2011
Screenshot #106: As you're browsing through the more than 40 configuration settings, chances are, you'll see an option that has a calculator icon right after the option's name. This means that numerical input is present. There are actually 6 types of input used in Platform Masters, 2 of which are visible in this screenshot. Radio buttons (rare), checkboxes (fairly rare), lists (very common, shown here), sliders (neither common nor rare), numerical input (somewhat common, shown here (though not active)), and textual input (very rare) are the 6 types of input used in Platform Masters.
Radio buttons are selected by simply moving the arrow cursor to it and pressing the selection button (the keyboard button you've assigned for making selections, enter by default).
Checkboxes are activated and deactivated in the same way radio buttons are.
Lists are noted by a series of 3 radio buttons after the option title, and they involve a list of predefined values as shown in this screenshot. They are used to help you gauge what effect each option has so that way finer adjustments can be made, if possible. They are also used when the conditions I've set for radio buttons are not met. Using lists is done the same way as selecting submenus within the menus.
Sliders involve a 1x1 platform that "slides" along 2 end points. To use a slider, first, move the arrow cursor to the option that contains it and press the selection button to activate it. Now, press and hold left or right to move the slider left or right. Pressing the selection button again will confirm the setting. Pressing the cancel button (the keyboard button you've assigned for canceling selections, backspace by default) causes the slider to return to its original value, as if nothing happened.
Numerical input involves manipulating the individual digits manually, used primarily when there is a very wide possibility of choices where a mere slider won't be enough (care to hold right for several hours on end?). To adjust a value, first, move the arrow cursor to the option that contains it, of which has a calculator icon following, and press the selection button to activate it. The active digit will blink repeatedly to indicate which digit is selected - the others remain unlit. Press left or right to move between the digits and up or down to adjust the value of the digits, which may affect digits on the left. Press the selection button to confirm the value or the cancel button to undo any changes.
Textual input, noted by a keyboard icon, involves selecting characters from a 14x7 character grid to create a string. This is used for file name inputs for saving your game and probably other uses I can't think of at the moment. To create a string, first, select the option where textual input is required. Now, move the cursor between the characters using up, down, left, or right to select them. Characters in red cannot be selected either due to maxing the string's pixel width (640 pixels maximum), character count (100 characters maximum), or the character or button cannot be used for the given situation. Press the selection button to add that character to the string. The cancel button or the pencil-erasing-something button in the grid deletes the rightmost character. The button with the green checkmark on it confirms the string. The button with the red X on it cancels the textual input, restoring the original string (this will also prevent the new file from being saved).
This is the beginning stages of what I have for numerical input and it gives a very good idea on what a large portion of the options will have - lists combined with numerical input with the numerical input being marked as "custom". If you look closely, you can see the decimal point present in this particular value indicating that the setting can be adjusted to 2 decimal places of precision, an amount so slight that you'll hardly even notice it, if at all. This gives great freedom to the player that most other games don't offer. Afterall, given the range stated in the menu help, there are 546,034 possible choices, over a half of a million. Holding right on a slider, changing 30 times a second by default means having hold right for a little over 5 hours just to go from one extreme to another. This is why I've added numerical input. What takes 5 hours with a slider can take 5 to 15 seconds with numerical input, even if there are 10 digits to manipulate, the maximum allowed.
Date: Jan 22, 2011
Screenshot #107: Here's a somewhat different case. Although the "Set minimap zoom" option has numerical input present, numerical input only applies if that option directly sets the value by using it like the above option does. Did you notice the comma in the number? Due to worlds like Sentus Mountains or Mount Sentusia, the starting height could very well be over 100,000 so 6 digits are needed.
Any time you're unsure what an option does, read the menu help description. The menu help description not only explains what the option does, it also explains the meaning of the value and what effect it has. It explains the latter 2 parts in plain English too (at least, as much as possible).
This screenshot was taken at a time before numerical input was fully functional, but taken before that so it's possible to get an idea on what it was like when first added.
Date: Jan 23, 2011
Screenshot #108: With numerical input now fully functional, as shown in the video, this is the end result on what the system is like. All digits are in their "unlit" state (which boosts contrast) unless actively modifying the value and the digit is selected for modification. In that case, they blink instead. This makes it much easier to gauge which digit pressing left and right will update and also to read the full value.
Date: Jan 23, 2011
Screenshot #109: With everything now ready to go, aside from a few minor bugs needing to be fixed (class 2 being the worst, quite minor), the main, actual terrain creation can begin. After the scenery, this is the time where great progress is being made. Unlike the scenery, the terrain is much, much less likely to be needing redos and the like.
The basic design for editing terrain involves 3 parts. The first is the debug panel. "CurrentBlock" (later seen as "Block ID") indicates which exact block is being selected, for modification. Because I also reference it during normal play, to pinpoint problem spots, I moved it onto the far left column. This has already been used to fix a problem, such as the case with block 65,535. Block 65,535 was being skipped unexpectedly and I found the cause to be due to a typo in the code (I typed a 5 instead of a 6, forcing the maximum to be 65,534 instead (There are 65,536 total blocks, spanning from and including 0 to and including 65,535.).).
The far right column is what I reference frequently when modifying the terrain. "Completion" is based on how much completion I've made based on the location of the cursor and for the selected world - this should be otherwise self-explanatory. "Mile" is a reference to the position in the terrain the cursor is at. Due to various "visions" I get, I need to know where exactly this is on the terrain so I can match them, as my design document explains. Yes, 65,536 blocks really is over 58 1/4 miles. This location I'm editing is actually around halfway between levels 2 and 3. The two "height" values refer to the height at the left side of that block and the height at the right side. It's very important to know what the slope I'm using is as well, so I have that present. It's in the middle because the slope determines the height. The left height plus the slope equals the right height. "32H004V Up" means that, the terrain is 4 CU (the "004V") higher (the "up") on the right than on the left, changing over a 32 CU span (the "32H"). "32H014V Down" is similar, except the right side is 14 CU lower than the left. There's also "Level" for when the height is the same across the entire block. "Null" is used for this part of the terrain hasn't been processed yet or it's semi-erased, to allow for cloning. "No ground here" means that, by falling into this area, you won't be able to get out. Thus, it's used for worlds that have bottomless pits, like Keveran Forest, and about half of the Sentus Mountains.
The second area referenced is the minimap. This lets me gauge the shape of the terrain beyond what I see on the screen. Adjusting the zoom allows me to see more or less of the terrain, sacrificing the ability to gauge overall height changes more easily. It appears that 12:1 zoom (12 pixels on the actual terrain is 1 pixel on the minimap) is optimal for Ronnisa Plains because of the often hilly terrain that's present.
The third area is, obviously, the terrain itself. The black, transparent square visually marks which block of the terrain will be adjusted when I use the up and down arrow keys to adjust the slope. The block the highlight is marking is indeed block number 3782.
To semi-erase the terrain, I first press the N key on the block I want to modify, move to the end point and press the N key again to semi-erase blocks in bulk. To make the terrain disappear completely (fully erased), I use the same method used for semi-erasing, only using the backspace key instead.
With this setup I have, I got worlds 1, 2, 6, 15, almost all of 8, and about 1/3 of 10 finished in barely 10 minutes. Worlds 1 and 2 are perfectly flat all the way through (slopes are first seen in world 3). Worlds 6 and 15 have no solid ground below (the only solid ground is that of the platforms). World 8 has a tiny part of it that goes above the fallout point. World 10 has about 1/3 of the terrain being nothing and the other 2/3 being of very steep slopes that are often impossible climb without a very high acceleration. I made some progress in worlds 4, 5, 9, and 10 (10 indirectly). World 3 is 5 7/9% complete as well. All of this took barely 100 minutes to do and that includes time to walk and run around on the terrain, to make sure there won't be problems, and also some fiddling around (like I do in other games). Time spent fixing bugs or making other enhancements unrelated to actual terrain editing doesn't count. You can see just how fast this process actually is given all this.
Date: Jan 28, 2011
Screenshot #110: I spent about 2 days redoing every single one of the game's objects (except the character and enclosed fluids (water, mud, and lava enclosed by platforms)). Some of the objects that I didn't have before are now included. As a consequence, the objects look far better than they did and some even have animation, such as springs and fires. Several other changes were made, some of which were planned or thought of several months beforehand. Instead of 4 colors of springs, there are now 5 - a white spring is added. Instead of 5 colors of hearts, there's now 6 and the amount of HP they restore have been increased. That is, instead of blue hearts restoring 5 HP, they restore 10. Red hearts restore 100 HP instead of 50. Pink hearts now fully restore HP and white hearts restore 200 HP. Upon seeing this screenshot, I realized that I forgot to enhance the lighting on the springs. I've already got the gradient made, due to my book's front cover, so this is generally a quick fix.
In addition to enhancing images, I also fixed several bugs that I was aware of, many of which I've known about for several months, one of which for over a year. Remember the class 3 bug where, by holding left, you could stand in mid-air when next to a platform? How about the case where, by holding right, a bounce would occur in mid-fall when it normally shouldn't have (this bug is due to the same cause as the previous). There was also the case with the one-pixel offset with the scenery. This occurred whenever relative positions shifted from being positive to negative. 0.99 and -0.99, when converted to an integer are both considered as 0 even though the range is double what it normally would be. This class 0 bug (the least severe of all bugs) is one I've known about for about a year. I also optimized my code a bit too. Originally, when much beyond 500,000 CU from the starting point to the left or right, CPU usage would get quite noticeable and high. Now, I have to go beyond 5 million CU before I even reach 1/3 of the previous effect (estimated) though only 2,097,152 CU (65,536 blocks) is the upper limit for levels (tutorial levels typically hover around 1.95 million CU in, the furthest). There are a few other bugs that I fixed.
Remember in screenshots mentioned earlier involving the water color where I mentioned of having the opacity of the water based on distance rather than only height? This is the consequence to this. The waves for the back end of the ice burg are not visible because I haven't added them in yet. The foreground waves have yet to be redone though.
As this screenshot shows, the spring is in an "extended" form, rather than the normal "compressed" state. This makes levels contain more action than before and it also improves the overall game play experience, to some extent.
If you look at the bottom part of the image where the water is, it's a bit easier to see the ice burg in the distance through this part than it is for the part of the water that goes right up to the ice burg. As both the height and distance of the layer increase, the opacity increases.