This soundtrack is my own special take on the vaporwave genre. All tracks are in MP3 format and encoded at 192kbps. Includes 19 tracks in total.
Overall these are distinctly different than the muzak tracks heard before the action parts of the game and deserved to have their own album like this. Some are more upbeat for action scenes, while others are more sad to compliment the player failing a mission or dying.
There is a 10% launch sale so grab it now and let these retro beats soothe your nostalgia. ːbrewskyː
http://store.steampowered.com/app/571651/
Muzak soundtrack released!
Includes 14 tracks that have been remastered from old records and tapes. All tracks are in MP3 format and encoded at 192kbps.
These tracks are heard on the radio during the first level of the game and while traveling to Pluto (before engaging the FTL drive). They are taken from old record and tape recordings my Oma singing from the 50's and 60's. They are digitally remastered for use in the game, and are now available as a standalone soundtrack.
http://store.steampowered.com/app/571650
Trading cards released!
The steam trading cards for Space Trucker have been approved and released into the wild as of today. I think you all will like the selection of backgrounds and icons I created for the game and market place.
The foil badge in particular is quite special! Happy holidays and happy new year! See you all in 2017.
UPDATE 1/2/17: Released the Muzak soundtrack today also on Jan 2nd. Includes 14 tracks in total that are from the radio in game. There is another soundtrack with electronic music that will be released later.
http://store.steampowered.com/app/571650
Day 1 Patch
Infamous day 1 patch is ready!
- Fixed an issue where a couple of barrels could trap players behind them on Charon. They have been removed to stop this from happening.
Happy Turkey Day Also!
Alternate Timeline
Imagine our local galaxy from the top-down perspective, a bird's eye view if you will. You see Earth, the pale blue dot. To the left you have Mercury and Venus, and of course our star the Sun. To the right you have our moon, Mars, and the rest of our collective "backyard". A playground for possibilities which we will use as our canvas for the game.
Some of the first thoughts are about ways people would move around this space. What would they be doing? Who would own what? This can be a pretty daunting task, especially when you have the void of blackness looking back at you when you start up the map editor at the start of a project.
The only way to combat this void is with planning! This is where things you have probably heard of before like a GDD (Game Design Document) come in handy. The probability this document will remain the same throughout the entire course of the game's development is almost zero. As a project evolves it is natural for things to change, to realize new possibilities, or find better ways of doing a particular task or feature.
The Cold War is something that is a distant memory for most. If you were born in the 80's you might remember your parents talking about the wall coming down or perhaps seeing images of Ronald Reagan on television. Anybody from that era will remember the tension, mutually-assured-destruction, underground shelters, drills in school making you get under your desk in a simulated nuclear attack, and the monthly air-raid siren test always reminded you everything could change at a moment's notice.
When designing a story and lore for it the best way is through the people that lived and worked there. Allowing the player to traverse through this medium with their assigned task while observing and using their imagination to fill in the blanks you intentionally leave. The largest problem in all of this is scale, meaning the complexity of the idea and how much you decide to show and talk about. The below graphic is a layout of every planet and moon in our local galaxy. The size of each moon is taken into consideration, nationality of the country that operates bases there, and other locations like space stations that would be between these locations.
One thing that might become apparent right away is that we have A LOT of locations here. Remember, this is not meaning we will create every single one of these locations but it allows us to build a path through them. In the case of Space Trucker the goal is to travel home to Earth from the distant [s]planet[/s] body Pluto, the mechanics of the game are the grid system used by machines to trigger random events, FPS combat and exploration, and operating your ship to plot a course to the next planet with the intent to continue the main storyline.
Being able to see all of these locations helps us though with the planning process. Now that we can calculate distances between these places based on the distance from the sun in millions of miles. These calculations are used as the basis for an enumeration in the codebase that defines these distances so the ship simulation can calculate things like distance traveled and quantify it as a value to the user, consume resources for X amount of distance traveled, and basically becomes the basis for designing something like a space truck.
Before we get to far ahead of ourselves let's take a look at what a possible space truck might look like. Since it is supposed to be a truck we merge the idea of a cargo container ship and a normal semi truck you would see on the freeway together. The scale is increased to that of a Saturn 5 rocket and then we start to carve out various areas inside of it for people to live and work to get a feel for what it might look like.
Now that we have an idea of the basic requirements for moving around the galaxy, nationalities at play with the Cold War theme, distances to be traveled, a course can be plotted through the system. Early versions of the game allowed you to travel to any location and had randomized quests but this quickly proved to be boring, as operating the space truck quickly became a task with no end, traversing hallways and putting out fires in a desperate attempt to keep the ship alive.
It was part of the original idea that drove us to get this far, however, this is not the type of game that we have in mind it should be more focused and have a straightforward path the player can take. If we can populate this world with enough interesting data points (IE people to talk to, things to do, places to explore) then this open world style of gameplay would be suiting but as a single individual you only have so many hours in the day to complete any given task.
So the problem with these early versions of the space truck proved to be a scale problem, just like having 20+ fully detailed bases can also start to seem daunting when you think about how you are going to have to place every door, switch, light, and thing the player does. Speaking of the player we want them to be able to kill enemies that try and prevent them from reaching their home on Earth so let's design an arsenal for them to use.
Things are starting to look much brighter now. We have a galaxy filled with locations, nationalities, a great war, weapons for the player to use to stop people in their way, a space truck for them to drive. Now we need a purpose. When will all of this take place? In the future? The past? Since the Cold War ended in the 90's and was related to the Space Race we could take a leap of creativity and think about a world where the technological advances of each nation didn't stop at the moon landing.
With this in mind we use the moon landing as a catalyst for further expansion in the galaxy. Furthermore, we need to excuse several activities, explain how so many bases could exist in so many places, and why are you killing people?! How is it OK to teleport into a foreign base and steal their technology?
Under the pretext of war several of these problems cease to be just that, but wars don't just start for no reason we need to have fuel for a fire that will burn hotter than anything the human race has ever created. So we need to create a reason for such technology advancement to take place, and a reason for competition and fear for each other to go well beyond anything a few nuclear warheads could manage here on our own planet to ramp things up a few notches. A basic timeline of events can start to be constructed, starting with the moon landing where it would have normally ended.
July 20th, 1969 - Neil Armstrong walks on moon.
May 5th, 1970 - USSR invents fusion reactor.
June 21st, 1973 - USA invents faster-than-light (FTL) drive.
August 5th, 1976 - First interplanetary starship constructed.
March 31st, 1979 - USA establishes first permanent colony on Moon.
September 3rd, 1983 - USSR begins commercial mining on Mars.
April 8th, 1985 - Entire solar system claimed by varying factions.
February 20th, 1987 - First commercial starships for transport, and luxury.
December 23rd, 1991 - Boris Yeltsin assassinated. World War 3 begins.
November 5th, 1992 - Earth rendered uninhabitable from nuclear war.
January 1st, 1993 - Today.
In this version of events we have a long buildup period of 22 years after the creation of the first permanent colony on the moon by the USA. In contrast, the end of the world occurs in less than a year clocking in at 319 days before all of Earth is rendered uninhabitable by nuclear war.
The final version of the game which is currently being showcased and is being worked uses a timeline similar to this with a few key points changed as development continued in this area. Remember, the goal here was to create a sense of time and purpose as the backdrop for the rest of our adventure to take place on.
With all this information at our disposal we can proceed to create more detailed descriptions for each location in the game the master list of them defines. The timeline and nationalities gives us some introspective into who is against what, lots of documentaries and reading about the Cold War will give you TONS of inspiration for interaction between characters and ideas for missions and quests the player can complete. Here is an excerpt from a document showing off detailed information about the facilities orbiting Pluto.
The information from each previous step we have taken feeds into the next one. We use the timeline to establish when a given facility might have been constructed in relation to another. Their sizes are also carried along so that it can be kept in mind while describing the facility. Sometimes you will draw up a blank for a given place, if nothing comes to mind just mark it with a TODO and keep going. Get all those crazy ideas out of your head and into the design document so others can read it!
This is the last article about game development for Space Trucker. It was great to be able to share all of these expeirences with you all.
Space Trucker is now available on Steam !
WE LOVE WOLVES is proud to announce that our 2nd game known as Space Trucker Is now available on Steam ! Pick up a copy of Space Trucker today by clicking below and add it to your cart!
http://store.steampowered.com/app/533320/
Space Trucker is published by WE LOVE WOLVES and it took us only 16 hours to get the game approved to be on Steam thank you everyone in the group who voted for us to get on Steam! Space Trucker has 18 achievements currently we also are currently working on the Steam trading card features which will come out in the next few weeks. Join the official game hub which can be found
Here by clicking ‘Follow’ thanks a lot everyone who voted on the game I highly recommend you buy the game today
Launching @ 11PM PST
Entity Creation
Creating a new entity starts with the idea of what is needed. If the developer is loading up the engine tools without any clear indication of what they should be doing then they are wasting their time. Sometimes this can be useful when learning a new engine or figuring out the best way to implement something.
However, when we are working on the game and trying to get actual work done it is important to have proper game design documents to support the work you are doing so time is not wasted and the best game possible can emerge from the development process. As one stop shop indie development studio time is our most valuable asset, we must make proper use of every hour we use to maximize our offering to the players.
We will go through the motions of creating the fusion reactor that is used on the player's ship in Space Trucker. It is a familiar object, is seen often, and can be interacted with. There is a model component, a GUI component, and this object will also be plugging into the grid network we constructed to pass messages around between machines. Below is an example of a mostly completed reactor, and what it would look like when it is powered on and running. There would be another state for when the machine is offline also.
The next part is where prior design and research really can save us time. For Space Trucker all of the machines and their GUI components were designed ahead of time in programs unrelated to the actual game engine such as Pencil; which is a program to plot out GUI's in this sketch like format without any code to get a purely visual idea of what a GUI might look like based on requirements gathered from whiteboard sessions that determined interactions between the machines.
Below is a graphic that shows the sketch prototype that was made on the left, and on the right the completed GUI in the resource editor used by the engine. It is nice when expectations can match what is possible this closely, sometimes you might not be able to get as close to this but what matters is that we had a clear direction about what we wanted before we even got started.
With the entity and GUI designed now it is possible to perform initial placement of the object on the map. In the screenshot below we have the players ship with the hull made invisible so the guts of the ship are clearly visible and easy to work on. Our fusion reactor is in the back near the middle, there is another machine that sits in front of it which holds the reactor monitoring GUI we built in the previous step.
Moving on to the next phase of entity creation we need to plug the machine into a special alarm panel called an annunciator panel. This is basically just a fancy word for an elaborate alarm clock that is tied to various machines and triggers when a particular event happens that is pre-programmed into a module used by that given light.
So for example, the REACTOR DAMAGED plate in the annunciator would not turn on or activate when the reactor was damaged unless it had a reference to the one in the game world and was able to periodically query the machine's current state in a way that would not waste performance every tick in the game engine. The same conditions would apply for plates like REACTOR OFFLINE, and of course REACTOR ONLINE in the case of the reactor and similar conditions would apply for any other machine that would like some special type of alarm like this.
The colors on this panel represent different levels of warning. White panels are purely for informational purposes and do not trigger alarm state on the ship. Yellow is something the player should keep in mind for the near future but typically does not indicate immediate danger unless the warning is for something like low oxygen. Red is the most severe plate color, meaning action must be taken right away to prevent damage to the ship or the player themselves such as the case as running out of oxygen to breath or being left stranded in space because the player ran out of water to fuel their ship.
Now we have many of the parts that make up our machine completed and in the game in one form or another which is a great step up from just having them on paper as conceptual ideas. The reactor can be seen in the shot below in the right side behind the monitoring tool for it which is not active in this shot because none of the GUI's are active while in the map editor and only get loaded when the game is running because that is when the logic for the machine is instanced and running and can actually do it's job.
An entity in the engine is a text based affair. The use of things like binary formats or special encryption will only make it harder for you to work on your own game in the future and it also makes it harder for players to make modifications to the game which might actually make it better! In this regard there is no reason to prevent access to these files, or use some convoluted system that cannot be read with something as simple as notepad.
It is not important to know every property in this file, it is more about how the structure of an entity in the engine is nothing more than a plain text document which removes some of the mystery from how something like this gets constructed in the first place. It contains all of the information we need to render the object and create a class to control it in the game world. Other properties like static indicate that the object doesn't move and will stay fixed.
This file is created automatically by the resource editor when we create a new entity using the built-in wizards. It is then very straightforward to add attached objects to that entity which can each potentially have their own class controlling them along with the base initializer class which the entity will be casted as during runtime. Editing an entity will update this text file with the latest definitions which the engine can then use to create the entity at runtime.
The last part of our journey to create a new entity ends with the tasks of programming the custom logic for the machine itself and the GUI proxy wrapper that will look at that machine entity on the map during runtime and update itself whenever the data it changes.
Another way to explain that paragraph above would be that the machine has logic to power interactions with other machines on the grid network, and the GUI is not a machine but rather more like an elaborate sensor. However, it is possible for the sensor to take energy also. This is meant to simulate conditions in reality where a digital sensor requires electric power in order to perform it's function.
The GUI for the fusion reactor is pretty straight forward once you understand what is happening for it to actually create the energy. Water is split into base molecules, then refined with greater amounts and split into a 50/50 mix that becomes the fuel for the reactor. This deuterium-tritium gas mixture is flooded into the reaction chamber and then spark ignited using a massive amount of energy from the ship's battery reserves.
Once the fusion reaction has started, the gas is pumped in slowly to keep it burning and supercritical. The heat generated from this is harvested as steam which is created from intense heat of the fusion reactor boiling the ship's water reserves and allowing that to turn a turbine which generates electrical energy that is then stored in the ship's battery for consumption by other machines.
The buttons are functional and allow the player to stop and start the reaction, however if there is no water reservoirs or not enough power to spark the fusion reactor then it will not be able to create the initial spark to get things going which would leave the player stranded meaning they will have to keep careful watch over their water reserves as they travel around the galaxy.
Next post we are going to talk about dynamic music and how it is used in the engine to set mood and tone for a given part of a level.
Little Black Book
Have you ever gotten a really great idea at the worst time possible? Such as while stuck in traffic, or on the train where you cannot take the proper time to make a note digitally or otherwise. In moments like this you try and remember the idea long until in full until you get someplace you can write it down. Some of the best ideas for game development and new projects have come from the most unrelated of locations or objects.
It would be rash to say this is not an efficient way to get new ideas down, but it is agreeable that something is better than nothing. What matters is that the idea was written down and archived for later use, without this it would be lost in the sea of day to day activity.
For each of the game projects I have completed there is typically a notebook like shown below where all of the ideas will go during the early stages of development. Referring to stages of the game so early on that it doesn't matter to create tests, whiteboarding, or even artwork.
The first couple of sketches here are the process of trying to figure out the best way to represent the machines on the player's ship and on levels within a 3D space. This work ended up being used in part of the grid network which allows the machines to communicate. Early in the brainstorming process it is important to remember that actual implementation details are not as important as getting the ideas themselves into some sort of medium other than our thoughts. Notice the date of 6/28/2015.
The next batch sketches show problems that arose as the grid network became more mature over the next several months and work shifted from how would it work and the hypothetical into implementation details which is a very nice sign indeed. At this point the problem was how to pass messages around the grid network without consuming too many CPU resources per tick in the game engine.
Based on those requirements the design pattern chain of responsibility eventually became a possible solution to this problem, it was drawn out based on what the pattern is capable of doing since forcefully breaking it would defeat the purpose of even saying it's name. The entire point of patterns in programming, especially an object-oriented language like C# is to give other developers the ability to easily understand your intentions and to solve common problems we all face as developers (such as cache invalidation, and naming things).
One of the other problems these pages address is that of too many requests being made to the grid network using the chain of responsibility pattern. Eventually it was determined that a mixture of queues and circuit breaker style throttling would allow the engine to function at fastest speed possible while also maintaining enough control over the machines for it to actually be of any use.
Finally, the last couple of pages are about a different subject entirely. These pages are related to an inventory system which is used to keep track of items like weapons, ammo, key cards, and any special quest items that might be required to complete a given objective.
There is a further distinction between GUI elements that work with the inventory system also. An example of this is a slot in a GUI that requires a particular item to operate, a keycard panel would be something that uses this to provide a functionality to the player. Another distinction is using the array index for inventory items as slots which are also used in the binding system and mapped to numbers on the player's keyboard by default from one to zero.
Do any of you have a little black book like this? Do you store your ideas in it? Do you find it better to put your ideas into paper form rather than digital? These are some of the questions I would like to ask the community in return since you don't even need to be a developer to use a notebook like this to to keep those creative juices flowing.
Next post we are going to talk about entity creation and how new machines gets placed into the game. This will require several pieces of tech Space Trucker built, editing tools, some creativity, and in-game 3D GUI's!
Static Lighting
The size of levels in Space Trucker requires there to be several hundred or even thousands of lights depending on the scope being obtained. In order to maintain performance it is necessary to find a reliable method of pre-mapping the lighting data that would normally be rendered in real-time while the game was running.
There are other rendering methods such as deferred rendering but these are not silver bullets since you lose out on things like multiple transparencies (looking through a window, that looks over the street, into another window into another building) would be impossible using deferred rendering so this is not a valid way to solve our problem since many of the levels have setups like this where windows and doorways may look into other areas, that will contain windows that look into other areas and so on and so forth.
For the development of Space Trucker we will look to older ways for guidance in this matter. Before the age of using dynamic lights and shadows for absolutely every dynamic entity on the level there was a method known as pre-baking or static lighting which would create a 2D overlay of your lighting data known as a lightmap. This data would then be used at runtime, combined with the UV unwrapping capabilities on the model, and the multi-layered material system we can lay the baked lighting image on top of the diffuse texture used by the level to make one big happy material shader for our level that can be used at run-time.
Above is an example of the map editor compiling the lighting data for a given level, the black space on the right is the actual lights being baked into the 2D image for later unwrapping. The reason it looks like a circuit board is because the levels textures are also stored this way. Every wall, floor, and ceiling is texture mapped from a single image which makes loaded very fast and allows for static lighting calculations like this to be possible without having to store the data for each part of the level in different files.
The insanity you see below is what the static lighting manager created for our level, this image is laid literally right on top of the diffuse texture for the level and then UV unwrapping allows the lighting to appear as we intended with the color parameters and roll-off amounts specified by the level designer.
It is worth noting that compiling even a simple image like this can take upwards of 30 or 40 seconds depending on the complexity of the level, how many times light bounces off materials, shadows that are created by light passing through various other entities and how that will be plotted out in the 2D image takes an immense amount of computational power. All the power that would be wasted during runtime of our game, is being done ahead of time now and stored for fast access since it can all be loaded into the computer's memory and not polled from the disk unless it is actually loading such as a level transition which is fine and normal at that point.
Below the drop here are some examples of levels with static lighting being faded from enabled to disabled. It is pretty obvious how much detail and life this can bring to a space, with the static lighting it is possible to have as much lighting as we want on a level with no limits on how many lights there can be.
The entire image that is used by the static lighting manager is only about 16MB worth of memory when compressed using a DDS file and the DX1 format it provides. DDS stands for direct draw surface, and is how the GPU is able to see images as byte arrays in it's own video memory making it easy for things like shaders to manipulate it in real-time before being rendered to the screen.
Next post I am going to talk about the little black book which stores notes, scribbles, ideas, and generally is the reason most developers are able to remember anything at all!
