The new level introduces a new type of hazard, complements of Earth's inhabitents: satellites. The solar panels they have absorb your shots instead of being damaged by then, some satellites use the generated electricity to fire back at you, so watch out!
This build also has all levels unlocked so you can try all of them even if you get stuck on one. It also features an animated sprite for the player. It's a little rough right now but it's a start.
Added a second level to From The Sun, which of course is to Venus. It has its own music, and the music for Mercury is improved from last time. Both levels are available on the main menu, although eventually they'll be locked until beaten in order.
It felt good to move on from a single level test bed of a game to creating more content with a base setup that I'm happy with. It was also great to have a sudden inspiration for a theme to follow while I created the waves of debris for the level, before it had felt more like filling space than coming up with a design.
I want to get an Earth level in the game by this weekend too, but I don't want to force that and make a level that's just filling space. If something comes to me I'll get it going otherwise I'll spend that time improving other aspects of the game, like the transition between levels.
There are two UI elements that I've built in Unity for From The Sun by creating a 2d mesh and mapping portions of this 8 pixel image to it.-> <- It's 1x8 and I'm just using it for color definitions. You can see the two UI elements in the picture below. They're the big rainbow gauge on the right side and the smaller rainbow gauge inside it. The big indicates the player's current color and the colors that are upgrades or downgrades from the current. The smaller one shows a history of the players colors as they make progress towards the current planet.
The big UI element is basically just a stretched out version of the raw image. I create a mesh of vertices that define those bars, with wider space for the player's color. The uvs just correspond to the image distributed evenly among the vertices, working out to one pixel providing the source for the two triangles that make up each bar. The triangles are just built directly from the vertices. The biggest effort for building this element was animating between the focused color, which was still just maintaining the current point of the boundary and animating it with time, stopping when the new color is full sized.
The smaller element took a little more building up of data to represent what is being shown. Instead of a current value to track that just represents an index the progress bar tracks the history of how much time the player spends as each color, in order and as distinct sessions. It was easy enough to set up a Progress class that has the color and duration, then keep a list of those, adding a new Progress item when the player's color changes and tracking time on that one. Then using the width and height of the rect that the progress bar will fill as boundaries I can start building a mesh from the bottom, adding new vertices from the bottom up for each progress item. This is where I went from copying code for creating meshes from vertices, uvs, and triangles and understanding it enough to read it and adjust it, as I did with the larger spectrum indicator to rewriting it completely to fit my needs. I iterate over the progress items, creating 4 vertices for each, uvs to sample the right color of the 8 pixel image, and triangles for those 4 specific vertices. This ends up with more vertices than actual on screen point locations, each boundary is 4 points for a line instead of 2, but as far as I can tell that's what I need to do to get the right uvs for each rectangle. I also make sure to only create triangles for the rectangles I want to display, not the infinitely small spaces between them. Once I reviewed the mesh generation code I already had and looked at how I was tracking the progress data this approach really fell into place and I feel like I have a better grasp of how a mesh and a texture map to eachother. The pointy bit and borders on the smaller gauge are done with a shader, the dot is just a copy of the renderer for the player that I move with the progress.
With some recent incremental builds that I've been sharing amongst friend I've worked out a fair about of small changes to the core gameplay of From The Sun that have really improved the feel of the game:
Removed ammunition limit. It wasn't serving a purpose in terms of gameplay, I just added that arbitrarily because it felt like part of how ammunition 'should' work.
Player color always moves towards ultraviolet on the spectrum when collecting ammunition photons, previously it could go up or down based on the color of the ammunition. That wasn't intuitive and now the behavior is more in line with an intuitive expectation.
Shots do damage based on their color. Previously player color had no efect on attacks, I had considered using different attack types, such as spreads of shots, for different player colors. Again, this complicates behavior and expectations for the player. By changing the damage of shots the player does not have to have the expecation of that to make use of it, but with that expectation they can make better use of it.
In addition to these smaller mechanical changes I've been updating the tools I've been using to design levels. I was limited to placing individual prefabs in Unity, of which I had created some using splines. I added support for editing splines directly in the Unity editor and I've been able to make much better shapes and layouts for debris clusters. Speaking of debris clusters I also changed the way the planet is put together, now it's a composite of small objects instead of a single large one. It makes breaking the planet down more satisfying.
I've also been learning more about making music with LMMS and it's a lot better on the ears that the previous builds have been. The improvment in the sound quality is primarily from switching from pretty pure tones to sounds created by the triple oscillator provided with LMMS. The sound effects need the same treatment.
Overall the game is getting to a good place and I'm ready to focus more on building out levels and improving the audio and visual assets..
My initial plan for audio in From The Sun was to have it be entirely procedural. It seemed like a promising direction for a game where player state is already influencing gameplay. The tones would be based on player speed, everything generated at run time. At first it seemed like it was coming together: I had a simple system set up to play arbitrary tones and constants available for the wavelengths of musical notes. Mostly I was generating sine waves, created a player that would combine all the currently playing sounds into a single stream. Eventually I had sound effects for most game events: shooting, collecting photons, taking damage, and dealing damage. They were ... harsh. The simple sine wave tones do not sound good. I would have to create filters for them to make different instruments voices. It would be a lot of effort to recreate something that's been being built up for years. On top of the sound quality not being good I discovered that Unity's WebGL, and maybe WebGL in general, doesn't support generative audio. I like being able to host builds online to show progress. I could have started hosting OS specfic builds, but combined with the low quality sound I was getting it was clear that generative audio is not the way to go.
So I started looking at authoring tools, of which there are tons. It's really overwhelming to sift through all the options, but I managed to find a pretty easy to use sequencer called LMMS. It was really easy to get started on and now I've got some better, although still not amazing, sounds effects and even a dinky little music loop. They've taken me just a few hours to put together, rather than the couple of evenings I spent getting a really low quality sound generator going.
I think the real take away for me from this whole process is that finding the right tool is always going to be faster and give better results than trying to make a new tool without having ever used one like it.
Been working on some level planning tools and refining the UI for From The Sun.
My initial toolset was an editor that placed each obstacle individually. This grew tedious quickly and I started setting up groups of spawns as waves and a couple of basic types of waves to generate programmatically. My favorite of those types was one that divided the screen by fifths, picked a random ordering for each of those subdivisions to get a waves, then use the same ordering to place five pieces of debris within the subdivision. I liked it because it created a good spread that hit every point on the screen but wasn't too hard to avoid, plus the first wave of debris describes where the rest of the waves will be on the screen. Those are still in use in the sample level, but there are some new types that I'm generating as well.
In addition to the generative waves I added some new tools to create groups of debris using splines. Following the Cat Like Coding spline tutorial I was able to learn a lot more about custom editor tools to help me lay out paths of debris. Next up will be composite debris that consists of multiple types of debris as a single physical object. That will allow for some interesting debris to navigate that rotates as a unit.
The UI has a new side bar layout that uses its background as a quick color indicator, plus easier to read score, and a less distracting ammo icon. There's also a tutorial that helps describe the mechanics of color changing and gathering ammo.
One big task that I have't even started approaching is audio. I should find some creative commons music and sound effects to use, at least for now.
This is the first build of a game I've been working on for a little while. You control a photon travelling through space. Collision with other photons give you energy, which you can use to destroy obstacles. WASD to move and space to shoot.