• From The Sun Postmortem

    In the over a year since the last blog post I've done very little development on From The Sun and a few months ago decided to stop work on it all together. As I built on the initial concept of playing as a particle of light that changes color and energy levels by absorbing other light or running into obstacles I realized that I didn't have a full plan for what the final game would look like. As an experiment and learning experience I consider it a success, but I don't see a larger appeal with it in its current encarnation so I'm taking what I've learned and am moving on to a new project. More about that to come.

    Taking on a solo project and exploring more of the aspects besides programming was really good for me. I gained a renewed appreciation for all that goes into a game. Chiefly among the aspects of game development that I had underestimated are design and production. I did no real design work going into development for this game. It started out as a little experiment with no player interaction where colored balls spawned on a screen, redder colors on top falling down and bluer colors on the bottom floating up. When balls collided the bluer one would become one step bluer and the redder ball would be destroyed. I then iterated on that design a few times until I reached the mechanics in the current build. That was my design process.

    Once I was fairly happy with the game mechanics I started building out actual levels and a structure for the game. In that process is where I learned the value of planning the production beforehand in order to be able to plan a timeline for the game. I didn't have a timeline at any point in the development process. My documentation consisted of a trello board that I threw tasks in to as I thought of them and some pages in a notebook with ideas for what levels should be like. As a result of that a lot of little things in this game are completey flat and bland: menus, interface, sound effects, etc. I'd realize that one of those aspects needs attention, spend a little time on it, and then get distracted by the next thing that needed attention.

    Two things that I ended up being pretty proud of making as part of this project are the level editor tool for building waves of debris and a crystal 3d model that I don't actually remember if made it into the game.

    The level editor tool makes use of lessons from CatLikeCoding's Splines tutorial to spawn debris along smooth curves in addition to manually placing prefabs. In the screenshot below two such curves are visible. Not shown are the widgets that appear when they are selected for editing. This is a view of the first few waves in the Venus level (if you want to see it in action you'll have to give the game a play.) Also visible in this screen shot is how a wave with a bezier curve only allows for one curve so the parrallel curves are actually two waves with very close together timing.

    Level editor showing bezier curves and prefabs at the start of the Venus level

    The crystal model is for a type of debris that wasn't as useful as I had hoped. I wanted to have them fill the role of providing a reason players to try and be a specific color rather than going for the highest power level, but in play test it was confusing whether you could pass through them if you matched their color or if they turned you to their color. I had thought the former made sense but many players expected the latter.

    Spinning green crystal

    Ultimately the usefulness of the crystals hinged on a ditched mechanic where redder colors would still fall from the top and decrease the player's power level. The design iteration process led me to get rid of any reason to change to redder colors and the design took on a model where the player could take more hits and deal more damage by being high powered and there was no reason to go lower. This is the change in design that made the most sense and also removed much of the original inspiration.

    The final version of From The Sun is playable here on itch.io. It includes Mercury, Venus, and Earth as levels, they end up getting pretty difficult.

     

  • Third Rock From The Sun

    That's right, you can finally destroy Earth! 

    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.

  • Post-GDC adjustments to From The Sun

    Showed From The Sun to some other CAs at GDC and got made what are hopefully some good incremental changes.

    • Scaled down most obstacles
    • Limiting the variance in photon spawning so there's less visual noise
    • Replaced the particle effect on the player with a trail renderer
    • Skinned the planet meshes to look more like a planet and less like a bunch of rocks stuck together
    • Updated menu assets, fixed a scaling issue
    • Added more music tracks and made minor adjustments to existing ones
       
  • Now boarding flights to Venus

    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.

    Check out the web build here.

    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.

  • Building dynamic UIs from 8 pixels

    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.-> tiny little 1x8 pixel image <- 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.

    Check it out live in my latest build. Maybe turn your volume down because my 'music' is a little rough.

  • Mechanical fine tuning From The Sun

    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..

    Link to latest build

  • What I'm Learning About Game Audio

    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.

    Now here's a link to a new build with that new audio in it.

  • From The Sun: Tutorial and A Simple Level

    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.

    Play and comment please!

    Direct Link To Game

  • Test level of From The Sun

    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.

    Link to web build.

  • Ludum Dare 35 and Circumstances Beyond My Control

    CAUTION, CARTOON WEINERS AHEAD

    Got me and Karl's Ludum Dare 35 entry submitted almost a week ago now.

    For the theme 'shapeshift' we went with our idea of a reverse werewolf, cursed to change from a regular wolf to a helpless naked human during the full moon and be hunted by the wolves. The ultimate goal of the game is to kill the gypsy queen to free yourself from the curse.

    We changed the idea for the plot a lot as we went, finally settling on this one early last Sunday. Until then we had considered setting it up in a zoo instead of the woods. There would have been an inventory and some sort of goal acheivable by going around the zoo and trading items for tips. Once we realized that was too much to try to put in we scaled down the scope to what we have now.

    Karl made some assets that didn't end up in the final submission because I didn't have the development time Monday after work that I had planned on having, thanks a mechanical problem with a bridge on my way home. I felt so impotent seeing the time tick away while traffic failed to move, my 1 hour commute taking just over 2 hours. Luckily I still had time to actually upload a build and submit it during the submission grace period.

    Today I took the assets from Karl that didn't make it into the submission and put them into the game so we can at least show what should have been. Play that new complete build here.

    Here's some of the initial art, as well as zoo art, that didn't make the final version:

    Reverse werewolf #1, too happy

    Reverse werewolf #1, too happyPompous Lion

    Pompous Lion

     

     

    Helpful Giraffe

    Helpful Giraffe

    His flashlight doesn't even work, budget cuts are rough.

    His flashlight doesn't even work, budget cuts are rough.

     

  • Tiny Dev Blog: Spawning Mercury

    Now that there's a Mercury made I'm ready to do something with it. Added a planet to the end of each level, with a delay between the last wave spawning and the planet. For now it's a solid object for the player and everything else passes through it. For now it's something. Also learned that I really messed up on the UI, it always looked fine working on my laptop.


     

    Bonus lesson: if you don't have Blender installed Unity complains about .blend meshes.

  • Tiny Dev Blog: Making Mercury

    Getting in the habit of doing a dev blog after any amount of dev work.

    Last night I added a very basic planet Mercury to a space game I've been working on. Got up to a skinned sphere that moves from it's start point to a fixed location (so exciting!)

    Beautiful skin made in GIMP by yours truly:

    And here it is on a sphere:

    And it wouldn't be a dev blog without a code snippet. This one moves the planet to a pre-set spot, so that it moves into the play area after it spawns.

    if(!transform.position.Equals(destination)){
    Vector3 toDest = destination - transform.position;
    toDest = Vector3.Normalize(toDest) * Time.deltaTime * speed;
    transform.Translate(toDest);
    }

    With that checking for position.Equals(destination) I was expecting more of a wobble around the destination, but it ended up really smooth.

  • WHISTLE! WHISTLE!

    Here it is: Karl and me's submission to Ludum Dare 32!

    Our unconventional weapon is getting a song stuck in someone's head.

    The game is about someone wandering around listening to their music and whistling along. As they whistle they get the song stuck in the head's of people near them. When someone else gets your song stuck in their head it enrages them, turning them red, and they chase you down to hit you. The game is played using w,a,s,d or arrow keys. There are 3 levels and each has its own goals:

     

    The Park: Get your song stuck in 20 people's heads

     

    The Antartic: Get your song stuck in the 5 heads each of the 4 colors of people

     

    Alien World: Get your song stuck in 10 astronauts heads.

    Play in browser
  • Trees, Penguins, and Aliens!

    Three levels of getting songs stuck in people's heads. Karl and me's entry to the Ludum Dare 32 Jam. Can you beat all 3 levels?

    Play in browser
  • 2 Levels of Glorious Whistling for Ludum Dare 32

    Karl and I have gotten a lot more cool stuff into the game since last night.  Karl drew up some sweet animations and environmental hazards. I added progress bars for getting the song stuck in other people's heads and got together a 2 level flow.


     

    Play in browser
  • Ludum Dare 32 ready for first demo

    Here's a first look build of the game Karl and I are making for the Ludum Dare Jam. Our 'unconventional weapon' is getting songs stuck in other people's heads. You're walking around listening to music and whistling. When you stay close to other people for a little while they get the song stuck in their head and turn red. Then they chase you because they're mad that you got the song in their heads.

    Play in browser
  • Firetruck Infinite Weekly Build For March 22nd, 2015

    This week's build has buildings instead of square buttons on the menu.

    Also a bug has been fixed where the level wasn't ending as soon as it was lost. This left the thermometer full while the game continued.

    And the main menu has a version number on it. This week's version number is 0.15322.

    Play in browser
  • Firetruck Infinite Weekly build for March 15th, 2015

    This week's build doesn't add much more to the game functionally, but there are new screens added to the flow of the game.

    There is now an Android alpha testing Google+ group that will have access to the weekly build's Android version.

    I also added Google sign in for leaderboards and achievements, but those haven't been added to the game yet.

    Play in browser
  • Introducing: Firetruck Infinite

    Firetruck Infinite is a panicked traffic management game with an endless fleet of firetrucks for putting out fires.

    We've been working on this game for about 8 months and this blog represents the first of the weeky builds to get posted publicly. There will be updates on a weekly basis, typically Sunday nights.

    The game so far features a city being plagued by an arsonist turning to a new dispatcher(you), and a fleet of inifite firetrucks to save them. Gameplay consists of tapping on locations on the map to dispatch a new firetruck to that location. Fires will spread through the city as the level progresses and it is up to you to manage your fleet well and avoid traffic jams. You can select individual trucks to give them a new location.

     

    Play in browser
  • Using LibGDX TextureRegion

    After running into issues correctly loading managed Textures in my current LibGDX project when the Android app is backgrounded and foregrounded I refactored the project to use the TextureAtlas class and TextureRegions loaded from it. The transition was surprisingly smooth: the same amount of control with drawing is available on a TextureRegion as on a Sprite. Rotation around an origin and color tinting being my primary concerns. The main difference I found between the two approaches is that drawing happens through the SpriteBatch with a passed in TextureRegion rather than drawing through the Sprite with the SpriteBatch provied as a parameter. All of the transformations that I had been applying to the Sprite are now applied through the SpriteBatch draw method instead.

    As an example of this different approach here is the code for my HealthBar class's render() function before and after the refactor. 

    Before:

           public void render(SpriteBatch spriteBatch){

                    backgroundSprite.setBounds(viewBounds.x, viewBounds.y, viewBounds.width, viewBounds.height);

                    backgroundSprite.setOrigin(viewBounds.width/2f, viewBounds.height/2f);

                    backgroundSprite.setRotation(rotation);

                    backgroundSprite.draw(spriteBatch);

                    barSprite.setBounds(currentHealthBounds.x, currentHealthBounds.y, currentHealthBounds.width, currentHealthBounds.height);

                    barSprite.setRegionWidth((int)(barTexture.getWidth() * (currentHealth/maxHealth)));

                    barSprite.setOrigin(viewBounds.width/2f-viewPadding, viewBounds.height/2f-viewPadding);

                    barSprite.setRotation(rotation);

                    barSprite.draw(spriteBatch);        

    }

    After:

            public void render(SpriteBatch spriteBatch){                float x = viewBounds.x;                float y = viewBounds.y;                float width = viewBounds.width;                float height = viewBounds.height;                float originX = viewBounds.width/2f;                float originY = viewBounds.height/2f;                                spriteBatch.draw(backgroundRegion, x, y, originX, originY, width, height, 1, 1, rotation);
                    x = currentHealthBounds.x;                y = currentHealthBounds.y;                width = currentHealthBounds.width;                height = currentHealthBounds.height;                barRegion.setRegionWidth((int)(barRegion.getTexture().getWidth() * (currentHealth/maxHealth)));                originX = viewBounds.width/2f-viewPadding;                originY = viewBounds.height/2f-viewPadding;
                    spriteBatch.draw(barRegion, x, y, originX, originY, width, height, 1, 1, rotation);        }
  • Game stuff to look out for

    We've got two things we're working on that we expect to be released by the end of April. We're wrapping up a significant update to Cosmonuts. Then there's a new game prototpye for Android that we'll be publishing.

    The update to Comonuts will include new nut types, new art, and a selection of levels for your nut gathering pleasure.

    The new game prototype is a two player head to head game that plays on one device. The prototype will be released with very basic art, circles and lines. It is also being released as a two player only game, although planned future versions will have single player modes. We're putting this prototype out to get feedback from players and have plans already to make a more complete version.

  • GDC

    Tavi and I were at GDC two weeks ago and we had a blast. We attended as CA's, which we both plan on doing for the forseeable future. Meeting lots of great people and hearing good advice always gets us really motivated. 

    Inspiration always strikes during GDC, with so much exposure to new and different ideas. This year simply mishearing the name of another game inspired us to make a rediculous new game, which we'll blog about another time. We're really excited about it and can't wait to get a prototype together.

Hello World!