The project I’m touching up is a level generator running off my take on an evolutionary algorithm. I wanted the learning experience of trying to create one myself. I, of course, studied what evolutionary algorithms are, and how they work, but wanted to avoid looking up exact implementations in code until after my first major attempt.
As it stands now, it’s mostly done. The evolutionary algorithm side of it works. The only issue at the time I originally attempted the project, was the actual construction of the level in Unity. My problem was that I originally created the room objects as prefabs, with GameObjects and C# scripts. But the evolutionary algorithm, and subsequent construction of the level are triggered through a script’s Awake() method. Doing this means that instantiated prefabs don’t behave, and cannot be manipulated normally. Since the project’s main goal was the AI itself, this was a secondary concern included to try and turn it into a more complete, and practical product. Now that I have the time, I’m working on addressing that.
I’m now separating the scripts and GameObjects entirely. Instead of using saved values for the LevelPiece script (c# class that holds data, and methods that define and help set up the rooms) they’re passed in via constructor. The objects will be instantiated via script before instantiating a single, generic room GameObject that they’ll dynamically place, and scale based on the LevelPiece object’s specifications.
My main concern with the algorithm was to create a framework for programmatically generating levels that did not feel generic. The biggest issue with randomly generated levels is usually not their technical aptitude, but a lack of aesthetic distinction.
My interpretation of the problem is that it stems from a lack of cohesive direction, and/or lack of programmed understanding of aesthetics. The importance of aesthetics is why I chose to go with an evolutionary algorithm as well. The goal of a good level generator, particularly what I wanted to make, is not to find and iterate on a single solution. Part of what makes levels a great concept in many games is how distinct each is. So I wanted an algorithm that could arrive at a variety of solutions that only needed to have in common a high level of distinct aesthetics.
I modeled this by tracking a number of roughly measurable aesthetic qualities a level could have. But each one represented an axis, instead of a single quality. For example: narrow <—> wide which represented how many hallways and narrow rooms vs wide rooms were used in the level. Building off of this, the fitness algorithm highly rates values at either extreme. So it does not prioritize narrow over wide levels, or vice versa, but it prioritizes both over levels that fall in the middle. After all the objective was to create distinctive levels.
Game Tuning Project
In an effort to get more practice at fine tuning game mechanics, I’m starting a series of mini-projects. I’m going to take individual, simple mechanics, implement them, and then focus on fine tuning them for practice with game feel.
First up is the age old jump. It took a bit more initial setup than planned, because I wanted to do it cleanly. But I’ve got it working, and after a first pass at tuning it’s already showing strong promise.
I’ve never been happy with how jumps I’ve done in the past using realistic physics felt. They come off as sluggish on the rise, and you generally have to make the height overshoot the height of a ledge significantly so that it’s reasonably forgiving. So I’m trying a jump that works in 3 stages of physics: rising, floating, falling. Falling just applies gravity as normal. But rising, and floating give periods of reduced gravity so that the player rapidly accelerates to the apex, and remains close to there longer, before plopping back down.
I’m guessing I’ll end up making a number of profiles with corresponding values for this, and other mechanics I do. That way I can easily use this one model to create a variety of jumps: peppy, hefty, floaty, etc.
Prior to my final projects I was also working on learning, and practicing Python from scratch. My initial goal was to try and do something daily with it. But now between job hunting, and just trying to get more meaningful things done with, and in addition to Python I think it’s going to make more sense to shoot for a weekly schedule.
Tentatively I’m looking to attempt a similar variety of tasks, but focusing on doing less of them daily to make it easier to devote large blocks of time, or an entire day to focusing on 1 project at a time as needed. So it will look something like this:
- daily job hunt stuffs
- weekly Python work
- weekly small game projects (AI, VR, Unreal, etc.)
- weekly game tuning project
- weekly work on large game projects
- weekly work on art styles
Since this blog is more specifically about game design, and development I have not discussed my work with art as much. I might start including a bit more here, or keep it to other venues.
More to come on the large game projects, which include the one discussed previously on this blog, and the group project I’ve mentioned, as well as others I’d like to pursue in the near to midterm future.