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):

View attachment 209046

 

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

Spoiler: 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!

 

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

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.

 

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.

 

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.

 

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! Will watch your progress.

 

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.

 

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?

 

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.

 

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.

 

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.

 

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

 

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

 

Looks great man. I love seeing the progress. Keep it up.

 

Hello!

Webplayer Demo

WebGL Demo

Controls are:

Accelerate/Decelerate: Z/X
Roll: Q/E
Direction: Mouse
Fire: Mouse 0
Dock at station: L



Main updates:

• A loadout 'hangar' where the player can go to fit out their ship (basically the loadout scene is now integrated into the game as a dockable location, and the player's ship and weapon choices are carried into the game).

• Combat! You will get attacked when flying escort missions, so keep your eyes peeled!

• Fixed an endless amount of architectural issues, mainly to do with dragging a boatload of buzzing ship components between the loadout scene and the game level, as well as managing jobs.

Although the AI is still pretty rough around the edges, I like where it's at. Basically the enemy fighters switch between a number of behaviour coroutines in a state machine, while an AI 'commander' feeds them high-level data such as target preferences. At first, I began with the escort ambush being simply a part of the whole jobs framework, and it was managed by the 'job manager' but now the job manager passes it off to the AI commander which gives combat a lot more potential for flexibility and adaptability.

Also I've added a few sound effects (thanks to @Martin_H for some great sounds!).

So, it's been about two weeks and where am I? Basically the core of the game is there in a manner of speaking - you can fit out ships, fly around (in at least one level) and do a couple of mission types - although I still want to add a pirate assassination mission type to complete my vision for the basic game, as well as add some random encounters with pirates to make sightseeing a bit more exciting and dangerous. And then just try to make everything a lot more varied and fun, because a lot of what I've done is just getting stuff 'working' with little attempt to make it compelling.

Will I finish what I intended (a reasonably fun, basic space combat game) in 3 weeks? Nah. I could probably do something decent in four, assuming that I can crank out the art needed in 1 week. I think another week on coding and I could have what I aimed for gameplay wise. And I didn't work on it much for a few days over the last weekend so I lost a bit of time there.

The question is though, whether I should shove it out the door so soon? I'm not sure if I will. It's hard to do that when it feels like you're 'onto something'. But whatever happens, it's going to be playable and bug-free all the time, so that anytime I feel like it's time, it will be ready. Ready is pretty much as soon as I feel like someone could play it for more than half an hour without feeling too bored - and it's not there yet.

 

After sleeping on it, I've decided to aim for four weeks. I'd like to have it finished well before Christmas at the very latest.

So basically - it's going to end up as 3 weeks working on the prototype, and 1 week cranking out art.

I think the initial idea of 3 weeks would have been ok if I knew what I was going to do and was a bit more focused. But I changed things around a lot in the first few days trying to figure out what I was going to do, and also just didn't work on it for a few days last weekend mainly because I didn't feel like I'd anchored a solid concept of the gameplay systems in my mind.

So now the aim is for finishing on December the 18th.

 

I feel like that all the time and I'm starting to wonder if it'll ever go away.

I experimented a bit with generating decal meshes and for them it would be a big help to have smooth averaged normals on my meshes, so that is what I'll try out next. I'll probably cheat a bit by using the bevel modifier in blender so that it just adds two new edges next to each beveled edge, and shades it all smooth. The silhoutte will remain the same and I get to still do my unwrapping on the super simple basemesh without having to fiddle around with unwrapping the beveled meshes.

 

That's what I do, just apply the bevel at the end, run the weighted normals script and export.

Also if you're using that script, a good tip is that if you want to go back to the usual averaged-normal, just use an edge split modifier to separate all the faces, and run the script again, then remove the modifier.

 

I liked the new build, smooth controls. I didn't like how long it took to actually get anywhere or have anything interesting happen. People on their phones I don't think would be interested in that long of a wait either. Definitely fun to play around with the ship though. Liking the progress.

 

@Samuel411 that's a really good point and it's something that's bothered me a fair bit.

One of my options is to cut out the transit entirely, and access each docking station through a map/menu. Then when the player selects a mission, it would cut straight to the fight.

That way I would have the flexibility of semi-procedural mission generation anchored in a consistent game-world that I can scale up in complexity, but without the tedium of travelling that's ill-suited to mobile. And it would also give a clearer and more satisfying structure to the missions than what's currently there. The funny thing is that at the same time that it was annoying to travel, it felt like the stations were too close to eachother and the scene was too small for the variety of missions that I wanted to have. So this could be a good way to deal with that.

Anyway, thanks for your valuable feedback! I'm glad you enjoy the flying. It would be great to have some feedback on combat - all you have to do is select an escort mission at a station and fly along beside the escorted freighter until you're attacked.

 

Here's a WebGL Demo.

 

I was thinking about it this morning and why not just incorporate the warp speed mechanic to go to docking stations?

 

Well I had basically ruled it out because it would devalue the warping between planets, since it would feel the same despite being radically different distances.

But you've given me an idea. I was going to have an intergalactic stargate that the freighters went through to reach Earth, that the player couldn't go through, but it felt wrong to have it there and not use it. So I might use the stargates instead for the player's inter-planetary travel and use the jump feature for getting between docking stations in the same level.

Once again, thanks for great feedback!

 

UPDATE: Added trading to the game.

Updated WebGL


Why:

It seemed like there were two directions I could take. Either make the game a mission-based pure combat game like Fractal Combat, and get rid of the whole 'game universe' and travel times, or add something that made the game universe worth moving around in. I decided on the latter mainly because I don't think there are many mobile games out there that try to combine fluid combat with good fun trading mechanics like the X-series. And I think there's a market out there for it - the latest Galaxy on Fire stripped out the trading and exploration and everywhere I go to read about it I see disappointment about that.

It also adds another dimension to the game since trading and fighting ability will be a tradeoff in selecting a ship to buy and the kind of risk you'll run flying out in space.

And finally it just appeals to my desire to see/make games with a sense of 'environmental depth', a sense that you're taking part in a big dynamic world that has a lot of stuff going on under the surface.

What:

So the new mechanic is basically along the lines of the trading mechanics in X2 The Threat but not as complex. Ships have cargo space and you can warp around between trading locations to trade. There are a variety of goods of different sizes (denoted by CU (cargo units)) and prices, and stations are continually going up and down in stock. The price of goods is linked to availability so you'll want to buy from places with a lot of stock and sell to ones with depleted stock.

Also now you can warp between the different stations in the same level (other levels are turned off for now).

What next:

I have to find a way to bring combat and missions properly into the current design. I've decided as a rule I don't want to cut to 'future' points in time - it should be basically always 'realtime' in a sense, so I have to find a way to make the escort mission relatively quick while still making sense logistically (note: although I want things to be 'realtime' I have no problem making things totally unrealistic if need be - not that it's realistic at all anyway! The only hard rule is that it should be fun - but I think that it's quite exciting to feel like the game world is never 'stopping and starting' as you go around selecting missions or going from place to place).

After that, I need to start making the game more fun. There's quite a bit of mechanics in there but it doesn't feel like a buzzing space world at all yet and replay factor is pretty near zero even considering it's a bare prototype.

Finally, I need to start putting together the level design in the other environments in the game (Chrysos and Ambrosia) which I've left out since I don't want to be forever tweaking things across scenes. First I'm going to figure out a method to make it easy to set up and update stations across scenes.

PS not sure about the deadline thing, or that I really care anymore! I just want to prove to myself I can make a good game and not waste my time.

 

I don't own a smartphone, so maybe I shouldn't even talk about mobile games, but what if you made the game-time advance while the player is away, and provide different ways to travel? "Time for bed - I'm gonna cloak my ship, and set the autopilot to my delivery destination, and sell the goods in the morning". Or "I really want to get there now, let's power up the frameshift drive and brace for possible interdictions by pirates". That would give the player choices on what to focus on, and more importantly a reason to keep thinking about your game while not playing, and coming back to it regularly to check on things and trade a few goods.

I can't remember ever having liked an escort mission. I wouldn't make those, but that's just my very subjective opinion.

For a mobile game I would assume people have incredibly short attention spans. So if for 10 seconds nothing is happening, I'd imagine a few already have gone off to check facebook. Some PC games I've played I only found bearable because of some fast time advance mechanic. I'm adding it to my game too, hold a button to speed things up 5x. I don't want to be bored waiting to arrive somewhere and I assume some others don't either.

Elite Dangerous is a cool idea, but ultimately it's just too boring and tedious for me, just to give you a frame of reference where I'm coming from. Others obviously enjoy the "eurotruck simulator" style games much more than I would. So I might be entirely wrong about everything, I'm just thinking out loud here.

 

@Martin_H some great points and one thing I want to say is that I really like having the sense of a realtime experience and it's something I want to keep as much as possible in the game.

That said, the player can warp between stations easily so there's no current time dimension barrier to trading - it takes about 5-10 seconds to go between trading locations - just point and press J. The escort mission is the only issue because the whole character of this kind of mission is the anticipation of the ambush which kind of necessitates a contrasting period of flying along quietly as tension builds up.

The only real idea I have is to have hyperspace-inhibitor mines that pull ships out of hyperspace when they go off. If this was combined with a hyperspace 'recharge' mechanic I think it might work within the fast-paced mobile sort of experience. If that doesn't work and I can't think of anything else I'll just cut them out for now.

I definitely hear you about Elite - although I haven't played it still I can easily see how boring it can get and it has nowhere near the atmosphere of the old X-series games. I'm kind of curious as to what made X2 The Threat so addictive for me - I found it incredibly hard to stop playing. It think it was that there was such a sense of depth to the game universe that even just flying around doing boring trading missions with dubious market mechanics, the sense of a huge buzzing game world was always present. I'd like to have the same feeling in my game but I'm aware that immersion is a key factor in that sort of thing which is hard to get on mobile.

Anyway, I've messed around in Blender a bit trying to come up with a simple yet aesthetic design language for the ships. I'd definitely like to err on the side of clean here and just do a good job with the larger detail. Combined with more contrasting, saturated colors I think it would come off nicely on mobile - just slightly stylized.

This one's not finished of course, but most of the main modelling detail is there, I'd probably add a few panel lines and plates/insets and other little details here and there.

 

@Billy4184 this is looking great so far! I am very glad to see you finally took the plunge and are making your game.

 

Thanks @GarBenjamin, nice to see you again! it's coming along nicely, going to put up the next version in a few days, probably on the 19th ready for Feedback Friday.

I've ditched the 'warping between stations' idea again and now you warp between planets/systems like before. To solve the distance problem I'm just making the levels a lot smaller, increased the turbo speed, and making the layout of stations on the level more even to prevent situations where it just feels empty in places. It should feel like a 'space town' when you arrive at the level and move around in it. I feel this is the simplest and most straightforward way to have the levels in the game.

Also added another level - Grannus, where ships go to die! Final home of the colony ship that left earth and a rich source of salvageable materials. Working on mining mechanics now.

 

Been working on a modular kit for space stations, very much wip at the moment:



In case anyone's not noticed, I'm ditching the whole time limit thing although I'm still trying to work with that frame of mind. However it's more important for me to know that I can do a good job and take my time when I need to, since this is really my first stab at making anything substantial. Sorry if I disappointed anyone, I did mean to try to do a 'race to the finish' but ultimately it would have turned out very average compared to what I could do if I was a bit more comfortable.

Modular!

The idea at the moment (after having tried out random stuff for a few days) is to have a single versatile modular kit for the space stations throughout the game. I haven't zeroed in on the texture format but it will probably be one or two textures per level, encompassing at least five or six space stations. Although it's quite hard to approach a modular kit at the beginning after some time I've started to get an idea of how it will pan out. For any of you thinking of making modular stuff and not quite sure how to set it up, I think it's important to keep in mind (in my view) that ultimately to any kit there are a lot of hard-coded rules that are specific to the situation, and you just have to work them out by trial and error. The ease-of-use and practical utility of the kit is, I think, somewhat inversely proportional to its theoretical flexibility and you just have to land somewhere in the middle.

Level design and performance

Since I don't want to have any issues (or a minimum at least) with performance, I've decided to go with fairly low performance targets. It's flexible but rule of thumb is 50-75k triangles and 50 draw calls. Half of that (or possibly more depending) for environment, including space stations, asteroids, and anything non-dynamic, and the rest for moving ships. I have no idea really if this is a great target but for now it seems as good as any until I do some tests.

Code/mechanics

At the moment, I have the basics of combat, trading, and mining/salvaging, which is about all that I'm going to have on first release. However it's not exactly bursting with fun at the moment so I have to set up a couple of levels and work on the anatomy of the vfx/sfx events that will accompany it, as well as the UI. As soon as I feel it is structurally right I will throw up a new WebGL.

Is it going to plan?

Well, I decided to jump the gun a bit and start the art earlier than I was going to for a number of reasons:

• It's something substantial to look at and enjoy about what I'm doing;
• I want to start marketing ASAP - been working a lot on my website, new site will be up soon;
  
• Since the art revolves around a big modular kit, I feel it's necessary to start early since it will probably go through a number of revisions that may have an substantial impact on level design.

In view of this the art will probably be done in a 'first pass' early on and then the textures and meshes will be iterated on throughout development. However what I think is important right now is to nail the mechanics and get feedback, so that's what I'm going to do next.

Hope you enjoy watching, let me know if you have any comments/questions and stay tuned for another demo in a few days!

 

Got to have at least one ad for my site! A little boring right now but will improve as the game gets along ...

Hope the name is catchy enough, let me know what you think!

 

Follow VSXGames on twitter!

 

Nice work so far Billy. And sounds like a good plan as well. Looking forward to checking out another playable demo when you get to that point. And now I really do need to get off this forum and get some work done myself. I think sometimes half of my "game dev" time was spent here. lol

 

@GarBenjamin thanks! I'm sort of making a bit of an exit from the General Discussion section myself, it's too easy to get caught up in fairly unconstructive stuff there. I'm going to try to be more active in the WIP/Game Design sections as well as my site - I'm working on setting up a blog right now.

Good luck with your snow-themed games!

 

Just finished a new version of my site VSXGames. I've added a place to showcase my products on the store, as well as a dev blog! Check out the short post about this game. I'm planning a weekly or twice-weekly blog, probably going to write next about my approach for making modular space stations in this game.

Feeling a bit annoyed as I just realized there's a similar sort of game called SOL: Exodus - do you think Ex Solis is too similar? I'm considering changing it to Exsolis to make it sound like a unique word, or maybe come up with another one. I kind of like the one I've got though.

Thoughts anyone?

 

Nice, clean, straightforward. Perfect site Billy.

 

Thanks! There's nothing like hand-coding in html/css to reign in the fancy stuff

 

Can't say that sounds any fun at all. LOL But I like the clean site.
One small suggestion - might consider adding 1-2 more related images per article - to keep the more visual people interested.

 

Absolutely! It's going to be a very visual site - I just haven't really spent a lot of time on different images yet as you can probably tell ...

 

Hello. I tested the demo. It looks promising. I'm building a spaceship combat game also.

There is not a whole lot to chew on for gameplay yet. I did some escort missions and fought a few enemies. They do the most damage when they all come at you head on. Although when they are separated they are easy to destroy.

You said this is a mobile game so my critique about the controls may not be relevant since I'm playing on a pc. But if you plan on releasing on PC here are my thoughts.

First if you release on PC make sure that your controls are completely configurable. Players who play flight games are very critical of controls and a lot of people have different preferences. Many have to play with a gamepad or joystick so you will need to add controller support. I come from experience since my first game was a flight game and got alot of complaints about controller issues.

When I first started playing I immediately noticed the X axis does not control roll but yaw. Alot of games will have the Y axis control pitch and the X axis control roll. Then have the A and D keys control yaw. You might want to try that.

I like the way the ship moves when aiming with the mouse. When the mouse gets to the edge of the screen the ships keeps turning. For some games like battlefield you have to keep scrolling the mouse if you want to make a sharp turn, which is a bit of a hassle.

You might want to move the camera closer to the ship and raise it higher so the ship is more at the lower part of the screen.

I noticed the Q and E keys control roll which might also work if I got used to it, however the spacecraft would roll in the opposite direction I would expect. It might make since after thinking about it since pressing the left button makes it roll to the left and the right button roll to the right. It was just weird seeing it go in the opposite direction. Having the controls be configurable would help.

I don't think the current control scheme would work very well for mobile devices since they wont have a keyboard to control the third axis. But I'm not sure what your plan on doing. You should make a simpler control scheme available that only requires mouse movement to control the spaceship and no keyboard for roll/yaw which could work for both PC and mobile. Have the spacecraft always facing upright (even though there is no real direction in space). I think it only requires lerping the Z axis to zero all the time.

Also when providing a demo make sure to list the controls and anything else they should know so they can give better feedback.

I would like to know how you did the mouse movement and the way the ship keeps turning without having to keep scrolling the mouse.

I am greatly looking for feedback on my game so maybe you can try it out and post some feedback. It may also give you some ideas on your game.
https://forum.unity3d.com/threads/fast-movers-sci-fi-flying-game.442179/

Good luck!
Roger

 

Hi everyone, I took some days off over christmas but it's now in full swing again! Working hard to get a new demo up before this weekend on Feedback Friday - this time the mining level (Chrysos) using the modular kit, and with the ability to mine asteroids.

Hi Roger, thanks for the detailed feedback! You're definitely right about gameplay, as I mentioned earlier many of the systems (market/combat/AI etc) are 'there' but they aren't really fleshed out a lot. There's quite some work to make sure it's fun all the way through.

About the combat AI, when the ships enter the combat state, they basically oscillate between attacking/evading, but at the moment when they enter the combat state they always begin by attacking. This means that, at first, they will all attack you for some period of time, at the same time - which can be a bit unbalanced. I have an 'enemy commander' script which will probably make them do a defensive split of some kind to spread the focus at the beginning.

In terms of the general combat, I will definitely err on the side of 'too easy' so that it remains fun and keeps a partially casual atmosphere. There will be little actual skill involved, although I'd like to explore ways to make it appear more intelligent while remaining easy.

The controls at the moment don't reflect the way it will play on mobile. On mobile, the roll and yaw will be linked (taking care of the third axis) - if you've played Starlancer, it will be pretty much the same thing. I've seen the 'lerp to horizontal' in games and while I will keep it in mind, I'd rather give more control for the time being and see how it goes.
Btw the reason I don't put the linked-yaw-roll configuration in the webplayer is because it plays horribly with mouse - starlancer didn't have mouse controls, only keyboard - but it feels very good especially with an accelerometer.

The game os only mobile right now, so the controls will not be configurable beyond switching between virtual joystick and accelerometer. In the web demo I will definitely list out the controls - good point.

In terms of the mouse controls, it's very simple - you just get the mouse position relative to the center of the screen and use it to drive the torques on the ship:

Code (CSharp):

1. // Get the mouse position in the viewport - with 0,0 at the center of the screen
2. Vector3 mousePos = chaseCamera.ScreenToViewportPoint(Input.mousePosition) - new Vector3 (0.5f, 0.5f, 0f);
3.            
4. // Get the mouse distance from the center (0,0)
5. float mouseDist = Vector3.Magnitude (mousePos);
6.            
7. // Correct it according to the dead radius
8. mouseDist = Mathf.Max(mouseDist - mouseDeadRadius, 0);
9. mousePos = mousePos.normalized * mouseDist;
10.  
11. // Set the control values and correct for direction
12. pitch = Mathf.Clamp (-mousePos.y * mousePitchSensitivity, -1f, 1f);
13. roll = Input.GetAxis("Roll");
14. yaw = Mathf.Clamp (mousePos.x * mouseYawSensitivity, -1f, 1f);
15.  

And then you just multiply the maximum torques for each axis of the ship by the pitch, roll and yaw values above to get the torque vector that you'll apply to the rigidbody.

Good luck with your game!

 

Finished a demo of the mining system in Chrysos, you can mine ore and trade it in at the mining station!

WEBGL DEMO

Note: This is just mining, so no combat or interaction with other ships right now.





Feedback on the mining system would be greatly appreciated! It should be fairly straightforward what to do, let me know if you think it's not. I'm reasonably happy with it and I feel like it's not too far away from wrapped up.

Where I'm At

Well this last week I've concentrated on graphics, so as to be able to present some better media, as well as setting up the core feature of mining/salvaging.

Graphics-wise I'm trying to err on the side of vivid/chunky look which hopefully looks good on mobile. I'm also keen to try to stylize things a little more to make character really come across on the small screen.

The modular station kit has been slow going and took quite some iterations, and still has a long way to go before I'm happy with it, but it's a good learning experience and overall I'm glad I'm doing it this way as I think I'm developing a better sense of what does/doesn't work. Biggest issue is how changing something, e.g. the texture detail, for one situation can mess up how it's used in another situation.

What's next

Combat! Should have fixed this up properly first actually, but there you go. I want to have a plug-and-play setup for the enemy attacks and maneuvers so that I can easily proceduralize things a bit to make the whole place feel more alive and reactive, which is essential if I'm to go lean on the story and missions.

I'm probably going to begin by adding pirate attacks to the demo above!

Also the AI doesn't really have obstacle avoidance yet so that should be fun as well.

After that, the trading needs a lot of work. It's boring and drab right now, apart from UI work I need to make it feel more competitive and do things like making the market reactive to certain events going on in the universe so that it's not always just the usual random draw. Might even have some kind of text-based customer service that gives you the latest.

Thanks for watching!

 

Here's a quick .apk with joystick and accelerometer controls (tap top right button to toggle between them), any feedback would be great!

 

Nice work. Cant really think of any feedback right now. You should include the controls in your post though. I did not know how to mine for awhile until I noticed the tooltips on the screen.

Is there a way to use the missiles?