#opark forest

[view-from-a-warm-place]

040 // I am not dead. Just lazy.

Ed.Note: I am not going to lie to you. I recently started a Twitter account and it has been taking up a lot of my time and it is easier to maintain than Tumblr, and I became entirely sidetracked with it. I had actually written this post in December of last year, then saved it as a draft intending to get more images ready for it. 

I forgot and only remembered now, so here they are! Again, sorry for the long delay. u_u;

So I have spent the past few months working alternatingly on a project for/with one of my fantastic girlfriends, making art slides for her project called "Skeleton Planet." These slides have been fun to do, with the mixed challenge/handicap of a four-colour monochrome palette and fixed image size. Here are some of them:

Admittedly, these art pieces have not taken up too much of my time in contrast to the length of time it has been since my last update. The other work I have been alternating back and forth with have been my original project (derailed months ago by the stupid jaywalking game; both still incomplete), a grid maker tool that should help me lay out doodles for landscapes (finished!) and pixel dailies submissions that tend to take a day or two to make (I will show you those later~).

The work I have done on the original project has centered mainly around a complex set piece in an even larger tile-based map for Opark Forest. The set piece has involved a great deal of animation for a number of materials I have never had to animate (properly) before, namely a canvas tent (in a breezy spot) and leaves on large trees (also in that windy location), and while it has required no new elements in terms of my engine (though a few have required revision), the map editor has so far been updated several times to correct flaws and improve its useability. The creation of the animated elements has been painstaking, though rewarding and I will reveal those later.

Matan kids on an incomplete fort!

Besides that, much of my time has gone to laying tiles and trying to make them look good next to one another. I have made a quick time-lapse thing using ASEprite to show the evolution of a part of this current map, although it is not particularly impressive.

Mazarre Ridge: Work-In-Progress. There are some colour palette issues in this .gif related to ASEprite’s palette quantizing that I could not avoid and sorry. :s

Now that you have seen it, maybe you would like to know a little about it? This is the 'Mazarre Ridge' area of Opark Forest. It is a rather unstable formation at the edge of Omalla continent's central plains that did not collapse (as the rest of the plains did) during the initial tectonic conditioning of the planet hundreds of years ago. The ridge is rocky and covered in a thin layer of soil created by the leaves and needles of the shrubs and large conifers the grow on top of it. The soil is quite good once you move away from the ridge where the wind prevents it from accumulating for long. There is a large lake not too far away, separating the ridge from the Matan Terraforming Platform. The terrain below the ridge is riddled with narrow caves and swallowholes that join and link together in Nigran Cavern beneath, and these holes are the primary reason why the road connecting Matan to the platform take the much longer route to the east of the lake, and why the area has only a narrow and seldom-used hiking trail connecting it to the town. The wind and steepness do not recommend it, either. Six years ago, Gustek Radomr constructed a small shack on one of the few stable outcroppings on the edge of the ridge for Celia Roscoe to play in; since then, Celia has expanded it slightly and maintains it to this day. It is quite difficult to reach.

Seedbird, in the woods on Mazarre Ridge.

Anyway, that is all for this update. I will try and be more diligent about adding more to this weblog but realistically, who knows-- I am not good at publicity. u_u;

I have made some new visual effects in the past couple of days. I hope to have a post ready soon, because I realize that it has been entirely too long. Here is a preview for you: a sort of shattered-funhouse-mirror effect for uneven reflective things!

Garbling a reflection was both harder and easier than I thought it would be.

Incidentally, if you were looking forward to more stupid-jaywalking-game updates, they will slow somewhat, but I would like to continue that project in the future. I just did not want to leave my main project on the back burner for any longer, so I picked it up again. The most recent thing I worked on for SJG was a code module that allowed me to make road layouts more easily from sets of locations and road-width data, rather than having to work out the carriageways on paper. The next element is other pedestrians, I think!

That is all for now! Talk to you next time! :y

[view-from-a-warm-place]

033 // ~ Wow! It’s Made! No.2: “A Tree In 2,023 Steps!”

I captured this from the redo stack of a tree I drew recently as a technique study, and I thought that I might also post a capture of the creation of it. I hope you find this kind of thing as mesmerizing as I do.

Start to finish, it took maybe three hours to do. Slow, but I am becoming better at it, I think.

As if you had missed it, the name is a reference to the plentiful and very useful, if slightly frustrating, tutorial images available online that offer you a lesson on drawing something in six or eight steps, which tend to leave out some critical leap or structure that tells you exactly how to get the details the way you need them (it tends to be around the fourth or fifth). Instead of that, I would like to offer you the complete process, directly from my edit history, from vacant workspace to signed product. Confounding step? Miss something? Need a bit of interpolation? Go back to the exact moment where it happened and study the result in this fun, 108-second animated image, uncluttered by explanations, descriptions, or frame numbers! Tell your friends!

The tree has ten colours, plus a transparency value. 1,971 of the GIF's 2,023 frames are of its construction, and the remainder are just me being fancy, plus a bit of LICEcap being a nuisance at the end.

Anyway, this has been a good week for neither my game nor my health, so I am afraid there is not much to see here. Hopefully, there will be more to see next time.

Until then!

[view-from-a-warm-place]

035 // ~ Wow! It’s Made! No.3: “Tree Super Redux”

The tree-drawing-visualization thing seems to be popular right now, so here are some more I made just today! They are not quite as articulate as the usual ones, but should do well for near-backgrounds and views through windows.

The first ‘lumpy’ tree is more of an artistic experiment than a legitimate game asset. I doodled a couple of leaves in with the second set and they are really there more as a mascot than anything. :1

- The first tree is drawn in 125 steps. - The second tree is drawn in 159 steps. - The third tree is drawn in 172 steps. - The last tree is drawn in 238 steps (+2 where I relocate it in the workspace). - All of the trees use five colours, except for the first which has seven, plus a transparency value.

I drew this as another sort of design study, mainly to have a few samples to put into a map to see if they look any good. I will post the results of that experiment later.

I hope thse low-fidelity trees amuse you! They were also fun to draw! :D

Incidentally, I find I have collected quite a set of GIF compression solutions to make up for ASEprite's unfortunate GIF-saving shortfalls. As before, I had to make some revisions to the original LICEcap capture (934kB), and when I went to save the altered version out with ASEprite, the result was 22.4MB! This is not really so horrible considering its size and length of the thing but is hardly internet-friendly and shows some considerable bit of a space for improvement, algorithm-wise. Anyway, I ran it through a sketchy online compression tool (a new one this time; the last one broke!) and got this 1,045kB lossless version back, and hooray!

Anyway, that is that for now, I will also try to put out another post this week, since this one is not really that interesting, game-development-wise.

Please look forward to it~ :D

[view-from-a-warm-place]

022 // Loose Images No.6: “The Hand of Jeremiah” and Celia Roscoe.

Welp, I did not get as much ready as I had hoped to. I spent a lot of this week smashing my head against a mountain of old code from years ago that I meant to update and never did, or that I did not know needed updating until I actually dusted it off again and subsequently felt compelled to update it. Arduous stuff!

Celia is actually animated to climb the tree, and she does quite elegantly! But! She is not yet animated to sit down properly, and my myriad neuroses will not permit me to send a screencapture out with missing frames. No, no, no.

Therefore, in the interim, you get this: Celia goofin’ off in the branches (she’ll actually do more next time, I swear!) and a somewhat colourful expository moment about the tree in the graphic, below.

Enjoy! :y

This big tree is a member of the species Corymbia terminalis-III salite; a hardwood that likes salty, rocky soil and which has been growing on that spot since before the Erusa Skyfall disaster. The girl sitting in it is Celia Roscoe, who you know. This tree is named "The Hand of Jeremiah." Celia named it that. Celia has only told her mother who 'Jeremiah' is and it's a secret.

C. terminalis-3 salite trees absorb salts in the soil and minerals they grow through and inter it in their thick, scab-like bark. The trees regularly shed their bark to eliminate excess salt, and, normally, the wind and rain will carry the discarded salt-laden wood off before it crumbles and re-salinizes the soil. 'Jeremiah’ is in the shelter of the Matan Escarpment, though, and the bark does not travel very far before it decomposes, and that is why this particular tree has such a broad space around it for it to thrive in. Others like it can be found growing in oceanfront groves and scattered across salty alluvial plains. The species of tree is now fairly rare on Luan-II, as non-seaside plants tend to die out as the salt in the soil is depleted-- a task they were specifically bred and engineered to perform in biocycle-terraforming situations.

A thick pseudolignotuberous root crown can support several trunks and stems per plant, sending thick, woody runners out from an original trunk and growing thick, appendage-like roots that may eventually branch into new, connected trees. The result is a plant with a thick, central trunk and several heavy, insect-like 'legs' splaying out in all directions, sprouting smaller trees of their own. These legs are where the species gets its nickname: Roga's "Walking" Corymbia.

Salite bark can be ground and used as a pretty-okay seasoning, but you really have to like salt. It tastes terrible on its own.

[view-from-a-warm-place]

019 // Technical Notes, No.1: Lots to say about a map editor.

Part I: Introduction and Burncards

This week, I would like to take a moment and talk about my map editor. Sorry it was a bit late but if you like essays, you should not be disappointed!

n.b.: There will be a lot of talking and visitors will be forgiven for skipping the text and just looking at the images.

When I started this project, I decided that I would like to try making maps in the old way, by creating a sequence of graphic tiles and arranging them into grids of numbers that corresponded to specific ones. Naturally, putting the tiles in sequence manually (in raw text) would be tedious, error-prone, extremely time-consuming, and, ultimately, a profoundly frustrating and dissatisfying ordeal, so I elected to create a map editor for this purpose instead. This editor has since become a tool that does considerably more than just place tiles in a grid and convert graphic references into numbers and back again.

My editor, which has been under continuous development since 2013, displaying a very basic map used to test and edit new map features and effects. It operates mainly using the Pygame (interface) and ConfigParser (data handling) modules.

* Again, be forewarned that this is long! But there are pictures to reward you. Kind of.

When I began, I had very little idea of how complex each map was liable to become, and so I began work on the editor with the idea of keeping the software as flexible and extensible as possible. Unfortunately, when I began, I also had exactly no idea of how to create working software in Python, and the result was a kind of mash of functions and reinvented-wheels and features which could have been created in any number of better ways. For instance, as I mentioned in my post No.005, I only recently learned about, and how to use, the Tkinter module, and previously all of my prompts and inputs had been done using modules I made myself. I am very happy with these modules. But creating them took days I probably could have put into artwork or mapbuilding. Again, there is no disappointment, since I learned much about Pygame in the process, and my editor has a very personal, if slightly defective, character to it. Plus, it is easier to add new functions since I understand exactly mostly how it was made!

Probably the most elaborate element of the editor to work out was sorting out how to have it save and load data, but first I will bore you with a little background on the data itself..

The tile "chart" -- the sequence of numbers that describes where each tile goes -- was easy, but as you have seen, there is far more to each map than just the tiles. There are several types of special effect, there are blocking zones, there are interactable objects and sprites, there are moving background objects and objects whose appearance and behaviour changes depending on where you are on the map, and all of these elements have their own parameters and data that needs to be stored, and restored, during the editing process. To make matters more complicated, most of these object types have their own specific modules, and their age and quality changes a lot between the oldest ones (which include effects like blinking pixels and the sunbeam effects discussed in post No.016) and modules implemented as recently as last month (the simple animated sprites in post Nos.009 and 010). Although all of the modules work when I test them, the nomenclature they use-- the format of the data they use to generate and time effects-- is, if you will forgive the term, all over the map. (:y)

The data stored in a bland text file like this..

..becomes the lively (if somewhat strange-looking) foliage you see in here!

I have at many points been tempted to go back and revise the input structures of the oldest and least-comprehensible modules, but have every time decided not to, for two reasons: one is because they work and I find myself busy enough to leave well enough alone, and the other is because changing the data structure of these older modules would require that I go through every existing map that uses any updated module and revise the data it has recorded to reflect the new design. Which is super-de-duper tedious and exposes me to only a kabillion points of failure and only improves the look, rather than function, of the data as it is recorded in a file nobody besides myself is ever liable to see. And! There is a good chance that, later on in my planless, perhaps endless, development cycle, I will decide that the new format also sucks and that I want to change it again. No, no, no.

"Do how do you keep your data organized, then, if everything is such a mess??" I hear you shout. Well, that is a good question for which I have two solutions: one is that I keep pretty okay comments in the modules themselves (some of the older ones, not so much) which allow me to simply open an effect's module and look up how to supply data for each argument, and in what format, and the other, which is a large, single text file that gives a sample for a specific module and lists off what each element in that sample is for. The sample is always functional, so I can copy and paste it into the map's data file and simply revise the values and delete the copied descriptions when everything is in place! (Another problem with revising old data structures is that I would have to update all of my documentation, as well, and although this is by far the least taxing element of the job compared to updating old data and subsequent debugging, it is just another time-consuming thing I would have to dedicate time to doing. And I would really rather work on content than play with argument sequences. <_<;)

Anyway, at the end of the day, all of the effects and sprite data for every map is stored as plain text in a regular text file where I can view it, alter and adjust it, and repair (and create) problems manually; the editor does not handle every element of map design and there are a few things I can only revise by intervening directly in the map file, and that is fine because I would rather not spend those additional hours creating elements in the editor just to modify an effect that I use only rarely. But I still need to load and save those values, and what makes this complicated is the way Python handles data. I use the native ConfigParser module to load text data into the editor, and the data, when it arrives, arrives entirely as text string objects. This is fine for data that I do not need or want to edit using the software editor-- these elements can be preserved as strings in a block of 'options' (the name of a data element saved in a ConfigParser 'section') and 'values' (the data itself), then saved out verbatim when the work is done, because the editor does not need to understand the content, it only needs to remember it. Editable values are much more sophisticated because they have to be converted from strings to whatever their intended format should be, then put into a place where the editor can access and revise it. For tiles, this is easy: all of the tiles are laid out in a 2D array (actually a list of lists) and changing it is as easy as looking up the correct coordinates, then changing the value(s) stored there. Things like sprites and effect zones and moving background images are considerably harder, since, unlike a tile, each object will have more than just a single number to describe it..

Consider the example of a map prop I call a "Burncard." The name comes from an older map element that the idea is derived from, a "Postcard." Postcards are simple moving background (and foreground) objects whose location varies independently of the map, usually varying with the location of the player (actually, the center of the player's view of the map). With Postcards, I can add parallax effects and background objects and collections of graphics like clouds and mountains (as seen in post No.017) without too much fuss. Postcards, though, are still fairly complex objects and require some processing power to maintain as long as they appear on screen (many are not rendered when the player "isn't looking," though, and that was not so easy to pull off), and if the Postcard is not intended to move independently from the map (it has no parallax-adjusted motion), then to use a Postcard would be wasteful. Enter the Burncard: a Postcard which is 'burned' to the map during its initial rendering! Because tiles are all drawn to a single surface on load (the player then views a portion of this surface) rather than redrawn every single frame, I can simply throw these static props in on top of the tiles instead of redrawing them every frame! This way, the software has less to keep track of while the game is running, at the expense of an only trivially prolonged load-phase when the graphics are 'burnt' to the tile layers!

What makes Burncards more complicated is the fact that they have a number of attributes besides the address of their source files and coordinates for where they ought to be drawn on the map: they can have colour gels, they may be scaled or flipped, many are applied to different graphic layers, and they often have to be placed in a specific order when multiple Burncards overlaid atop eachother on the same layer. And all of that data has to be stored and manipulated, then converted to text data and pushed out into a file during save, and restored from that text data when editing resumes or the game parses the file for use. Burncards are pretty complex! To handle all these different parameters, Burncards are edited as "objects," a sort of programmatic Rolodex card created from a template and put into a collection tracked by the editor. When I load, the text data is converted from strings into whatever data type they look most like to Python (I made a tool to help with this using ast.literal_eval and used it to extend SafeConfigParser, for those of you in-the-know) and puts them into their appropriate attribute slots in a Burncard object according to the sequence in which the parameters are listed or using specifically-named elements in the data, and puts all those objects into a dictionary I can flip through and edit as needed. When the work is done, the editor goes through that entire dictionary, object-by-object, and converts the attributes back into text strings according to their content, stacks them up in the correct sequences, and puts all that data into a long, carefully-formatted block of text that ConfigParser can save out to a file. It's really handy! But if a single character is mislaid, I have to rummage through it to see what went wrong...

The lamp post in this screen capture is a Burncard! So is the log, the tree trunk at left, the bramble at the base of the lamp and the sapling just to the right across the trail, and the grass clumps in the fore- and background. Let’s see what the lamp looks like in the editor..

Here it is, ready to be changed! The background scenery is actually a Postcard, which the editor does not handle.

This is what it looks like to have the lamp selected, and if I click the "CURRENT TILE" sample..

..I come to this pane! Making this interface was a pain, let me tell you, and there are a few bits that do not quite function as they ought to, but I learned an awful lot in the attempt, and so far, it does everything I *need* it to..

..At the end of the day, the whole thing is saved out to a simple line of text. Here it is! (This line shows just the lamp. Notice how it appears twice on this map!)

For ever editable object, I have created some kind of small interface and data processing system, and although I would have certainly changed some things if I knew when I started what I know now, I am still content with how it has gone so far. Which is good because the damn this has probably taken longer to make than the game-proper. >:1

All said, this editor has delivered some really great effects and saved a lot of time, even if I have had to invest a lot of energy in it just to get this far, and even if there is still much work that yet awaits me.

It's a good editor, for something that I made myself without knowing at all what I was doing! It may not produce effects as complex as Unreal Editor but I happen to think it's much more elegant. (It also at least attempts to save my work when it crashes!)

Anyhow, this is all far too much text for a weekly post, so I will leave things there for now. Thank you for taking an interest in my editor, and for reading all the way to the end! :D

See you next week!

[view-from-a-warm-place]

016 // Technical Notes, No.0: NumPy and Visual Effects

“Experience is something you get just after you need it.”

So I promised you a post or two ago that I would talk about some of the technical challenges and errors and misdirection I have encountered in the course of my project so far. I will try to honour that promise now!

NumPy is a set of functions and classes that mediate code written in Python, which is fairly slow in terms of processing but is easier to learn and use, with a set of its own functions written in C, which are already compiled in a way that machines can understand but are more complex and harder to write (at least as a beginner). For small data sets (containing dozens or hundreds of elements; dialogue trees, for instance, or character locations), the difference this represents is usually trivial; the time it takes to process the data in Python is not slower on an order of magnitude that humans usually notice. When the data set is large, though (thousands or millions of elements; pixel data in a graphic bitmap, in this case), it becomes a bigger deal, especially if that function runs every frame or so. (I wish I could explain this better but everything I know is self-learned and I am not a very good teacher. :/)

The waterfalls and sunbeams you may have seen here and there in Nigran Cavern and outside the shuttle wreck in Opark Forest are two places where I have used NumPy to generate graphics on-the-spot using code, rather than raw images. These elements are generated and updated entirely in code, rather than from any sort of base image or animation, and the way their geometry changes is entirely random*. This is useful for a few reasons, primarily because it frees me from having to draw and make unique every waterfall and sunbeam in every situation, and because it liberates disk space that those graphics would have otherwise taken up. The price I pay is that the software has to both generate and continuously revise the graphic elements on-the-spot, though, in addition to displaying them, which requires processing power beyond simply flipping through pre-drawn frames, and as stated, Python and Pygame are a bit stunted in this area of information processing. NumPy really helps in this area, effectively having the bitmap data array processing carried out directly by the computer hardware (rather than by way of Python’s bytecode interpreter) so that Python does not have to try, but in so doing creates new and additional problems as NumPy and Pygame do not always play nicely together.

Pygame is equipped with a module called surfarray which allows the software to directly intervene in a bitmap’s pixels; it could be a very useful tool, but the problem is that it is buggy and Pygame has not been officially supported for years. The pixels2d and pixels3d functions, which are the ones relevant to my code, create “memory leaks,” which are basically blocks of memory that the software reserves, fiddles around inside of, but then forgets to release for some reason** when it finishes with it. It does this every time I call it, which can be two or three times per frame, depending on what the player is looking at. If the software runs at thirty frames per second, it can accumulate thousands of useless bitmaps every minute, which stick around in memory until either the program closes (hopefully) or until the system runs out of memory and crashes. I found three obvious solutions: try to correct the problem directly by debugging Pygame’s surfarray code, which I did not know how to do since it was partially in C (which I also do not know much about); I could use the similar surfarray.pixels#d functions, which do the same thing but take some time to make copies of the bitmap arrays for you to edit (rather than editing pixel data in-place); or I could abandon the surfarray functions entirely and do something else, which partially became my solution.

What I ended up doing was leaving the pixels#d functions alone, but trying out the thankfully-not-buggy pixels_alpha function, which works solely with an image’s transparency channel. It turns out that bumping opacity around is more than enough to create a decent-looking waterfall (water is all the same colour anyway, right?) without worrying too much, and since the function avoided the problems its companions fell victim to, I ended up going with that. Admittedly, there remain issues: Pygame can only handle the effect element as 32-bit surfaces (wherein each pixel has a value for a red, green, blue, and opacity channel) even though the only channel that actually bears any contrast is the opacity value (the red, green, and blue values are identical for all pixels), which means that 24 bits of data on each pixel could be effectively described by a single value for the entire image (which is a bunch of wasted memory), for one; also, pixels_alpha works without hazard on my computer and with my version of Pygame, but it may not be so cooperative on other systems– a degree of compatibility I would not worry about if the library it came from was more reliable.

The sunbeams in Opark and in the Nigran Cavern Entryway are generated in a similar way.

As I said in post 014 though, I do not really look down on them for their technical ‘inadequacies’, because they seem pleasant to look at and are not excessively demanding processor-wise. The entire project remains as it was when I began: experimental, and I think that this aspect of it makes it especially enjoyable to develop. Also, what else could you call something created by someone who started with no idea of what they were doing?

Anyway, that is all for this week’s post. Depending on how well map development goes between now and the next entry, I may have some images for you next week, or maybe I might go over some tileset stuff. Post a reply to this entry if you have some preference one way or the other, or maybe for a third thing! :D

See you next week~

* In the extent that the meta-random values Python's native `random` library can be "entirely random."

** As near as I can figure, Python’s garbage collection never clears them out because they create some internal reference that they never got around to breaking when the pixels#d output array is ‘orphaned’. But I what I do not know about Pygame could fill a wharf’s worth of warehouses. :/

[view-from-a-warm-place]

nb00 // Delayed, due to illness.

I know that I had promised you some sweet caves this week but I have found myself in the unenviable position of being both busy with “life” (so-called) as well as finding myself a tad infirm.

Taken together, little fun has been had.

As a way of saying "I’m sorry,” here is a screen capture from the Opark Forest Wreck Site featuring some of the new flora featured recently. I redid the sky and the midground, and some other things. There are several updates and revisions compared to the version in the Tumblr-theme-title-backdrop version posted at the top of the main page (and possibly this page as well).

I had intended to save this for a bit later, but I had intended to do a lot of other things which did not happen.

Anyway, here is my apology; I hope you will find it acceptable:

Next week will be better. Next week is always better.

[view-from-a-warm-place]

027 // Distractions IV: ‘Descenta Vertiport' (original)

I have been trying to do more work on my game lately, but have found myself with a case of creative block to do with the final layout of Matan Village, probably related to the difficulties I have been having sitting down and working it out on paper. Experimenting with layouts is easier on paper for me, I find, than it is on some electronic medium, cause: unknown. In any case, this blockage has created delays for two or three weeks now and that is why you have been seeing a lot of analytics and old work revisited.

This week, my procrastination has been focused on remaking this image, drawn by me in September of 2013. I drew it using mostly hard brushes in Photoshop 9 and recall that it was not a huge effort at all.

abv: image scaled to fit width. original size: 222px sq.

The scene itself is a place out of a dream that I built on after I woke up, the uppermost landing of a very tall elevator that reaches into a miles-deep sinkhole connecting several broadly-spaced subterranean strata of a planet called 'Descenta' (among other names). This one is at the top and you can see the sky beyond it.

After rediscovering this image of it, I decided it might be gainful to try to recreate the scene as pixel art, and so far, it has worked out quite well. The new version is a bit different from the original, but it pleases me so far. I think I have learned a fair bit about dithering, which I cannot say I was super-confident with before.

I hope to finish the new version by next week, so I will post the remake then. I should also like to post a bit of worldbuildy-background-lore stuff with the finished image, too, if you like that sort of thing!

As to game-related stuff, I have some maps for the interior of the shuttle wreck in Opark Forest to post as well! They are some of the first tilesets I made for this project, so they may not be as good as Opark or Nigran Cavern and could do with an update. Please look forward to them!

See you next time! :y

[view-from-a-warm-place]

017 // Considerations II: Mountains and Clouds

So I have been working on a few old graphics and modules these past few days and decided to take a look at the way I drew a few elements in the backgrounds near the forest. This week, I will focus on the clouds and mountains visible from a few locations in and around Opark Forest..

This first image is the older of the two. It uses soft, green hills (in this view, scaled up two times) and puffy, 'dense’-style clouds. There are a few things I would like to play around with in the look of these graphics-- the hills ought to be sharpened and maybe I could add some trees to the hillsides. I should also fiddle with the colour.

The second image uses some different mountains I drew a while ago-- grey, sharp corners, barren-- that leave a different impression on the viewer in terms of distance and depth. They are also at 1x zoom so the features seem finer. The clouds are a lot ‘thinner’ and use dithered patterns instead of ‘blobbier’ geometry to make them seem airier and a bit less imposing. They are also a bit less cartoony, I think, which is neither here nor there in terms of the look of the game. I made them as a bit of an experiment, to see how a new ASEprite brush looked in various applications. Even if I decide not to use them in Opark, I expect that they will find their way into some other scene eventually.

There is also the matter of the sky, and the kind of blocky gradient I have on display there. I have been playing with using a finer, less 'steppy’ pattern for it, but have not settled on one just yet.

Between the old and new style clouds and old and new style mountains, what do you think?

[view-from-a-warm-place]

undefined

014 // Screen Capture No.2: "Welcome to Nigran Cavern!”

Better late than never! As promised, here are a few screen captures from the "Nigran Cavern” region of maps. They even have motion for you! Hot damn! :y

The first MP4-format video shows a pair of rock arches weaving between waterfalls, pouring in from the Opark countryside above. (Sorry for the graininess; I have yet to get video compression worked out in an elegant way...)

The second gif-format animation shows the vista from the mouth of Nigran Cavern as it connects to the scarp running through Opark Forest. I am not completely sold on the colouring in this view just yet, so please expect it to change at least once or twice...

In both maps, all of the sprites and static artwork you see was made in ASEprite. Animated effects like the sunbeams and waterfalls are generated on-the-spot, in code, using NumPy, which I regard for various reasons as the best mistake I probably could have made here. (I will explain why in a future post! <3)

The Nigran underground region will probably consist of six or eight maps when it is complete. I plan on putting some good stuff down there for you, too!

I have really enjoyed working on Nigran Cavern so far; I learned a lot of different ways to use a tileset (more on this in future posts), found some new ways to use old effects, and created some new effects with applications in other regions.

I will very probably get into the details of these effects later, and how they have been used, but I will save this for a follow-up post actually showing off the material itself. For now, please enjoy this completely optional and technically-questionable expository moment:

Nigran Cavern is a system of dolomite solution chambers and corridors stretching thousands of miles in all directions beneath Luan II’s Beylan region, and into other adjacent cavern networks in neighbouring regions. The caverns, like many others worldwide, were created as the GEOMATs lifted the Omalla landmass and other continents above their resting depths in Luan II’s then-shallow oceans, causing their original watertables to flow outward. Carbon and sulfur acids produced by settled organic cycles in the biosphere and introduced artificially to accelerate the creation of soils through weathering and erosion leached into the caverns through cracks in hardier rock and sinkholes and dissolved the more soluble materials beneath. Eventually, these cracks formed large underground cisterns and rivers, absorbing water from the surface watertable and from creeks flowing into ‘swallowhole’ sinkholes.

Because the underground geology of Luan II is relatively new, sophisticated patterns of stalagmites and stalactites are rarely seen-- the chambers shown, though they vary in age, are all less than four centuries old. Some features are less the result of dissolution or erosion and more the remnants of Luan II’s far more ancient lava-extrusion processes; others may have been created by seismic forces as recently as months ago. The GEOMAT terraforming process creates new and unique phenomena on each planet that undergoes it!