I am not Qu. I am merely borrowing his name. My true name would drive you all mad and usher in the end of times.
Posted in Uncategorized on September 27, 2019
Geez, the SeasonalCycleEditor UI control has well and truly gone through a it’s fair share of iterations now.
The goal here is to provide an intuitive interface for customizing the duration, magnitude and offset of seasonal temperature/fertility cycles, which themselves follow a straightforward sine curve.
The first version of this control utilized a straightforward 2D texture of a sine curve, which I figured I could stretch, tile and crop to create the cycle graph. As mentioned in a previous post, that attempt failed because frickin’ arithmetic, how does it even work, science can’t explain that.
So I scrapped the sprite-based control and made this shader-based control instead:
Technically, this is two controls: the temperature and fertility curves are rendered separately on top of one another. It’s a somewhat prettier result, but it lacks polish and isn’t exactly intuitive: 6 handles on a single surface is way too many, and if it wasn’t labelled “seasonal cycle” it’d be quite difficult to guess at it’s purpose.
Not good enough. Try again:
Better. Separating the curves was a good call. Their units (Celsius and percentage respectively) are unrelated, so sharing graph space only makes it more difficult to label the Y-axis.
Labeling the seasons was also a good call. I originally considered “Spring/Summer/Autumn/Winter”, but “Wet/Hot/Dry/Cold” are more descriptive and less tied to real-world seasons.
Also, they’re shorter. Easier to fit on the UI.
The result is still non-optimal, however. I don’t like that the hot and cold season bars overlap with the wet and dry seasons, a) because that’s not accurate (“hot” shouldn’t start as soon as “cold” ends!) and b) because it’s not how we *think* about seasons. Sure, we’re aware that in reality one fades into the other, but in our minds, the concept of spring is distinct and separate from the concept of summer.
To be maximally intuitive, a graph like this should reflect the mental model the player has of the thing being graphed.
One more try:
Much better. Still could use some tweaks, labels, and a brighter season description bar (my laptop has a very bright screen, which makes it hard to see how dark some parts of the game are until I export the screenshots to a different machine), but it’s very much getting there. I’m happy to leave it here for the moment and make progressive tweaks to the design as I push forward to 0.13.
Posted in Uncategorized on September 16, 2019
One advantage of doing multithreading for 0.12.0 was that it de-stigmatized it for me. So this week, rather than keep trying to optimize the lag I had created in the map editor, I did a thing and dumped it all on another thread.
Two other threads, actually. The erosion algorithm spits out a heightfield, which needs to be converted into vertices for rendering. Both of the erosion and the conversion are expensive functions, which is why they now both happen on other threads. I’ve become quite fond of the backbuffer pattern, in which I complete all the internal work on a backbuffer and flip it to a forebuffer copy for display and use by other parts of the program. The results are promising: not quite real-time but close enough to be workable, and the UI remains responsive throughout.
All that out of the way finally freed me up to start working on the map editor itself.
For the brushes, I needed the ability to pick a point on the 3d terrain with the cursor (okay yes, I could have just had players paint on a top-down map, but where’s the fun in that?). I’ve already done this in the game proper, of course, but remember how the in-game terrain is a) heavily optimized and b) a static, unchanging object? Yeah, the triangle-picking technique I used for that caused far too much lag on a dynamic heightfield to be viable in the map editor.
Instead, I took a different approach: ray-tracing from the cursor position to the terrain object and polling the height field for every pixel travelled. The result is nowhere near as accurate as triangle-picking, but it’s a lot faster and you’ll never be as close to the map editor terrain as you will to the in-game terrain.
And with that done, I started work on the brushes. I’ve got some simple raise/lower/flatten brushes in place, but no real UI for them yet. Still working on that part.
All things considered, this was a good week.
Posted in Uncategorized on September 4, 2019
Sorry for the radio silence everyone, I’ve been submerged in some refactoring work that, while vital to keep a codebase the size of Species workable going forward, doesn’t make for great screenshots and/or interesting blog material.
“Dear diary, today I converted ProfileOptions from a static class that reads from a flat text file to an easily expandable object contained in the Game class that writes to xml format so that World settings can be more consistently managed when loading and unloading games, and will probably have to spend a fair number of hours tomorrow refactoring all the references to it.”
Also, and I made an attempt to draw the “Seasons” UI using 2D sprites that failed miserably and set me back a week. I’m reworking it with shaders, because I’m apparently better with trigonometry than I am with basic 2D arithmetic.
That effort is going somewhat better: I have a working graph and all the data I’ll need to actually implement seasons without too much trouble.
Still to do: Map Editor brushes, Erosion Optimization, Creature Settings UI and Scrollbar control. Progress is slow, but steady.
Posted in Uncategorized on July 2, 2019
The New World UI is a mess. Let’s not sugarcoat it: clicking the “New World” button is like kicking a beehive, except instead of kicking you’re clicking and instead of being assaulted by wrathful insects hell-bent on vengeance you’re exposed to a confusing excess of numerical input spinners hell-bent on vengeance.
So, the first part of the new 4-part New World screen will be a simple Quickstart screen, designed to get you away from menu and into the game as quickly as possible. New players will still have a few of the most vital controls, but the vast majority will be offloaded to the other screens.
I’m not quite happy with the current design and am still experimenting with it, but it showcases the idea well enough.
On the left, a preview of the starting creatures. Since we have more space available than before we can make this bigger than the one on the old New World screen, but more importantly, it shows several specimens rather than just one. This makes it easier to see the difference between ‘single species’ options (‘Initialise Blank Slate’, ‘Initialise Aquatic) and more varied settings (‘Initialise Random’, ‘Initialise From Exported).
On the right, the new 3d Map Visualiser. The erosion algorithm has been built into it and it’s been hooked up to the in-game terrain, so it’s now possible to start games with eroded terrain. The erosion process looks good while it’s happening, although it’s a major performance issue. I’m still looking for a solution for that: I tried lowering the fidelity of the map visualiser and it somehow made the lag worse. So I’ll probably have to resort to multithreading again. At least I know how to do that now!
The three pop-out sliders on the right hand side are water-level, temperature and fertility, and they update in real time too. A similar UI control could come in handy for the climate settings in the main game.
Unexpected feature: if you adjust the water height while the erosion is happening, you can get a neat ‘layered’ effect to the erosion.
Posted in Uncategorized on June 14, 2019
Because I am a dope of the highest order of magnitude, I forgot to talk about one of the most important features I have planned for 0.13.0: a seasonal cycle. I plan to have the average temperature and fertility automatically fluctuate over the course of one hour simulation time (by default).
Of course, from the creatures perspective this will be less like seasons and more like glacial cycles, due to their short lifespans and rapid evolution. I’m okay with that. Creatures will be forced to continually adapt to survive, rather than simply reaching a local maxima and stagnating.
The season-cycle graph will be present on the Map Editor screen, and it will be editable, with the ability to set the magnitude, length and offset of both the temperature and fertility curves with simple click-n-drag handles. By including a separate curve for both Temperature and Fertility, the game will have a maximum of 4 distinct seasons: hot, cold, wet and dry, depending on which curve is closest to a peak at any given moment.
Long term, I plan to associate each season with in-game visual and weather effects. This might not make it into 0.13.0, though: I consider it a nice-to-have, not a priority.
Posted in Uncategorized on June 3, 2019
It’s about time I wrote one of these. I’ve been working quietly on 0.13.0 in the background for a while now, but I didn’t want to write anything solid until I was certain 0.12.0 no longer being haunted by the dreaded ArithmeticException.
0.13.0 will revolve around improving the New World screen, or at least changing it to be something more user friendly than an impenetrable wall of number spinners. Instead of one New World screen, the game will have 4: Quickstart, Creatures, World and Advanced Settings.
Quickstart will be exactly what it says on the tin. You’ll get a creature panel with the Type dropdown (Initialise Blank Slate, Initialise Random, etc), and a Map panel with the Randomise button and maybe some temperature/fertility sliders. That will make it nice and easy for new players to find their way into the game without being overwhelmed with unnecessary options.
The Creatures page will be a bit more involved than before, and will include at least a few new options for customizing your starting creatures. Not a full-scale creature editor, but a few basic adaptions for things like temperature and oxygen. This should allow you to start in a tundra without immediately killing everyone off.
Initialise Exported will also have an interface to control which creatures you want to populate the world with, and I’m considering giving Initialise Random should include the ability to page through the randomly generated creatures and choose whether to keep or discard them. Like Tinder but for Abominations of Nature.
The World page will be the centerpiece of this update, and will include a realtime 3d map editor. The player will be able to shape the worlds landmasses with raise/lower/flatten brushes, and the game will automatically apply erosion to make the result look more natural. This is where my shiny new erosion algorithm will come in handy.
I had a lot of fun working on this. The algorithm simulates rain erosion, cutting sediment out of cliffs and depositing it in catchments, creating ravines, plains and just generally making the heightmap look so much better than it did. Just… so much.
Erosion will not happen in-game: the terrain I use is still optimized for a static height map and Monogame’s OpenGL platform doesn’t support Vertex Texture Fetch (Monogame is open source, but I don’t currently have the expertise or understanding of OpenGL to implement it myself), so that will have to remain as is for now. But when complete it will look a lot fancier and more natural than the current playdough-terrain shapes. Take a look at some of these comparison screenshots I hacked together.
Click to enlarge
Since the terrain will now include fancier and more realistic cliffs, I also intend to adjust creature’s pathfinding a bit. Climbing will need to be significantly more expensive than walking to make cliffs serve as barriers to geographic dispersal, especially since the ocean no longer serves that purpose once they find an amphibious survival strategy.
The Advanced Settings page, for settings what be advanced an’ stuff. This will serve two purposes:
- This is where you’ll find all the lesser-used input spinners you currently see on the New World screen that aren’t directly related to the starting creatures or the world. I prefer not to remove features unless I can confirm that nobody is using them.
- More importantly, this is also where you’ll find brand new settings. Some people have been doing amazing experiments with the settings available in 0.12.0, and I want to help facilitate this scientific approach to the game by providing new variables to tweak. At the very least, some modifiers for the stamina and oxygen bars would seem to be in order. If you have any suggestions for settings, let me know!
Other things worth noting
Sliders: To make the new world page more user-friendly, I’ll be implementing horizontal and vertical sliders in place of the existing Input Spinners. Hopefully I can find a good way to balance making these simple and user friendly with making it possible to see and type in the decimal value you want.
Scrollbars: I’ve needed to add a working scrollbar control to the game for a while, but I keep putting it off. The Species GUI is a… let’s call it a “proprietary system” (read: homegrown mess), so I need to implement new controls myself. Additionally, a scrollbar is defined by its relationship to other controls, so it’s a bit more complicated than a simple spinner or label. But I’m committing to it this time. We’ll have scrollbars in Species 0.13.0, and I’ll retroactively apply them to everything that needs ’em.
Biome Editor (?): Big question mark on this one, but I’m toying with the idea of making the biome map 100% customizable, down to the type and number of trees that spawn in each biome. On the one hand it would be a good feature, particularly for people interested in modding the game, but on the other it would be a fair bit of extra work and may eventually prove redundant when it comes time to overhaul the Vegetation system into something more ‘evolutionary’. We’ll have to see how it goes.
Tweaks: As always, once the major features are done I’ll launch into a few weeks of bugfixing and tweaking the simulation to be more interesting and intuitive. This is when most of the physical and behavioural adjustments will come into play.
Unfortunately, 0.12.0’s tweaking period got absorbed into my epic battle against the Arithmetic Exception (I dance on it’s grave), so I have a fair-sized backlog of minor adjustments I’d like to make when 0.13.0 comes out.
Frequently these tweaks can do as much for the game as the major updates, so I imagine Species will undergo a rapid (and hopefully very positive) diversification period immediately after 0.13.0 is released.
Do you have any idea’s for tweaks? Let me know in the comments below.
Posted in Uncategorized on May 10, 2019
* Once again attempted to defeat my nemesis, the ArithmeticException bug (the most common cause of crashes in the current version). I’ll get you this time, gadget.
* As I have still been unable to catch the ArithmeticException (the most common cause of crashes in the current version), I have purchased a significant quantity of fireworks from the Acme Corporation and laid an ingenious trap.
When the crash happens, the program will report a significant quantity of additional information about the problem that I can use to track it down and fix it for good.
* Strapped the ArithmeticException bug (the most common cause of crashes in the game) to a table and attempted to bisect it with a laser. Gloated for a while, then left the room in the certain knowledge that escape was impossible and my victory was complete.
* Increased the scale of limbs to make creatures in general a bit more interesting and… appendagery. That’s a word now.
The information from my 0.12.0.9 trap helped a little bit, but it mostly just confirmed where not to look: it’s not related to a specific leg type or position, and the cause of it is exactly what it looks like: a leg bone rapidly increases in size until it hits infinity and transcends numerical classification.
The cause of that appears to be a state issue in the limb animation. Leg bone transforms are supposed to be reset and freshly applied each frame, but something is causing the Bicep/Tricep widths to be saved and re-applied on top of each other every frame.
I’ve been unable to track down the exact scenario that causes this, so instead I’m refactoring the entire animation system to eliminate the possibility of state information being saved between frames.
Which is kind of like applying nuclear weaponry to the task of killing a cockroach.
But this cockroach is 50 meters tall and breaths fire, so screw it. Nukes it is.
It fought back, too. Immediately after starting the refactoring I started seeing constant expansion bugs every time I ran the game, not just from the limbs but from the tail and neck as well.
But those are gone now. Still have a few extra bits of fallout to deal with (limbs not rotating due to droop, being smaller than they are supposed to, and flickering), but we’re on the right path.
It’ll be good to get this one behind me and officially announce what we’re doing for 0.13.0.