Space Game Project

UPDATE: No time limit anymore, sorry if I disappointed anyone, I’m just going to make it as soon as possible.

WebGL Demo

Webplayer Demo

Current status:

Hello everybody!
So a lot of people say it’s hard to make money with mobile games these days, and it’s all down to luck, and that unless you’re making a freemium casual game you shouldn’t bother. Well, I’m going to try to prove that wrong. And I’m also going to try to prove it wrong that games need to take a lot of time to make.

I’m going to make a mobile 3D space combat game in a couple of months, sell it as a premium game and try to make back $1000 in the first month after release. I’ll be posting here about my planning and preparation, development, marketing and financial stats after release. Hopefully this will give everyone some useful insight into how to be successful (or not!) as a game developer.

I haven’t really made any games yet, so this is kind of a blind jump for me, although I have been practising modelling and coding for a couple of years now. I’ve been working on space game related stuff on and off for that time, so I have quite a bit of the groundwork already for some of the coded systems, but for this I will be essentially rebuilding them as they are strewn across several test projects, in various states of mothballedness.

In between working on my asset store stuff, freelancing, and this, I estimate I will have 3-4 hours each day of productive work on this project.

Design/Planning
Within 3 days, I’m going to come back with a complete plan of the game, including the overall gameplay and art direction, background ‘story’, detailed description of all of the levels, a list of all the gameplay systems that will need to be built, and a list of all the art assets needed. The idea is to be around 90% accurate in terms of the assessment of all the assets that will be needed so that I can correctly plan the use of my time.
In this time, I’m also going to download and play a bunch of games of this genre from the play store and try to figure out what makes them fun or not, as well as draw inspiration for the design of the gameplay.

Full prototype
I’m going to make the entire game in ‘greybox’ before making any art . That means that the entire game should be playable and bug free before I make any effort at the art. I really think this is one of the keys to success.
Also, I’m going to try to create an abstract blueprint for the levels that can be re-used to make creating them much faster, without making it all feel too much the same.

Art creation
Once I have the entire game built, it will be easy to be efficient when making the art. In the planning stage I’m going to detail the exact approach I will take to make things quicker and easier, such as:

  • Making modular/reusable art for the ships and scenery;

  • Creating a material library at the start, and keeping it simple;

  • Using a single (or maybe a few) master materials in Substance Designer, using the material library, where I just plug in the baked maps and export the result.

Lastly, this is an exercise in making things fun and full of character rather than simply functional. It’s not at all an attempt to make something realistic and anything that isn’t fun will be mercilessly routed out. To that end, I’m going to try to come up with as many ideas as I can to “juice it” and make the game fun and engaging.

Thanks for having a look and I hope this will be fun for you to watch! Since people are wanting a screenshot, here is one - the loadout menu (see below for more):

4 Likes

Here’s the first draft of the planning and design document:

GDD

CONCEPT

This is designed to be a very simple space combat game designed around the player being a freelance pilot and taking on missions around the game universe. The explicit goal of the player is to gain access to more powerful ships and weaponry through taking on missions and getting paid for them.

The target platform initially is just mobile (Android and iOS). The game will likely be released as a premium product at a price point of $2.00 although (despite my initial post) I haven’t ruled out releasing it free to begin with if it feels like the right thing to do.

Graphically, the game will be quite simple with a slightly stylized, colorful and clean aesthetic which will hopefully go down well on mobile.

Instead of making a story-driven game with a high production overhead for cutscenes, characters and mission/level design, as well as scalability issues, I decided to go for a more open-ended design that could be expanded indefinitely and have story modes added later. The open-ended, ‘procedural’ mission design also brings a high replayability factor. This means that the concept can be made relatively quickly and released, and iterated upon and expanded over time.

STORY

The original game won’t be story-driven in any way (although story-driven campaigns might be added on top of the core gameplay at some point) so the background story is quite simple right now.


After developing the ability to generate wormholes, humans have colonised their first habitable non-earth planet in a different galaxy. It was none too soon, for Earth, early in the 21st century, suffered severely from the effects of a population explosion driven by a collapse of organised civil society.

The new solar system, simply named New Sol, contains a single habitable planet called New Earth as well as several resource-rich planets which are used by the colonists to resupply Earth.

New Earth is a water-world which, although containing relatively little landmass, is perfectly suited to human settlement and rich in biological life. No intelligent life has been found there, and some have theorised that this is due to relatively frequent mass-extinction events driven by severe tropical storms and tsunamis…

Ambrosia is a small, watery gas planet rich in carbon and other nutritious materials which, using new techniques, is mined for materials which are turned into food in orbiting factories, for transportation to Earth.

Chrysos is a giant planet which, due to its gravitational effects, has pulled in a lot of mineral-rich asteroids which are mined for resources both for the new colony and for Earth.

Unfortunately, out here in this new colony, piracy has sprung up as a major source of income from colonists seeking to improve their own lot at the expense of others. Instead of a full-time police force, the colony relies on trustworthy freelance pilots to defend them.


GAMEPLAY MECHANICS

Overview

The player takes on the role of a freelance pilot operating a small, fast combat ship, taking on courier, escort and mercenary combat missions. This ship has the capability to make short, local hyperspace jumps inside the New Earth system, which the player can use to visit the three planetary locations. At each location, there will be a number of stations or outposts which the player can dock at to take on missions.

Space travel/combat

This game primarily involves operating a ship. The core code/mechanics for this are:

  • Camera view: To begin with, and to reduce the art overhead of making cockpits, the perspective will be a third-person chase camera position behind and slightly above the ship.

  • Engines/Control: Since it is a mobile game, the 3 rotation axes (pitch, yaw and roll) will be converted to 2 by linking the yaw and roll (similar to Starlancer). This way the ship can easily be controlled with one finger on a virtual joystick, or with the accelerometer, while the other finger can control the throttle or the weapons.

  • Weapons: The weapons will fire directly forward and the reticule will be fixed in the centre of the screen. However, to make the aiming mechanics easier to handle (especially from third person) there will be a snap feature where the weapon projectile spawn points snap toward the target when the player->target axis is within a certain angle from the player forward axis.

  • Shields: To begin with, and to make both the gameplay and the HUD simpler, there will be no ‘hull damage’ feature. When the shield reaches zero, the ship will explode.

Missions/Progression

Currently, three mission types will be available at a variety of stations in each location.

  • Courier: This is a simple, low-pay job to take a package from one location to another. Although it’s not as dangerous as the other missions, pirates may get wind of you…

  • Escort: This involves protecting a cargo or passenger ship taking a route through a dangerous region of space. This carries a medium risk as attacks are usually planned and attackers are operating in groups. Pay is medium.

  • Assassinate/destroy: This involves either trying to assassinate a pirate or to destroy pirate assets, and carries a very high risk. Pay is high.

The ability to pilot cargo ships and trade is not initially planned although it might be added later.

These missions are regenerated periodically, and at the moment will simply consist of 1 or 2 lines of description in a non-unique format.

LEVEL DESIGN

Each planet location (New Earth, Ambrosia and Chrysos) will be a separate scene, and the player and certain elements such as UI will be transferred between the scenes using DontDestroyOnLoad() when the player makes a hyperspace jump.

Each of these scenes will be a spherical environment of 5000 meter radius and the player will be simply clamped inside it.

The basic features that are common to the levels are:

  • A scene/skybox;
  • A planet;
  • A hyperspace location that the player can activate from other locations;
  • A series of locations where the player can find jobs;
  • A number of ships that the player can interact with through combat.

There will be some location specific assets to give identity to the locations such as asteroids at Chrysos and gas clouds at Ambrosia, as well as an inter-galactic hyperspace gate at New Earth (for travelling back to Earth) which the player cannot go through without being destroyed.

CONTROLS

The ship controls layout is as follows:

· Directional control: Optional between accelerometer, touch joystick or a D-pad.

· Throttle: swipe slider.

· Targeting: Button.

· Pause Menu: Button.

· Fire Guns: Button;

· Fire Missile: Button

· Hyperspace Jump: Tap on UI widget.

ASSETS

Models

The initial estimate for model asset requirements are:

Player assets:

· 3 player ships,

· 3 guns;

· 3 missiles;

Environment Assets

· 1 planet mesh with 3 textures;

· 1 or 2 asteroid meshes with LODs;

· 3 modular kits for stations (1 per location);

· 1 inter-galactic gate for New Earth;

AI ship assets:

· 1 freighter ship;

· 1 passenger ship;

· 1 mining ship;

· 2 pirate ships;

Visual Effects

The visual effects will be made mainly using TimelineFX and exporting either individual textures or animation sheets for use with particle systems in Unity.

The estimate of the vfx needed initially for the game are:

· Explosion (1 or 2);

· Missile trail;

· Projectile effect (2-3);

· Laser beam effect;

· Engine trail;

· Gas clouds for Ambrosia;

· 3 skyboxes (using Spacescape);

Sound Effects

Either bought from the asset store, made in Audacity, or using a simple sfx generator I made in Unity for weapon sounds.

· 1 explosion sound;

· 3 gun sounds;

· 1 missile sound;

· Engine sound

· Hyperjump sound;

· Collision sound;

· Getting hit sound;

· Locking, locked and ‘enemy detected’ radar sounds;

· 2-3 simple menu navigation sounds such as text scrolling and clicking;

PROJECT MANAGEMENT

It will be attempted to create the whole core game in 2 weeks in greybox (simple placeholder models and no textures) and the art assets in 1 week after that, leveraging:

  • The Asset Store for sfx;

  • Substance Source for textures.

  • Spacescape for skyboxes;

  • TimelineFX for visual effects;

Approaches to save time are:

  • Keeping a simple, clean aesthetic for the art that focuses mainly on form for the models, and color/luminosity for the textures;

  • Creating material libraries (1 per location) for stations and environment

  • Creating modular kits (1 per location) for creating stations;

  • Using Substance Designer to create a master material for creating the textures automatically from the highpoly and lowpoly meshes (will be using high-low bake workflow).

  • Keeping the UI minimalist, clean and simple;

MARKETING

I don’t have a plan yet for marketing, except that I’m going to do anything I can think of, including:

  • Having a landing page for the game on my website (vsxgames.com);

  • Having a facebook and twitter presence for the game;

  • Contacting review sites;

  • Contacting youtubers;

  • Getting press from Unity;

  • Going for a nude run through my city with a sign strapped to my back advertising the game (just kidding!)

Hi.
So how much price you will sell?
And where you will launch? Google store?
Are there in-game purchase item? or not and just demo/paid version game?

Hi, I’m probably going to price it at $0.99 or $2 (I’m more inclined toward the latter). I don’t have a mac to launch it on the app store but hopefully my brother can do that for me since he has one.

At the moment it’s going to be premium and there’s no ads or IAP, but I’m definitely interested in making another free version afterward for comparison that has one or both of those.

I also may make a trial demo with just the first few missions and put some ads in it.

Very ambitious, looking forward to seeing your progress. Good luck!

1 Like

You know its going to be good when you see no pictures of anything and just words :slight_smile:

I do admire your focus on getting money out of game development though. This is my 5th year of development with $5 profit lmao.

P.S. I don’t know of this is still a rule but you need actual progress to show when posting a thread here.

Please read the forum rules- screenshots are required!

OK, OK, here’s some WIP. I’ve pretty much finished the basic loadout menu for ships and weapons. Everything has been set up so that any number of ships/weapons can be added and the whole thing will still work properly. Also the menu items read out of an interface implemented by the weapon/ship prefabs, so adding another one is a breeze!

As promised, everything is ‘greyboxed’ until the game’s finished.

Here’s a Webplayer.

Ship selection:

Weapon selection:

The design document is coming soon, I put it aside for today to get something done.

3 Likes

Good to see you working on a game! I’m looking forward to see this project grow.

Have you made up your mind on whether to go with auto-unwrapped lowpoly meshes and normalmap bakes from manually made highpoly meshes, or manually unwrap low/mid-poly meshes to use premade textures that are like a sheet of different materials and patterns? I still haven’t been able to make up my mind on what I’d rather work with and I’d imagine the mobile plattform constraints have their own implications on that decision. I’d be interested which approach you chose and why.

I’m at the point where I’m thinking about assembling a mech model from a bigger number of modular meshes (in the “dozens” range), but no matter which approach I’m thinking about, it seems like a real headache, either from a drawcall point of view, or from managing the assetcreation pipeline. Either the vertex attribute counts will be too high for dynamic batching, or the geometry won’t work well with the midpoly texture-sheet approach, or I’d have to handle baking a way too large number of individual modules onto a single texture set, making it a pain to extend the set or even change the look of the texture later on. I’m using deferred rendering and was planning to use lots of dynamic lights, but combining that with a large number of un-batchable shadow-casting objects seems… risky.

Good question, basically I’m going to go with the usual baked maps for fighters and weaponry, and try to make some reusable atlases for environmental props such as stations. Basically what I’ve found is that it’s very hard to make an interesting ‘character’ vehicle, i.e., a vehicle that has a high visual impact, from non-unique texture atlases, and I’ve tried quite a bit. You just can’t have form-following seams and surface features like this, and you end up with a model that looks like someone’s taped a lot of newspaper pages to it.

Also, not only do I want to keep poly count very low so I don’t have to do much optimisation, but I’m also keen to reduce the effort and uncertainty and I’ve found that reusable textures take a lot of planning and iteration.

In my opinion, there are only 2 workflows that are really viable - the usual high-low baking, or a medium-poly thing with texture arrays and deferred decals. The latter is actually what I would suggest you do if you were making a PC game in first person. It’s not really viable for mobile I think, due to poly count pretty much (and I’m not sure if Unity’s new texture arrays work for mobile) - and I assume you’re not going for mobile anyway - but if your platform can sustain it, for hard surface stuff you can get really nice forms with one or two averaged-normal bevels, and it kind of necessitates a nice and clean look which I personally like, as well as having very good close-up fidelity. But if your view is far, it’s probably not worth it due to the art overhead of unwrapping bevelled meshes and applying decals, and I would just go with the usual baked workflow.

Anyway, I would question whether 10-20 drawcalls for your mech on PC is going to have an incredible lot of impact as long as it’s just the player and not everyone else as well. So I’d probably just split it up and have 1 texture per modular part. It all depends on the rest of the game I guess.

1 Like

I hate how most things feel like a poor compromise all the time… Anyway, I was thinking the texture sheet approach could pay off longterm because it would make iteration on new modular mesh parts quicker and also it would make it very easy to implement custom skins for the player’s mech later on. That would be a whole lot harder if a mech consisted of e.g. 16 different pieces that each have their own 3 baked textures per material. Also damage textures would be easier to implement with a sheet where I just need to switch each mesh between the damaged and undamaged material.

I wouldn’t worry if it’s just 10 - 20 drawcalls, but I see myself easily hitting 100+ meshes for the player mech alone. Shine 10 shadowcasting lights on that and there you go. If it was viable I’d make every friggin light cast a shadow, because I love cast shadows ^^. The idea was to allow loadout customization by giving the player choices for left, right, front and center parts of the upper hull, each constructed from several simple meshes that each have a convex mesh collider, and the outer layer of armored objects can be individually destroyed to reveal the internal structure. I think granular visualization of damage taken can be a powerful feature and the cost seems justifiable, as I really want to stay away from the usual abstract simplified health point system.

Maybe I’ll just need to experiment a little to see how well it might work.

I’m not sure that removing mesh armor would be the best way to visualise damage - how would you remove it in a way that looks like it’s been damaged and not just missing something? If I were you I’d definitely give shaders/materials a go for the damage, there’s some nice stuff out there that you could try to copy:

The texture array workflow is definitely appealing for me as well, since I’m quite comfortable modelling stuff and baking can be annoying at times. I think decal placement would be the biggest annoyance but as long as you go with a nice clean look it shouldn’t be too hard.

What kind of camera are you thinking of, a long-distance view? If so you could probably get away with one bevel most of the time, and you wouldn’t need too many decals.

2 Likes

Good luck Billy.
Interested in your workflow for creating customizable stuff that might require closer to finished art pieces than what would structurally fit in your grey-box to functional complete game.
i.e. If you provide a lot of trophies for the crib (ala mass effect) or customizable texture switching - for a ship for the player to have a (semi)unique looking ship, how would you go about setting this up functionally - without textures. - Guess you could just do it with some flat/solid placeholder textures while grey boxing.

Anyway - been waiting for you to drop the hammer! :wink: Will watch your progress.

2 Likes

Wow, this sounds hugely ambitious - but aim high right? Definitely advocate building a completely working prototype first, something I’m trying to do more of. Perhaps add more customisation if you want to explore the freemium route? (Could even go as aesthetically basic as the gummi ships from Kingdom Heart) Good luck! Will be keeping an eye on this.

1 Like

That’s the point though, I want things to look “missing”. Like a WW2 plane that loses a part of a wing. It should feel like “Fvck! I just lost a piece of my mech!”, and also it should have a gamedesign implication: armor plates still block a projectile, but when they are gone, the more vulnerable internal structure is exposed. If you’ve taken a beating from the right flank you might want to turn the damaged side away from enemy fire, but that has other implications as well, since all weapons have limited firing arcs. And you don’t neccessarily have 360 degree coverage.

The shader looks cool though! Everspace, right? I plan to so something similar for environmental damage. From a drawcall perspective it’s a bit problematic (for the mech that is - environment should be fine because it’s less “granular”). Either I need to drive the damave over vertex colors which limits the vertex count of dynamically batchable meshes (according to my calculations from 75 solid shaded quad faces to 56 - more if some are smooth shaded and have no UV seams), or by tweaking shader parameters in the material, which breaks batching straight away afaik.

Yes, 1 meter real world would only be a few pixels. I hope I won’t need mesh bevels at all, and can get away with no bevels and post fx AA. For the old placeholder it worked pretty well.

Did you manage to stay within that 3 day time estimate? That seemed rather short to me. Are you doing an analysis of time estimated vs time taken to adjust the projected completion time of future tasks?

1 Like

Not really sure yet as I haven’t gotten to that point, but yeah, my approach with this is to create placeholder stuff and build the system around it. In terms of saving customisations, either saving a prefab (haven’t tried that yet at runtime) or just building a contraption of int values in playerprefs to represent the different parts. I’ll definitely be spending more time on this later on.

Thanks! Yeah I’m trying a few things out and getting some ideas …

Well I think the best idea is to try a lot of things and see what works out in terms of difficulty and aesthetics. If you’ve got a mech with a hundred parts at a significant viewing distance, each part is unlikely to need very many vertices. Btw bear in mind that you can sometimes get a more efficient mesh when you have a single averaged-normal bevel and smooth shading, and it looks much better to boot.

If I were you I’d begin by making the mesh out of low-poly batched parts, see if you can make it look good enough, and then probably try removing the meshes and adding a damage decal to the surrounding area when they are destroyed.
Imo the best asset to have as a game developer is the ability to prototype fast - not just in terms of skill and speed, but getting out of the mindset of planning too much ahead - in my experience it’s very tiring and often turns out irrelevant. The overall project needs planning, but individual tasks and approaches don’t always do well with it. And it’s a good feeling to know that you can put something together on short notice and then chuck it out if it isn’t good enough.

3 Likes

OK well I haven’t done a good job with the project design document, because I made a couple of false starts before heading in a direction I didn’t really intend at first.

The issue was that I didn’t really know how I would update and scale the game, since in 3 weeks although I want to have something playable and enjoyable, I don’t expect it to be as big as I would like to see it become in the end.

So the first idea was to make a series of 10 missions or so with a pretty standard format, a briefing, a quick cutscene at the beginning, and then a fight of some kind - but it’s kind of hard to piece all this together and then be able to add stuff later on. And it actually takes a fair bit of work to set the scene and make it meaningful in terms of the overall story. Also, in a premium game I figure it’s likely that the more story the better, so it doesn’t feel so casual and feels a bit more special.

So what I ended up doing is creating a sort of ‘openworld’ (tiny though hehe) game where you fly around in amongst some stations and do little jobs like courier runs and escort missions (both of those already working in prototype). Very much like a tiny version of the X -series games.

The idea is that with this, it’s quite easy to flesh out some gameplay at the beginning and then just scale it up for all eternity.

So the background is we’ve just started a new colony in another solar system, you have 3 warp locations within this new solar system (one is a ‘port’ for people visiting the habitable planet, another is a food factory near a gassy planet, and another is a mining planet). Each of these locations has jobs (atm they are just local in scope but I’m working on making them inter-warp) and now you just go around doing jobs to make money and buy better ships and weapons.

There are 3 jobs atm - courier, escort and bounty - the bounty one I haven’t got yet as I haven’t added combat mechanics yet.

Anyway enough talk, new webplayer is coming tomorrow.

PS so about the design document, I found that focusing on it early was a bit of a roadblock and I’m not sure it’s a great idea to make it very early unless you know what you want. I kind of feel like now that I have some stuff going, I could actually make an effective one and hopefully I’ll do it in the next day or two.

2 Likes

Here’s a new webplayer with gameplay.

Controls:

Direction: Mouse
Roll: Q/E
Accelerate/Decelerate: Z, X
Jump: J (when aimed correctly)
Boost: Tab

At the moment, you can jump around between the three locations in the solar system, but only New Earth has any activity - the others are empty. I want to find a way to be able to iterate and update the stuff in each scene without having to individually set parameters before I populate them.

You can dock at a station (just get close and click the dock button) and there you can get either a courier or an escort mission. No combat, weapons or drama yet, just the basic framework and logistics.

Also I haven’t tied the gameplay in with the main and loadout menus yet, that’s going to be done shortly.

Main focus next is the design document, since I think I basically know what I will do now. Then combat.

3 Likes

Hi, I updated the second post on the thread with a basic design document.

1 Like

Didn’t get an incredible lot done this weekend, for various reasons, but anyway … formations!

3 Likes