I’ve been a bit demotivated in the last few days… No reason in particular, think I’m just tired from the DayJob™, but because of that I haven’t been very productive…
Today I only managed to make the planets spherical when we’re in orbit, which should have taken me 10 minutes, and it took me over two hours… Of course, that was a lot of tweaking, silly mistakes, making the textures, etc, but still it’s way too long…
I think it’s because as my list of tasks becomes shorter, the amount of boring stuff becomes larger, and if making games is just a hobby, you have some difficulty tackling boring stuff after a full day of doing boring and/or demanding work…
Anyway, I hope to feel more motivated in the next few days, after I tackle some long-standing bugs that annoy me… 
Now listening to “Remagine” by “After Forever”
Link of the Day: 1080p 60FPS YouTube is one of the best things to ever happen to the demoscene!
The results weren’t as good as I hoped, but at least they’re fully procedural and there’s not many idiot names in the lists…
I tried using a syllable-based system, but there are just too many of those, so the memory required for this algorithm would be just too much!
Ended up using a list of names from sci-fi worlds, combining them together to generate the probability tables and then using that to generate names. To have some different types of names depending on the type of planet, before I add a string to the dictionary’s, I decide on which dictionary to add by analyzing the character content of the name. For example, a name with a lot of “A” and “E” will be either a jungle or swamp planet… This is combined with a bunch of other rules to decide which type of planet this is, and then adding this to the dictionary for that type of planet…
Convoluted, that’s for sure, but the results are a bit better this way… Still see too many cases where the planet name starts with double consonants (which makes it harder for the player to read), I might still do something to remove that situation…
Anyway, in keeping with my tradition, next step is some bug fixing, then some optimization before going back to polish…
Since I had to restart the game (to generate planet names for testing), I’m going to start my bugfixing in the first planet, see if I broke something on the initial cutscenes…
Now listening to “The Singles 86-98” by “Depeche Mode”
Still working on the random name generation, not 100% happy with the results…
So far, the system with best quality is based on probability. I give the system a list of “good names”, and he builds a dictionary of probabilities, which describe the probability of character Z to come after character Y, after character X.
While the results are “not terrible”, I’m still not satisfied with them. Here’s a sampling:
arsaus
erbet
ebarai
betaina
lassan
kladon
mithrumia
etaandora
iburgos
llewor
sihnos
erequara
cygna
landia
entess
gamint
woria
rtrai
ahiigna
mwork
ltitun
ptelus
rayailux
…
Some of them are unpronounceable, and this already had some pruning in terms of fine tuning the dictionary. And it doesn’t work at all for my purpose, which is different types of dictionary for different types of planets!
This would be good enough for the game, I’d say, but I like this kind of challenges, so I’m going to investigate this further: going to try using phonemes instead of just letters. The system is roughly the same, it just categorizes things differently…
Now listening to “Valley of the Damned” by “Dragonforce”
But Tuesday’s are also terrible!
DayJob™ takes a lot of my time on the beginning of the week, so I get dead tired and can’t produce much on Gateway as I’d wish…
Today I spent most of my time doing research on how to generate procedural names for the planets. Currently I’m using a list of 100 names randomized, but I’d like names to have some bearing on the type of planet… For example “Vulkan” should be a lava planet, “Plantora” should be a jungle planet, etc…
I’m trying a couple of approaches and I’m currently implementing one based on learning applied to prediction systems, which is quite cool, but I’m not sure if it will work with this… I’m currently implementing it, so nothing to show for it today…
Now listening to “Desert Butterflies” by “Yossi Sassi”
The “escort” mission was full of them, some due to the multithreading, others due the actual logic of the system (for example, the player could leave without the person being escorted)…
Other than that, it was just standard debugging… Still found some places where I’m using the old brains, instead of the script-based AIs, so I need to make sure to remove all of them from the system…
Tomorrow I hope I’ll be able to play around with the planet name generation (which seems fun in theory!)!
Now listening to “We Are the Void” by “Dark Tranquility”
Link of the Day: Another extremely nice demo… YouTube 1080p at 60 FPS was one of the best things to ever happen on the demoscene! 
As the title indicates, some more work on bugs, mainly things related to the multithreaded area generation…
Also improved the look on the vertical faces of the ice:
Just got some more bugs on my list, and tests to be done on the random missions (some of them might have been broken by the multithreaded code, due to the fact that areas are no longer deleted when we transition from one to another).
Now listening to “Easton Hope” by “Orden Ogan”
Link of the Day: I laughed… 
Not much to talk about today (at least nothing interesting)… It was mainly a bug-tracking/killing day…
Some issues with the management of missions (which would sometimes cause for duplicate missions to show up), plus the sneaky ninja that wouldn’t cross the area boundary (which sucks!) and some other small stuff…
I expect tomorrow I’ll be doing more of the same, unfortunately… Making new stuff is much more fun than fixing existing features!
Now listening to “Irrational Anthems” by “Skyclad”
Link of the Day: This looks interesting, a more “story-driven” FTL… Hopefully it plays as well as it looks!
Found another bug with the game related to the new multithreading system: sometimes, at a certain point in the game, ninjas spawn to chase the player. Before, when the player changed area, the ninja would spawn again, but now they don’t, because they haven’t been destroyed (the previous area is still in RAM).
I’ve adjusted the code to account for this, but it’s not working and I can’t figure out why… So time for some more debugging…
Also fixed some minor issues, including fixing the smoke bomb effect when the ninjas appear:
Not 100% happy with it, but I’ll probably tweak it some more in the future…
Now listening to “Origins” by “Eluveitie”
Scheduling and task management is something I could never do just right, I always tend to underestimate the effort, even if I multiply the times by two or even three… I probably think I’m smarter than I actually am! 
Anyway, today was one of those tasks… I thought that reviewing the scanner effect would take me 20 minutes tops, ended up taking the whole evening, all because in a place I had the parameters in the order “normal, right, up”, and on another I had “right, up, normal”, but this took me forever to notice!
The new effect looks way better, though…
In the process I found a lot of small bugs (unrelated), so that’s my next step, fixing those bugs before moving to something that might be fun or hell: creating random names for the planets!
Now listening to “Blackstar One” by “Celldweller”
The shader system on “Cantrip” has some sophistication to it, and part of it is the fact that it generates the specific necessary shaders from a uber-shader (a big shader full of conditions) and a render environment that trims that uber-shader to smaller ones, depending on need…
The problem with this approach is that everytime there’s a new shader requested (for example, a 3d model with a point light and a spot light on it, with two texture maps and no normals), the system has to generate a shader, which sometimes leads to a small stall (a shader takes some milliseconds to generate)…
So I’ve added a shader cache. I can’t store the generated shaders (well, on Direct3D I could store the byte code, but even that would cause issues, and in OpenGL I don’t even have that possibility), so I store the second-best thing: the generation parameters, so when the game starts, the system will generate all the shaders that might be needed for the game, preventing the gameplay stalls…
This works rather well, and allows for a more fluid gaming experience, and the expense of a slightly larger startup time (some seconds only). Just my initial setup (not all shaders accounted, this list will grow automatically, so I don’t have to see every permutation I’m using) has 110 shaders and takes about 15 seconds…
No screenshot though, this is all done on code! 
Now listening to “Shatter Me” by “Lindsey Stirling”
