This week, I’ve been trying to figure out the best way to determine where settlements like Cottages and Towns will be spawning in a procedurally generated world.
I’d like to have some trade routes eventually – or people at one settlement aware of the ones that can be reached nearby so they know where to generate procedural quests at – or some other form of connectivity.
So I figured I’d use the perlin noise to also help create predictable settlement spawn points.
It makes sense to me to spawn next to seas and mountains, as those would be resource rich areas. So I wrote some code that identifies those areas.
Then I wanted these isolated loops of hexes to be connected. Rather than find the shortest routes and make straight lines, I created an offset of perlin noise and created “invisible lakes” with it by defining the value that would be the edge of the lake. Then I traced around those the same way I do with the real lakes and mountains. The result is windy paths that intersect most of these sea and mountain paths.
Intersections of these make the most sense for settlement locations, as an intersection suggests higher traffic of travelers along paths. At each intersection, the hex has its perlin noise value from the offset noise I laid down. I chose a low range of values for the site of cottages, and a high range of values for the site of towns. I have a significant range left over for other types of settlements I might decide to add.
After that, my computer crashed, and I spent a day trying to get Unity to start again. Their customer service is excellent, however, and they got me up and running with just one email of suggestions.
Downloads and Ratings
I’m also celebrating my 1,000th download of Sverdheim this weekend! I had added it early to the itch.io Bundle for Racial Justice and Equality, which single handedly boosted me from just 100 downloads. I am in awe that so many people gave this simple little game a try.
And with that, I got my first 2 star rating, for being a “Totally bizarre roguelike game.” I think it’s a funny rating, but I hope it doesn’t discourage others from giving the game a try, and maybe leaving ratings of their own.
Character creation! Customize your sprite. Name your new character whatever you want. Chose a primary attribute to get that edge. A secondary attribute and weakness are randomly selected for you.
Attributes now defined with opposite attributes, so that the random attribute selection during character creation knows not to stack onto your primary attribute, nor will it select a weakness that negates any of your attributes.
You can see your name in the character status panel.
Your equipped gear is reflected in your character sprite.
Fixed a bug where a player would sometimes fall out of the initiative order during combat and get helplessly stomped on by the enemies until they die.
Old saves not compatible with this release.
Adjustments to the overworld song patch. Randomly inserts a bass kick on the main beat. Sometimes the Matrix Sequencer will now skip adding notes to the 8th column, creating an interesting rest in the song. Matrix Sequencer volume limited so as to not be so ear-piercing at times.
Trying to quicksave during combat gives the player a little feedback message to explain that it’s not going to happen.
An autosave file is now saved to before any combat or rest to make your save scumming easier.
Some new tips added to the title screen tip scroll.
Encounter difficulty reduced to get in more encounters between rests
This is the first major update of Sverdheim after declaring it “finished”.
This new update changes the world from a limited, rectangular size, bounded by void, to near infinite! Its size is bound by the limits of the 32 bit integer. Doing the math, that’s 2,147,483,647 areas, time 16 (areas are 16 x 16 hexes) gives you a world that’s 34,359,738,352 hexes along each axis. If you were to walk from one end to the other in a straight line, it would take you over 1,000 years.
So that’s plenty of room for adventure!
With that change, some other components of the game needed to change with it. Most notably is the new, circular field of view. Since the game generates the world as you move into new areas, I limited your view so you don’t see the magic happening beyond. I tried to chose a range that showed you enough of the world around you, yet not so huge that you could see everything. I’ve got it on the list to make it work like a fog of war, where visited areas remain revealed, but for now, you’ll just see your immediate surroundings.
It’s like a smaller window on a larger world.
I’ve tuned up the music a bit. Someone said that it was sounding harsh, and I agreed. So hopefully the changes are a bit more melodic. I’m leaning more on the random sequencer than the percussion samples. The game music is still generative, and now it’s infinite as well! Personally, I love it. I’ve found myself running the game in the background of other tasks I’m doing just to listen to the music. Since it changes over time, it never gets old for me.
Encounter balance has been adjusted. Before, it seemed like I would get into one fight, and more frequently needed to run away than stay and win. There also seemed to be a ratio of one fight, followed by five rest attempts. This wasn’t fun. I wanted the ratio to be about the other way around. So now the enemies are a little easier to beat and resting restores your full health. I’ll be tweaking this balance in future updates if we feel it’s too easy or hard.
There’s other, smaller changes and details that I’ll get into in future blog posts over the coming weeks.
If I were in marketing, I’d write more. But I’m in programming, and the more I blog, the less I program. But still, I’d like to not be completely silent. I know whenever I look at an indie dev’s site, I tend to judge how alive the project is by how recently or how frequently they blog – even knowing what I know. It’s the only thing that I can find that gets me a pulse, you know?
The daunting thing is the time investment. So let’s try something different: Once a week, at least. Small posts. Screenshot. Little slices of progress.
So here you go. Small post. Screenshot.
This is me doing some work on the new spawn radius.
When the work is done, and the next goal line is reached, I’ll go back to longer posts where I talk about the more interesting things I’ve been doing. I’ll give more details on these little posts too. For now, here’s my pulse.
Has it been one week? It feels like two. Maybe it’s been two weeks since I’ve decided to take a break. Since I’ve “finished.”
Now it’s time to start back up again, if for any other reason but that I promised myself I would. It’s interesting: When this started I was driven by a hereditary compulsion. I tend to sometimes get an idea and laser focus on it, driven against my will to the point of exhaustion to work on it. Then, like always, the drive waned. This time, though I had set an attainable goal line for myself, and when the emotional half of my brain tried to lose interest, the more deliberate part of my brain was able to take over and push just a little extra to get there.
I call that “Practicing discomfort.” It’s something I do when I work out. My body is done. I don’t “want” to do it anymore. So I practice being uncomfortable. If you can understand that sometimes the uncomfortable places are the places where progress is made, you can accomplish much more than you would otherwise.
And now, I’ve taken a break. There is zero dive to keep going beyond a list of cool stuff I can accomplish. So let’s just set a little goal this time. I’m taking just a small handful of the ideas from that list. That’s all I have to do to finish again. Some are boring but easy. Some are more work, but more exciting. But the important thing is that this new goal line is easily obtainable. I can’t count on my neurotic compulsion to get me there, or even to get me started this time. That interest has drifted on to other things over the break.
But will the little goal carry me? Can I trick myself with many little goals, interrupted by many little breaks? I’ve done it before with some success, though on a smaller scale. When I don’t feel like working at my job, I tell myself I’ll “just work for 25 minutes. Then we’ll take a 5 minute break.” I can do that for days: Working 25 minutes. Break for 5. Work another 25. Break for 5 more. And so on. I get a lot of work done when I don’t feel like it that way. So let’s see if we can expand it.
We’re just going to do this little list of things. Let’s see what happens.
*No software is ever finished, until it becomes abandonware.
Sverdheim is now a complete, playable game. Wow. I’ve never done that before. It’s something I’ve dreamed of since I was a little kid. Another achievement unlocked.
This game itself is nothing special. There’s nothing new about it. It’s simple. You just play it until you get tired of it, and with the current content that would be rather quickly. Or maybe it just seems that way to me because I’ve been inside it for so long, and I have so many ideas for how it could be better.
So what’s next? Next I take a break. It’s important to walk away from these things before coming back with fresh eyes. Next I write some blog posts back on erickveil.net about how to do more technical things. Maybe I play some other games or look into another project that I’ll tinker with more casually.
But then I’ll return. Like I said: I have so many ideas. There’s a huge list that built up while getting this far of features that could make this game so cool. I’m going to do those things. Maybe we’ll set another, small goalpost. If I’ve reached this one, I can reach another one.
For now, you can download and play Sverdheim. I’ve hosted it on itch.io. All future releases will be there, and I’ll likely kill the github project, unless I decide to host some code there.
Well the world got a little weirder these past few weeks. It’s a good time to play video games, at least.
As promised, this release of Sverdheim has the music in it. Rather than write the music myself, and reveal just how not musically inclined I am, I programmed the game to generate the music for me. If you know anything about modular synthesis and generative music, then you already know the techniques I’ve used.
Each class in the music chain is like a module in a modular synthesizer.
I started with a simple “Clock.” It has a parameter where you can set and change the BPM. It emits a signal each tick, the frequency defined by that BPM value. Any other component in the music chain can link to that signal and do *something* and it will always be on beat.
From there, we have a “Clock Calculator”. This object takes a signal from a master clock, and in turn triggers several output clocks based on its emitted beat signal. This way, we have many clocks, all with beats based on the master BPM. One output clock would be at double speed, one quadruple. One will be at half speed, another will be one quarter speed. This way, we can control other components at various speeds, and they all will still be on beat.
Next, I wrote a Variable Frequency Oscillator. It’s basically a sine wave generator. I tried to create other wave forms, but they sound terrible. I’ll include the others later, but to do so I will have to figure out the proper Furrier Transforms, or more likely grab an asset from Unity’s asset store that already generates them. For now though, the sine wave will be enough.
The oscillator has many settings for customizing the sound. You can set the frequency, and the length of the signal in fractions of a second. I created a standardized set of frequency presets that each match the natural musical notes from C to B at octave zero. The natural notes I know I can pretty much combine in any order to make a chord that sounds good, or a scale of notes that sound good. Therefore, I avoided any flat or sharp notes or any of the other weird stuff that people with more musical knowledge than I have tend to use. There’s an octave setting – each octave just doubles the frequency of the same note from the previous octave. This gives me a wide range of notes I can play.
The sine wave by itself sounds rather digital, but the magic of making any garbage sound good is reverb. Reverb is why you sound good singing in the shower. Luckily, Unity has a reverb filter built in that I could use, and it makes my sine notes sound like bells.
Next I created a sampler. This one’s pretty simple: I feed it wav files and a clock and it will play the sound when the clock triggers it. I created a couple of heavy, reverberated bass drums and a high clap in LMMS, and using them in a handful of samplers gives me a passable drum machine.
To run the drum machine, I implemented a software version of Music Thing Modular’s Turing Machine, another module for Eurorack synthesizers. I call my class a Randomizer. This object takes an input from the master clock, then outputs various random beats, and also a chain of random frequencies. It will then change the beats and frequencies over time at a customizable rate that I can set via an attribute.
Using the Randomizer, I create a random percussion sequence that changes over time. I also connect it to the Oscillator with a low octave for a slow, low, droning bass line. I have a faster clock controlling another Randomizer that feeds into another Oscillator, and provides a single note, continuous random melody.
Next, I created a Matrix Synthesizer. It’s like a 16×16 grid, where the y-axis is the frequency of the notes (each frequency a natural note, spanning a little over two octaves), and the x-axis is time. Each beat from the input clock advances the time one place, and we play every note on that Y-axis at once, making a progression of chords.
I fill in the matrix using Bresenham’s Line Algorithm. Usually, this algorithm is for drawing lines in graphics programs, but here we use it to draw notes on our matrix. This arranges the notes in a scale every time. A new random scale is added to the matrix each time a public method is called, overlapping them and creating random chords. We call the method after each time the 16th chord is played, causing the melody to gradually change over time. There’s a minimum and maximum density setting, which allows me to set how many notes are allowed on the matrix. Once the maximum is reached, the lines start deleting notes back to the minimum, where notes are added again.
An interesting thing about the Matrix Synthesizer was when I first wrote it, like many things we program, it didn’t work as expected. I needed a way to quickly visualize the matrix itself. I didn’t want to spend a bunch of time programming some visualizer though. That night, while asleep, I designed a simple matrix visualizer in my dreams. It’s just a unicode text box in the Unity Inspector. I use white and black boxes to represent the matrix – black boxes showing notes turned on, and white ones showing notes turned off. White and black circles replace the boxes in the currently played column. I wrote it when I woke up and it gave me exactly what I needed to debug the class. I feature this visualizer in the video above.
Finally, I added a higher level of music generation than you can get from modular synthesis: Procedural patching. All of these elements are randomly combined in different ways, according to a set of rules. I’m calling each set of rules a “song” for better want of a term. There’s a song for the main menu that’s a slow, random percussion that introduces you to the game like the beginning of The Anvil of Crom. Once you start the game, that song evolves with bass droning and matrix melody. In combat, there’s a fast percussion song that’s meant to get your heart going. When you rest, there’s a song that’s a slow, light melody that’s supposed to be more relaxing. And while just out in the world exploring, random modules are combined into various songs.
The weird thing about all this is that the music still has a cohesive sameness to it. Like, the “songs” each tend to sound the same just because they follow the same rules despite the actual progression of notes being completely random. If I’m not mistaken, we copyright music based on those concrete combinations of notes, but I’m no longer convinced that the actual notes of a song are what make it a song. I can’t put my finger on what does, though. It’s not just the sameness of the instruments, as your typical rock band will play a wide variety of songs with the same instruments. I don’t know. Music is beyond me. That’s a puzzle for someone else who’s been a bit more saturated in these disciplines.
So I’m almost at my goal! With the completion of the music, I now just have a list of bugs to work out, and my Minimum Viable Product will be complete. Just like the other aspects of the game, though the music is finished, it will likely get added to and altered and tweaked as time goes on and I get new ideas.
Nothing is ever really finished, despite the goal markers being reached.
This weeks release is a small change. Some tweaking to the sound effects, and a fancy new splash screen. I once got a game on Steam with the default splash screen. Even though that game was free, I found the default Unity splash screen a little unprofessional, and it colored my impression of the game. It’s a small thing that doesn’t take much to change.
Much of the week, I’ve worked on music. There’s no music in this release (0.5), as it’s not in a listenable state: It blasts your ears full force and there is no control over it yet. So I disabled it for the build.
I’m pretty excited for a couple of reasons, and they both have to do with the music.
Working on the music means I’m coming to the end of my journey. Music was bumped to the end of my list because I knew it would take so long. A delay that I wanted to take time on without thinking I was spinning my wheels and delaying progress. The fact that I’m working on it means that I’m near the end of my list! After music is the cleanup – a list of things to fix that’s accumulated along the way that I have to complete before I can say I at least tried not to half-ass this.
The other part I’m excited about is just seeing this music take shape. I have no musical talent, so I’ve decided to let the computer compose the work. I’ve provided audio samples, spent a lot of time figuring out how to write wave oscillators, and defined the rules about when and how things play. How the beat is constructed. How the melody forms. And it sounds, to me at least (and I am my own target audience), amazing.
The music is never the same, but it’s same enough to be cohesive and defining of the game. As I’ve said before, I don’t imagine music in my head that I might try to duplicate. My compositions are random, or partially visual based where notes are arranged in a visually organized way – which makes no sense to the ear. So I’ve just handed that chore over to the computer. And surprisingly it works!
The next release may be a couple weeks. I don’t want to release the music until it’s done, and programming music is a bit different than other programming. Usually, I know what I’m writing before I start typing. I know what the expected results are going to be, and I know how to test things to push them back into the form I need when things don’t go as planned.
But I have no design or testing process for music. It’s all experiment – trial and error. I have to write code I may never use just to see what happens and not like it. I have to write code that is not in the game which analyzes the sound’s data to try to find out why my wave has a popping sound every few seconds. I have to figure out Fourier Transforms again. It’s one of those “I’ll never use this” things from math that was immediately forgotten after the exam. But here it is, promising to make my sawtooth wave not sound like garbage.
So if I don’t post next week, I’m not going to guilt myself. I’m busy working. In two or three weeks, I’m going to have something cool. And maybe I’ll share it with you.
I have a new version of Sverdheim for you today, though the time I’ve been able to work on it has dropped off drastically. This is another reason why I’m keeping the initial feature list so small. My original burst of obsession has faded, right on schedule. Still, I don’t believe the project requires such intense emotional motivation to complete. I still gain joy from the work, especially when I look at the list and see how close I am.
This week, my actual job has been fulfilling. That’s the real distraction: Real Life. I love my job for the days it engages me like this. It’s got its highs and lows, just like any job. This week was high: I’ve had concrete problems with clear solutions for me to design and code. I was able to create beautiful solutions. Soon I will have to test them. Testing is necessary, but boring. When work turns towards the testing slog, that’s when my personal projects, such as Sverdheim, pick up momentum again during the off hours.
Still, I’ve made progress, and I’ll celebrate even the small attention I’ve been able to put in this week. Sound effects have made it into the game. Despite my poor ability in this corner, it’s amazing what that little bit of beeps and boops do to liven up the game. I dipped my toe into some theme music, but that endeavor reminded me that I have absolutely zero musical talent. I don’t have music in my head at all that I might try to duplicate, and if I ever did, it would be easily replaced by whatever I hear. So as soon as I make a failed attempt and listen to it, that’s all I know. I spin my wheels. So I’ve put the musical task off until later, in favor of more attainable and less grinding goals.
Like any skill, I’m sure I could work at it. I distinctly remember, in my early days as an aspiring polymath, that I had a lot of hobbies piling up that each took a lot of time. I needed to limit it. I’d decided that music was one I would avoid putting time into. I have a little exposure: Some trumpet lessons in grade school. A little choir. Guitar lessons in high school. Tinkering with a virtual modular synth and programming sound on a Commodore 64. But it’s never been practiced, much to the dismay of my instructors. Practice is vital, gifted or not.
Putting challenges off when you can allows your mind some time to reflect and for a plan of attack. I need to highlight my strengths. Whenever I put together a song, it’s really just random notes arranged on a piano roll in LMMS. Since it’s random anyway, why not just write a procedural music generator? I bet I could do that. I understand waveforms and envelopes. I’ll start with some basic, random percussion. Maybe some long, droning notes to go with it.
I’ve been listening to tagelharpa music for inspiration. That’s an instrument that makes me wish I had some sort of talent with sound.
It’s time for another update and this time I figured it would make sense to post it here on my shiny new WordPress site. I’d decided that if I’m going to be posting about a specific game, that I’d give that its own space. My existing blog over at erickveil.net tends to be more technical, and have articles about obscure programming and configuring things I’ve learned. While there would be some overlap between the two audience interests, I believe that overlap would be insignificant in size.
In addition, once I’d settled on a name for the game, and also found that nobody had parked the domain, I felt it would be a good idea to snatch it up before some automated web crawler under the malicious command of the Internet’s nefarious domain jumpers snooped out my intent. I’m not in the habit of registering domains for all of my projects, but it was on the list of tasks I’d wanted to achieve for this one anyway.
So, since we’re new here, let me provide a quick recap: The goal here is to actually finish a game. I’ve been programming games for a little over 30 years now, and that’s counting when I started as a child. In all that time, I’ve finished exactly zero games. That is because finishing was never the goal of these projects. The goal has always been to have fun programming. To dream and tinker. To relax and sling code without care or the pressures of requirements. You will often be warned away from such practice, but I’ve learned so much in the process of doing things wrong, much more than I would if I listened to everybody who is afraid of failure. I learn a lot from messing things up, and programming my own games allows me to mess up and not have it be on someone else’s dime. The difference this time is that the goal is to finish.
This game, Sverdheim, has its roots in that first game I worked on at the age of 12 on a Commodore 64. These days, such games are called “Roguelikes”. When the idea stared back in the 80’s, we just called them adventure games, or CRPGs.
In order to “finish” this game, I’m stepping away from my usual meandering and tinkering, and have set up clear goals of what finished means. There is a short list of features and functionality in place, and I am rigidly adhering to that list. As new ideas come in (and they always come, in large numbers), they go on another list. They are not abandoned, but perhaps they will be implemented later, after we have finished.
Along the way there are other features and functionality that pop up that are not just neat ideas, but make themselves apparent that they are essential even though I had not thought of them on the outset. This is a part of every programming project I’ve worked on. It is impossible to imagine every possible necessity up front, and it is foolish to ignore them as they arise. The art is determining the difference between the critical features that need to be added, and the ones that can be put off as they threaten to move your goal ever away from your reach. One type often disguises itself as the other.
I have much more to talk about, and that is good, since it will give me more blog topics to cover. Like the feature list, I must resist the urge to post it all here at once. That would result in one of those huge articles that nobody ever reads completely, and thus becomes a waste of everybody’s time. Even here, we must focus on the finish line.
Until the next post, I will leave you with the latest pre-release of Sverdheim. It is a work in progress still, filled with bugs and unbalance. But it provides an idea of what I am moving towards.