The Vacuum

A simple 2D space adventure with pseudo orbital physics.

So this is my current project, I've been working on it since August 2015 and is available now on itch.io

https://ched80.itch.io/the-vacuum

It's a 2D space adventure game where you build your ship, assemble your crew and head out into the cold vacuum of space. You'll take on missions for cash and play your part in shaping how the solar system takes the crises that appear.

Each play-through the randomly generated, although a seed can be set so that the same map is generated each time. Although randomly generated, not all elements will be added to each play-through. Some elements are unique and will appear seldom, these elements include planetary specials, crew specialities, NPCs and news stories.

Here's the current work-in-progress.

My aim is to update this post each week to explain my progress and post the odd demo and video and screenie. All feedback is appreciated.

The game will have the following features:

• Random worlds - each play-through has different challenges, worlds and moons to explore.
• 2D, multi-body, orbital physics - perform gravity sling shots and travel between different planets.
• Light RPG elements - as you progress you level up and improve your ship's and crew's abilities.
• Random events - each play-through will set off a sequence of events that will change the game world depending on how the player resolved the crisis or not.

Well almost a week has passed, but very little has happened on this over that time what with Christmas and all that. I've tinkered a bit with some of the sounds, fixed a little bug with the weapon segment, but nothing major. So rather than post nothing, I thought I'd give a little bit of history of what's happened from August until the end of this year.

I had the idea for a simple space trader early in the year and I started prototyping the basic mechanics with beads, dice and a paper hex-board. I always wanted to include realistic orbit mechanics so after the board prototype I expanded the idea with another prototype built in Excel - i do a lot of prototyping with Excel as I find it easy to set something up and then tinker with the formula before I start any proper coding. So after a few weeks of getting to grips with orbital mechanics I figured I had enough to start the game proper.

The first month went well, I implemented the ship designer and the basic trading features, but then the headaches appeared.

The first pain was to solar system builder. I had this idea of implementing an acrete model for building the solar systems. This is where you start with a big disc of gas and particles and you randomly add tiny planetesimals at random distances from the sun and with random eccentricities. These planetesimals collect all the dust in their path and, if they get big enough, collect some of the gas too. The system basically needed about 300-500 planetesimals added to create a system resulting in 4 or more major planets, plus their moons. Generally it was a poor design choice. The algorithm took ages, and given that the players will just want to jump into the game, waiting a few minutes just to create the map was never going to be good enough. So after about 6 weeks of coding and tinkering I decided to scrap the method completely and simplify the system builder completely. It's not as geeky, but the end result is much better for the game.

The next pain was the orbital mechanics. The engine I'm using has a limitation that the float variables are only maintained to 7 d.p. This basically means you cannot model something the size of the solar system and maintain sufficient accuracy for the various spacecraft I wanted to implement for this game. So I had to shrink the solar system to about a 200th of it real size. Then I had to play about with the gravitational constant so that the planets orbited the sun in a reasonable time. I say reasonable because I didn't want to make a space simulator. I love space sims don't get me wrong, but I wanted the player to be able to explore this system (relatively) quickly. So I adjusted the values so that travelling from Earth to Mars only took hours, rather than months. But these were only minor head-aches. The real problem was getting the two-body orbital mechanic formulae to work for multiple bodies. Basically I was trying to get the game to re-calculate the two-body orbital parameters every time the player used the thrusters. Then when the player reached the planet's sphere of influence distance recalculate the parameters again, but with the Sun, or the Moon as its new primary node. Anyway, basically it was all getting too complicated and the calculation was not particularly quick so in the end I ditched the two-body formula and opted for a permanent multi-body solution. The main difference was that, with the two-body formula I could perform time-acceleration really easily since the orbital positions with respect to time were all mapped out. With the multi-body solution, accelerating time meant the orbits were very unstable when close to a planet. So i soled this, by simply restricting the maximum time acceleration relative to the distance to the planet. It's not ideal, but I think it works ok.

Now since I've removed these problems, the game has moved forward nicely. I'm currently thinking of how to implement the mission system, but I'll let my brain cook that one up for a few days while I work on the A.I. and fix the segment upgrade feature.

Laters.

So this week I was meant to be focusing on the A.I. instead I procrastinated and spent the first half of this week on the U.I.

I always hate coding A.I. For all my previous games the A.I. has always been disappointing, to me anyway. I always have this idea of creating a nice simple, robust, but difficult to beat A.I. but I always feel the end result falls short. So this I wasn't looking forward to coding this part of my game. So I've approached the A.I. differently this time and I've started with a state diagram and how the different states are connected. Each A.I. has effectively four states: IDLE, DEAD, MOVE or SHOOT. Some A.I. are fixed to DEAD (expired spacecraft, asteroids) while others will not shoot until shot at. So at the moment I've only just started coding the movement state, but part of that delay was because I had to re-code how the game was hanling A.I. data. I had made the mistake of limiting the game to handling only one enemy, but then I had the idea that you could capture unmanned probes by reprogramming them and then this thought made me think you could have a number of probes following you about as protection and this would mean the code would have to handle more than one enemy. also fighting a fleet of enemy craft will be much more fun than just single enemies all the time.

Anyway the U.I. was annoying me so I distracted myself by repositioning the resources to the left wall and collecting the action buttons along the bottom. I also moved the time acceleration and thrust icons to the top of the screen. I think it looks much better now:

<a href="<img src=" http:="" s1156.photobucket.com="" user="" christopher_chetwood="" media="" screenie-1_zpsfhfjwv3p.png.html"="" target="_blank"></a>

I also changed the player's trail and future path markers from dots to a line, which i also think looks much better:

<a href="<img src=" http:="" s1156.photobucket.com="" user="" christopher_chetwood="" media="" screenie-2_zpsnlx3p6zn.png.html"="" target="_blank"></a>

In other news my Steam controller arrived today so I'm a little bit excited about using it. I'm planning to add a number of control methods to my game. It current has Keys+Mouse (which will be the Win and Linux defaults) and the Android version will have touch controlls, but I'm also adding support for 360 controller and (obviously) the Steam controller.

This week I faced my A.I. demons and I've implemented most of the A.I. functions I think I'll need. Based on the state diagram I produced last week I just got my head down and worked my way through each of the states and the state changing stimuli.

A friend of mine took a great picture of the Andromeda galaxy and said I could implement it into the game. So've I've replaced the old back drop with his picture and I think it looks a lot better.

I also changed how the scanner ranges were shown. To explain, scanners have two ranges, a range at which objects can be seen and a smaller range at which objects can be classified. Originally I was just using a simple circle drawing command, but I've repaced that with a scaled sprite, which I also think looks a lot better.

I had a quick trip to Madrid and back this week so I managed to sink quite a bit of time in and I tinkered on a few of the missing features.

The first was an alternative to the random event system. So preiously the only way to interact with other probes and rings was via random events that put random A.I. objects on a collision course with you. But this doesnt give the player much opportunity to seek out battles. So this week I implemented an alternative event system where random transmissions are placed randomly around the player's location. These transmissions either come from active probes or rings, but the player will have to change course to find them. The transmissions are only identified to the player via a little satellite dish icon on the edge of the scanner range pointing in the direction of the signal.

You won't know how far away the signal is, nor what is creating the signal (i.e. is it friendly or not). One the signal is within the scanner range it behaves the same as the current A.I. I feel it adds a slightly different direction for the player to take now. If they have designed a battle hard craft, they might want to seek out transmissions in order to collect materials and cash, whereas if you have designed a more passive craft, they will want to avoid or just ignore the transmissions.

Later I will probably expand the transmission system to handle mission objectives. Say you take on a mission to recover a lost probe, the direction towards the mission objective could be handled in the same way as the trasmissions, but I will probably use a different symbol so you can easily see which direction to go in.

I also started expanding the stats collected by the game, so that the "game over" screen can provide a bit more detail on what you achieved in the play thorugh. I'll also be using the stats to unlock achievements, but I won't be thinking of the achievements until the game is nearly finished.

I added a number of upgrades into the game. Up until this week there had only been two, a power boost and an oxygen boost. Now I have eight:

• Cash +25%
• Food +25%
• Food -25%
• Oxygen -25%
• Power +25%(this already existed)
• Power -25%
• Science +25%
• Waste +25%
• Waste -25%

It might seem dd that you'd want an upgrate that Waste increased waste production, but there will be the odd port that will pay for Waste. I've decided to change the look of the upgrades. Originally I wanted them to look like bits of equipment, but after I had made 3, it wasn't obvious, looking at them, which upgrade boosted power and which boosted science. So I've simplified them so that boosting upgrades are green, reducting upgrades are red and each upgrade has a hadly symbol indicating which resource they affect.

I'm thinking of putting up the current state of the project next week for people to take a look at and let me know what they think. I'll then update it each month fixing bugs (probably adding more), adding features and content that sort of thing.

I was a bit ill at the start of this week so by the time I was able to pick up development this week, around Wednesday afternoon, it was going to be limited what I could do before my next post.

Nevertheless it did enable me to take a look at my game with fresh eyes and I've realised it is way too early to release anything for testing. I know I said last week that I would I wanted to get something out just to get some initial feedback, but I've realised if I put the current version out it would probably do more damage than good. I mean there is no tutorial built in yet and I don't explain what the controls are anywhere in the game. That would be fine if ths was a traditional platformer or something, but I've got all sorts of little commands and mechanics built in that just expecting the player to figure out what keys to press is just unfair.

Plus also I've tested the combat several times and it not very balanced and not fully debugged yet so I currently harms the flow of the game. I'm clearly trying to fix it, but it's better I hold of releasing something until this bit, at least, is fixed.

So what I did manage to do was add in some particle effcts when thrusting, just to make it more clear that something is happening. I'm also adding particles when probes and rings are damaged, but there are still some bugs in this at the moment.

This week I began implementing the code that will support the missions system. So this took a fair few days and I've not finished coding or debugging it yet. It's not a ground breaking mechanic, but it's a fairly core element of the game. Through missions the player will align themselves with one of the factions in the game as well as earning a bit of extra cash.

So to support the mission code I've also added the first five groups to the game:

• The Nyopean Union - A huge transnational entity that originally founded the majority of the original colonies and continues to fund them. They are a democratic group primarily focused on encouraging trade and maintaining peace for the benefit of the homeworld nations. The Union is over 700 years old. The extra-terrestial colonies are not members of Union, but are actually owned and controlled by the Union as a whole. The colonies are just becoming self-sufficient and want to control their own population which is leading to the current political unrest throughout the system.

• The Mechanium - A small group who's philosophy lies in the belief that man's destiny lies in technology. They encourage technological enhancements of the human physical frame and have a string trust in the use of A.I. systems.

• Gene Liberty - A small group who believe that man can only progress through the art of genetic engineering. They believe creating biological solutions for mankinds problems is a far better prospect than a technological one.

• The Pharmatopia - Another small group who believe man can only progress with the use of chemical injection and designer medicines. While technology is seen as essential it is secondary to a chemical based solution.

• EcoHarmony - A small group who believe man has pulled to far away from nature and must return to more harmonic relationship with the planets we occupy.

The game will present the player with a random selection of missions from some of the groups listed above, there will also be private missions. By taking on a mission linked to a group, you will influence the strength of that group and, in turn, how the game's story progresses.

For example, if you align yourself with The Mechanium by performing a lot of their missions, The Mechanium will gain in strength resulting in a story arc that is more focused on The Mechanium's agenda. Simliarly, your relationship with the group will improve and you will gain access to unique Utilities that you can equip on your ship.

I haven't started work on the story arcs yet, although I have some rough notes scribbled somewhere.

In other news I am expanding the weapon system to incorporate 5 weapon types:

Missile - already implemented, but these will now all be homing missiles.

Beam - These laser weapons will instantly hit, but will inflict lower damage.

Particle - Similar to lasers, but they apply a field around thw target and the damage is inflicted slowly and decays over time with the field remaining even if the beam is removed.

Plasma - already implemented, these will be sped up, but are effectively dumb energy balls.

Mass - already implemented, similar to plasma these will be slower, but will inflict higher damage.

This week I (nearly) finished off the weapons code for five types. The only element missing now, is the particle weapon type. At the moment particle weapons acts like beam weapons delivering instant damage to to the target (assuming your aim was good), whereas particle weapons deliver their damage slowly while the particle field still exists around the target.

I need to alter how the ray sprites are handled for this to work, so I've pushed that into next weeks to do list.

Apart from the weapons, I finally fixed the particle bug that meant whenever you hit an enemy no particles were shown. it wasn't a game crippling bug, but it annoyed me each time I was testing the weapon code.

Another thing annoying me is not being able to save my ship designs. so i've started coding a load and save mechanism, but I only started that today so I'll finish that off next week.

I've also be working on generating character images for the job cards. And by generating I mean going up to people at work with a selection of hats, sun-glasses and bicycle likes and asking them to wear something while I take a photo of them. Luckily I work with some great people so they won't mind me posting a few here.

I always write my blog on the train journey home. While I wait on the platform I usually think about what I've achieved this week and this is the first time I've really struggled. I seem to have dabbled this week rather than actually achieve anything. Which is a worry as I'm still way off finishing this.

I managed to add a few more faces to the character pool. I'm up to 30 faces now, but I'd still like a few more. Ideally I'd like 100, but i think 50 is more realistic.

While I was doing that I decided I didn't like the way the faces were presented so I decided to create some frame images, one for each group to place over the faces on the job screen. This meant selecting appropriate fonts for all the groups and that meant also installing a shed load of fonts onto this machine. So I ended up wasting 2 days messing about with fonts, but I am pleased with the result. They are better than the placeholders I was using, but I'm not completely satisfied with them.

I also dabbled with creating some music for the game. I'm happy with the Kevin McLeod title music, but I want to create my own stuff for the actual game. But i did't get very far this week. It's been a while since I created any music so the stuff I created wasn't particularly great, but the more I doodle the better I'll get.

I did manage to implement the save slots for the rings. So you now have 3 slots to save designs to. These can be re-used for different play-throughs and won't get wiped if/when you die in-game.

I still haven't fixed the particle weapon code, but I am making progress; I created the 'halo' sprite that will stay over the target when hit and I have started adding the code to support the weapon and I'm hoping for the next blog entry I'll be all done. But I'm not promising anything.

This week I began to code the final major element of the game; the news events. These events will serve to present the story arcs of each play-through. every 48 hours a news story will break. Each story will have one of 6 possible endings: failure or one of the five groups succeeds. The conclusion to the story will be presented 24 hrs later and the conclusion selected will be based on the jobs the player completed in that 24 hour period.

For exmple, one story will have an infectious disease break out at a colony. If the player has been completing jobs mainly for the EcoHarmony group, the EcoHarmony ending is selected. In this scenario the colony is saved, but the quaratine imposed prevents any trade with the colony for a random period of time. Had the player failed a number of missions, the story would conclude with the colony surviving, but becoming infecious meaning there is a risk of the player becoming infected if you do trade with the colony for the rest of the game.

The idea is that the news stories permanently change the landscape of the world and the player can influence how the world is changed.

The stories will be a mixture of random events, such as the disease story, and group specific stories, where the player can influence how the story of particular groups plays out. The group stories will follow a particular path each time, but will be interspursed by random stories.

In other news, I finally managed to complete the coding of the particle weapons, which I'm lad to get off my back as it means I'm now able to script all the weapons for the game now.

I also fixed a few minor bugs that were hanging around and adjusted the balance on some of the segments.

Generally I'm making good progress and the majority of the stuff missing now is content. So over the next few months I'll be creating all the little sprites for the unlockable equipment and scripting all the story arcs as well as sketching out some music, which I'm still working on.

Here's a video of the current build in action.

So last week I got ahead of myself saying this thing was basically ready and all I needed to focus on going forward was content and media. Yeah, I was clearly blind or tired because there's still a lot missing.

I had a sort of crisis at the start of the week as while I was play testing it I realised the game just didn't feel right. The combat is wonky and unbalanced, the orbit mechanics aren't fun, the ring designing is confusing and boring, the resource management is too complicated and I genuinely thought this might just be a comlpete waste of time. But I do believe in my vision for this. And I believe my vision is fun.

So I'm sticking at it, I just need to go back to prototyping alternative systems and find the fun of my vision.

The first thing I'm doing is stripping out the ring design system and starting again. I've redesigned the supporting structure graphics so that the ring is now ring shaped.

Secondly I've got rid of "segments" and "modifiers" as this was confusing to explain to people. So now we just have parts. Rather than being limited to 5 segments and 4 modifier, you can now put as many parts as you can fit or afford on the ring.

The key word there is afford. When you start the game you will have a credit of design points - each part costs points to implement on your ring. This is to stop you just putting all the parts on the ring. Each time you play through - whether you die or complete the game - you will slightly increase your desig credit AND you will also unlock new parts to use.

Placing the parts is also more fun with the parts dropping into place around the edge of the ring - it's not ground breaking, but it makes the designing process nicer.

Appart from implementing this, I've been converting the existing segment and modifier images to the new system.

The next thing I want to re-tackle is the orbit physics but that'll be after my holiday.

I basically spent this week ripping out code and replacing it with the changes I wanted to make to the ring design system that I prototyped last week. Having spent the previous could of months building up the game around the old system there wasn't much not affected by the change and it took forever to get the thing to compile in the end. Was forever finding bits I'd missed or old functions that no longer worked properly because of the new system. The loading system for the design slots still doesn't work, but at least the game is playable again now.

And it's a better playable experience for it. The change is a lot simpler to explain:

You have 7000 design points to pick items to design your spacecraft. As you progress through the game will will get new and improved items to add to your design.

As oposed to:

Pick 5 segments and 4 Hub Modifiers. as the game progresses you will recieve segment modifiers that you attach to specific segments to boost their stats.

The designer looks better now too:

I need to centralise the filter buttons at the top, change the node image and the yellow division line, but otherwise I'm happy with it.

I'm also thinking of ditching the oxygen resource. I think it's a difficult resource to manage and needlessly restricts player movement across the map. Having one less resource also simplifies the game for the better freeing up player to concentrate on trading and missions.

At the tail end of this week I started working on improving the orbital physics. At the moment it all feels a little slow sling shotting between planets and moons to reach other planets and moons isn't as fun as I feel it can be. So i'e been building a small prototype to try out a few different things - it will probably mean a change to the map size, the planet images and possibly the speed at which time runs, but I'l know soon enough.

I'm also taking the next two weeks off the this game so the next update will be on April fool's day :)

This is just a short note to say this project isn't dead. I'm still pasionate about completing this project.

I had some real-world things that prevented me from working on this for about 2 months, but since then I've been converting this from AGK Tier 1 code (a version of basic) to AGK Tier 2. Tier 2 uses the AGK libraries in c++ so although I've not been progressing and tuning the mechanics I have been spending slowly converting my basic code to c++.

The main reason for converting to c++ is to take advantage of the improved precision variable types and math functions which aren't available in Tier 1. This will mean I can generate bigger maps and (hopefully) improve the physics. But we'll see.

ow, I've been away for 49 days! crazy.

Anyway, since the last message implying I was converting this to C++, I've decided to abandon that conversion and stick with the current Dev Environment. Firstly, the conversion was a pain. It was taking me weeks and weeks to convert the 1000s of lines of basic in C++ and at the same time I was really learning C++ so I was making all sorts of basic errors and it would take be ages just to get the splash screen to work. This on top of still developing the game eventually took its toll so I've stuck with what I know.

Since that moment, I've re-made the orbital mechanics so that it is 100% more stable and much more fun. The future orbit propagation is now 100% accurate with respect to your eventual path. Previously is was just an estimate and so would change as you got closer and became more accurate. This made travelling between planets annoying as the orbit you thought you'd set up would ultimately be a lie and so you just ended up just firing the thrusters all the time. Now you can see all the gravity swings meaning you can save a ton of fuel by lining up a sequence of fly-bys to get to where you want to go.

You can also see the orbit capture of your target planet and the orbit propagation - as you can see in the screenie below.

I've also moved the crew onto the main screen and i've got a few ideas how they will interact with you as the play-through progresses.

This screenie also shows how the new missions are presented. I'm currently working on the scripts for the new missions so we have a variety of types of mission, not just take item a to planet b.

Last week has been good.

I've fleshed out the mission a bit and got the basics working. One mission type, the rescue type is basically missing completely as this needs some significant additional mechanics to pull off so I'll come back to that once I've tuned the core mechanic.

I've also fixed the mission duration code and updated how other orbital objects are generated. I've adjusted out the ring-screen is presented and enabled crew swapping to happen in that screen too. I also added the start of the crew and module upgrade mechanic. Every level that you research gives you one upgrade token to spend on a crew member or a module on your ship. Spending it on a crew member increases their skill and slightly extends their contract. Spending on your ship improves the effect of that module. Each level takes double the science points to achieve.

This, silent, video shows some of the mechanics in action, but I died before I could complete a mission, or get to the first science level.

Next week I will be focusing on sorting out the modules - i.e. re-building how they work, and implementing the crew conversions.

Still working on the missions. Thought it was better I complete all the mission types to get an idea of how varied the play-through feels. I want to avoid boring fetch and return type quests, although I realise there is a limit to the variety you can create with random missions.

Anyway, the most complex mission types will be the ones requiring you to land on a planets' surface. So I've spent the past few weeks building up a proto-type for the planetry landing mechanic, which I'm implementing as a sort of 2D physics platformer.

I apologise for the graphics - they're place holder stuff while I flush out the code. I also need to work on the procedural generation of the building placement as they really shouldn't float in the air like that.

Anyway, this should look a bit better next time

A bit more work done on the planetary landing. Here's a little vid of what it looks like:

The vid is very choppy and shows some premature which is a result of the laptop I was using for the recording - without the screen capture running it clocks a smooth 100+ fps.

Anyway - the key things you can see in this is the re-fueling after you land at at an outpost, the dust whirling up as you get close to the ground and the beginings of the characters walking across the surface.

Made lots of progress this week, mostly due to the 3 hour train ride each way to Manchester where I was checking out Play Expo 2016. So much progress was done in fact that I don't see the need to push the prototype any further. So next week I'll start the task of integrating the prototype into the main game. The biggest concern I have is that the landing mechanic is significantly more difficult than the rest of the game. I'm worried it'll be such a big leap in difficulty that it'll frustrate players. What I might do is offer a practice area on the main menu for players to practice landings.

The process of implementing the landing mechanic has gone better than I thought it would. It's technically working although I've noted a long list of bugs. I've also not linked it into the quest system yet so that's bound to cause me a few headaches. Next week will be more of the same, focusing on the quest system, fixing the bigger bugs and tweaking the overall mechanic.

I've had an idea for the ring invasion mechanic too, but I'll have to prototype it to see if it'll work.

This week was pretty productive, here I managed to link thelanding mechanic to the quest system. This needed a major change to how the buildings are placed, but I sorted this out too. At the same time I changed how the ground looks so that it matches the colours of the planet in the system map, which I think makes it look better and gives the game more continuity between the planetary travel and the landing.

As you can see from the image above, the building distibution still needs a lot of work as they need to be spread out more and have a wider variety. I've also changed the HUD and got rid of the debug text.

The whole thing is still overly buggy in such a way that it is game-breaking at the moment, but that's for me to fix this coming week. I'm also fixing the game saving functions as I've realised I've got so much to do in that area and I regret leaving it so late to sort them out. I've completed all the save functions already, so I'll be finishing off the load functions this week before heading back to bug fixing.

The load/save stuff is imoprtant as i'll need it to extend my play-through tests of the game. At the moment I can only develop in 45 minute blocks and this game takes longer than 45 mins to play through so in order to be able to test the game properly being able to save my progress is fundamental. Plus its also fundamental for when i'm in a position to realise the first version.

This was another code heavy week. I implement the load/save functions although I'm still having issues with the loading functions, but I'm sure Ill sort that out. I also fixed the game breaking bugs with the landing mechanic, so that was a major plus.

I also adjusted the ring building screen to change how the parts are presented and to tart it up a little bit.

For no reason, here are some extra screenies of part of a play through I was testing:

It's been a while since a did a vid of the current build so here's one:

I've been working on content this last week with updating the sprites for the ring elements and trying to write a tune for the landing sequence. At the same time I'm trying a few run-throughs to flush out the bugs, but I'm struggling to get past 5-6 minutes before needing to rage quit and fix the code. Which is a good thing; it's better that I find them than the players.

Whoa so long since I've posted here and probably one of the last times too as I'm moving, or have moved my blog over to the games' itch.io page now.

Which is essentially the purpose of this post really.

I'm finally at the stage of having something out there available for people to play. So I'd love to hear any feedback people have.

Get the game here:

https://ched80.itch.io/the-vacuum