Template Space Combat Kit (VSXGames) [RELEASED]

@Billy4184 Your server is not sending the demo to the front-end. It doesn't open/play for me either.

 

@MV10 and @Tayer, it should be working now, looks like it was a bad upload and my browser had cached the previous one making me think all was well. Let me know if there are any more problems

Just a reminder, press Esc during the demo to bring up the Pause menu where you can see all the control bindings

Looking forward to all of your feedback so that I can continue to improve the kit!

 

Just played it - very slick!!! Can't wait to see it on the Asset Store!
Are you using Rigidbody physics to move the player ship? I'm currently using Rigidbody physics so that I can use gravity to alter the trajectories of objects in my game.
Also, are the ship controls broken out of the ship itself so that if I had multiple ships, I could switch between them, so whichever ships in my "fleet" I'm not controlling, they'd switch to a rudimentary AI (ie., formations on leaders -- I have my own code for that but definitely looking for a cleaner way if you've already built something like this)...

Looking good!

 

Hi @danreid70,

Yes, it's all rigidbody physics, there's absolutely no direct control of transforms. I stuck to that not only because it works better but also because it makes it easier to expand the kit to include things like realistic individual thrusters and so on.

Not sure if you were asking this, but AI won't be in the first release, although it's very high in the priorities as it is not an 'extra' but rather essential for a game of this type.

Yes, you would be able to easily switch between ships. The ship itself is not 'active' in the sense of communicating with other scripts. Rather, the input script attaches itself to a ship and controls it. So all you would have to do is specify the ship that you want to control. The ships are handled through a convenient 'Ship' class so this should be quite clean and easy. Also, the AI will simply be an input script and will use exactly the same interface as the player, enabling you to easily transfer control to AI.

I'm really glad you liked it! Don't be afraid to criticize things you don't like or make suggestions as I'm always trying to improve it and make it more useful for a wider range of different projects

 

Like the concept. For input it would be good to be able to switch out to alternative input systems (e.g. Rewired). I want to use a HOTAS system with tool and since Rewired supports all of the good ones that seems like a good choice.

 

Hi @longroadhwy thanks for stopping by! I had a look at Rewired and since it seems like it would be a really useful asset for space game developers I will make sure my kit is compatible with it

 

Rewired is best input asset on any platform in my opinion (been a fan since beta). For space/flight simulation is the only way to go (no 20 button limit) and the best part with native input support on Windows/Linux/Mac OS. It wonderful to build your game for Windows and then for Linux and have the same great native HOTAS support on both platforms. Linux traditionally has had the worst controller support of any platform but with Rewired there is no difference between the Windows and Linux.

Make sure you take a look at the Rewired trial version since the only limit is that your game (the executable that you build) will only run for 2 minutes.

http://guavaman.com/projects/rewired/trial.html

Back to your game.

Do you plan on making any of the enemy ships hidden inside any of those asteroids? It cool to have the enemy ship hidden inside or behind the back half of the asteroid. So it makes it harder to find them.

I really enjoy being able to fly through the asteroids in the demo you provided. Do you plan on having any gravitation pull from any of the planets so your ship could get sucked into a planet?

I like how you did the HUD for indication of speed when in "third person mode".

It would be interesting to have fake targets that appear that mask the real targets from you.

Do you plan on having any mine fields to protect the enemy targets that we are trying to destroy? It would nice to have some protective mines floating around a target. Also have some mines that automatically home in on the player when they get into a certain distance from the target.

 

Thanks for the link! Yes, Rewired looks like it would be very useful and would fit nicely with this kit.

A couple of your suggestions seem to be a little bit specific to your own game, but I will make it as easy as possible to add your own features to the kit. It won't be difficult to add your own gravitational effects and things like that. Also mines with particular behaviours would probably be specific to your own game and I want the kit to be clean and lean so that everyone has as little difficulty as possible understanding how it all works. If you have a specific question once you've got the product I would be happy to help you out.

However I will include a simple mine just for you and add it to the demo

About the enemy ships behind the asteroids, I have thought about making an 'asteroid base' just for fun, and I might do that. The behaviour of hiding behind the asteroid would come down to the AI. Now, I have experimented with this already - keeping the asteroid in the line-of-sight with the target in order to set up an ambush, and this behaviour will certainly be in the AI 'add-on' that I have been working on - but will not be in the first release.

 

@Billy4184 First, I agree 100% with @longroadhwy on Rewired. It's just incredible how thoroughly it solves Unity's input issues and is especially helpful for flight-style games. If your asset had Rewired integration, that would nicely solve the input side of things.

I've got a rather long post here, sorry. The TLDR is: I'm way more interested in the AI and obstacle avoidance stuff than the rest of it.

OK, so here goes...

I've been (very) slowly working on a space action game. It's got a little bit of trading/smuggling like Elite, missions like X-Wing, and even a bit of Borderlands/Diablo-style loot and other light RPG elements, but shrunk down to a scope I can hopefully finish someday.

The majority of the features you've listed in your space combat pack I already have implemented, and it sounds like in a similar way. So what's more interesting to me is the AI and obstacle avoidance features. I especially like the idea of plotting curves through the environment as needed. At the moment, I don't have a good solution for enemies navigating through asteroid fields, for instance.

What I've got now for enemy fighters is a simple state machine with 11 states, the four main ones being:

* Head Toward Target: When the AI ship is far from a target, just roughly head toward it.
* Get On Target's Six: If the AI ship is in front of its target, try to move toward a point some distance behind it.
* Match Speed and Follow: If the AI manages to get behind the target and face toward it, try to match target's speed (roughly) and stay on its six.
* Global State: Whenever the AI has a reasonable chance at hitting the target, fire. For beam weapons, the weapon target is the target ship's position directly, for projectile (laser bolt) weapons, the weapon target is the "lead" (predicted) location of the target ship.

This works surprisingly well. For obstacle avoidance, I have a stupidly simple thing where I raycast in front and if there's a hit within the raycast limit, the AI pulls up for two seconds. Very primitive. If it gets "stuck" on something moving forward, it'll actually back up for a bit.

If the target simply comes to a stop, the AI will also come to a stop when it's close and continue to attack. It's an unwise thing for the player to do. There's also a special case for the player. If the AI has a non-player target, such as a freighter that's on the player's side for instance, but the player gets close, the AI will switch to the closest enemy that's a threat. That is, an enemy with guns is enough for them to at least temporarily switch targets.

I don't have anything yet in terms of enemies working together. My thought was to have certain types of enemies, like trained military, be able to fly in wings with wing leaders (wing "commanders" you might say...), where the wing leader does the AI and the others just try to stay in formation. Those types of enemies would likely have turrets rather than fixed weapons, so they could aim without having to move out of formation.

So... I am curious how a behavior tree approach compares to that. I do own Behavior Designer, so I'd be in favor of supporting that. Haven't really played with it and honestly don't know much about behavior trees.

I'm not interested in the AI being particularly smart. Basically, their motions should *look* reasonably non-dumb while providing a *fun* challenge.

I am curious about your statement that you are doing strictly rigidbody physics with no direct transform manipulations. I do that for the player, but not AI ships. I originally tried that, but I was unable to do accurate target lead calculations. I ended up with a hybrid solution where all linear motion is done properly via AddRelativeForce, but rotations I cheat on and do directly to make sense of aiming. If you have a proper solution to that, I'd buy the pack just to see that.

 

Hi @Steve Tack, thanks for your interest!

To put it simply, my experience with space combat AI and obstacle avoidance is that it takes 10% of the work to get something 75% quality, but 90% of the work goes toward the last 25%. That's why I decided to not include the AI in first release as I felt it wasn't good enough and there was quite some work left to take it to product quality.

Regarding behaviour trees and state machines, first of all I haven't applied behaviour trees to space combat AI yet. My point of view is to make a state machine until it becomes too hard to maintain and then naturally you will switch to behaviour trees - rather than immediately trying to implement a more complex system. Because state machines can actually make a decent AI as you found, but also as you found it has some limitations. Obstacle avoidance for example could be a whole big state machine in itself depending on how complex the environment is.

So I can't really tell you yet what the differences are exactly, although I can speak generally. The way I see it, a state machine is a big bunch of if-else statements. The weak point of this system is when you have a lot of small changes to make to the behaviour based on small changes in parameters. Each of these becomes an if-else check, and unless you have some sort of great UI for your state machine tool, working with this code quickly gets complicated.

So in terms of the space combat, I found that while the core system of the AI was easy enough to implement - get-on-your-six, evade-for-period, all that kind of thing - adding flair and character to the enemy made it difficult to work with. Especially at an individual level it would be good to give the enemies 'personalities' or otherwise combat gets boring. In Star Citizen for example with Vanduul Swarm you have a whole bunch of different personalities which feed into behaviours. I wanted to be able to make an AI have hit-and-run tactics, brute-force tactics, and do things like work together when several of them were attacking the player. I also wanted them to do things like become more fearful when they were heavily damaged - i.e., be more inclined to evade. I think these really help make combat interesting, because combat is after all just your cockpit and a small moving blob on the screen, so it's essential to really bring everything you can out of the experience IMO.

So behaviour trees help because they use a value-based system to decide what behaviour to choose at any given moment, you basically decide on each iteration of the tree which behaviour to choose based on their relative value. For example, to put it simply, you might have an Evade and Attack behaviours and you need to know how to choose. So you could make it so every time the AI is hit, the Evade behaviour becomes a little more important and the Attack becomes less important. Also you might have it so that the Attack behaviour becomes more important if the AI is already locked onto you. So you get a lot of degrees of behaviour without having to specify concrete if/else statements and so on.

For an example of behaviour trees being a good fit for games, Halo has always been applauded for having fun AI and strategic gameplay and a big part of that is the behaviour tree system. A lot of games it seems use a mix of state machines and behaviour trees although it's hard to find details on this.

Anyway, regarding calculating the lead target position, there's a way which basically comes down to projecting the projectile path and the target's path and solving a quadratic equation for a time t in which they are in the same position. It took me a while to figure it out but it's not all that hard. I'll see if I can comment a script for you and send it via pm.

 

@Billy4184 Thanks for the thorough reply! The kinds of AI you're describing definitely sounds exciting.

My state machine is based on the one from the book Programming Game AI by Example. It's an elegant design that uses singleton classes for each state. The owning "entity" you pass in and do everything through public properties and public methods on that entity. Each state has an Enter, Execute, and Exit method to handle transitions. You can do stuff like go to the previous state. It helps a ton with encapsulation. There's no UI needed - I'd think that would only complicate things. It's definitely nicer to work with than if/else statements!

As an example, my "match speed and follow" state is one of my simpler enemy fighter states, as most of the heavy lifting is in other classes. Like in the Ship class, setting DirectRotation to true activates target lead when needed.

Code (csharp):

1.  
2. using UnityEngine;
3.  
4. public class StateMatchSpeedAndFollow : State<FighterPilot>
5. {
6.     // This should be called when behind the player.  Try to match speed and head towards player's future position.
7.     private static StateMatchSpeedAndFollow _instance;
8.  
9.     public static StateMatchSpeedAndFollow Instance
10.     {
11.         get
12.         {
13.             if (_instance == null)
14.             {
15.                 _instance = new StateMatchSpeedAndFollow();
16.             }
17.  
18.             return _instance;
19.         }
20.     }
21.  
22.     public override void Enter(FighterPilot entity)
23.     {  
24.         entity.Ship.DirectRotation = true;        // Rotate directly toward calculated target position (target lead is used for pulse weapons)
25.         entity.TargetCone = 10.0f;   // 10 degree cone
26.     }
27.  
28.     public override void Execute(FighterPilot entity)
29.     {
30.         if (entity.AITick)
31.         {      
32.             // If beyond 550 meters of target, go to StateHeadTowardTarget
33.             if (entity.DistanceToTarget > 550.0f)
34.             {
35.                 entity.StateMachine.ChangeState(StateHeadTowardTarget.Instance);
36.             }
37.  
38.             //
39.             // See if we're now in front of the player.  If so, go to StateGetOnTargetsSix
40.             //
41.  
42.             // Calculate heading from target
43.             Vector3 targetToThisDirection = entity.CachedTransform.position - entity.TargetShipTransform.position;
44.  
45.             float angleFromTargetToThis = Vector3.Angle(targetToThisDirection, entity.TargetShipTransform.forward);
46.  
47.             if (angleFromTargetToThis < 90)
48.             {
49.                 // We're ahead of the target, so switch to StateGetOnTargetSix
50.                 entity.StateMachine.ChangeState(StateGetOnTargetsSix.Instance);
51.             }
52.  
53.         }
54.  
55.     }
56.  
57.     public override void Exit(FighterPilot entity)
58.     {
59.     }
60.  
61. }
62.  

On the target lead thing, thanks! My target lead calculation is based on some stuff I cobbled together from Google searches. I haven't actually worked out the math myself, but at least at one point is was spot-on. Not sure why it's off now - could be that I just hadn't pushed it too hard initially. For one thing, it doesn't take angular velocity into accounts, so that could be a problem:

Spoiler

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class Targetting
6. {  
7.     // Base projectile speed is currently fixed at 160
8.     public static Vector3 CalculateLeadPosition(
9.         float baseProjectileSpeed,
10.         float distanceToTarget,
11.         Transform fromTransform,        // The ship doing the firing
12.         Vector3 fromLocalVelocity,
13.         Transform targetTransform,
14.         Rigidbody targetRigidbody)
15.     {
16.         Vector3 targetInterceptPosition = Vector3.zero;        // Return value
17.  
18.         Vector3 projectileVelocityVector = fromLocalVelocity + (Vector3.forward * baseProjectileSpeed);
19.      
20.         float projectileSpeed = projectileVelocityVector.magnitude;
21.      
22.         Vector3 velocityPosition1;
23.         float velocityDist1;
24.         Vector3 velocityPosition2;
25.         float velocityDist2;
26.              
27.         // first calculation, using actual distance
28.         velocityPosition1 = targetTransform.position + (targetRigidbody.velocity * (distanceToTarget / projectileSpeed));
29.         velocityDist1 = Vector3.Distance(velocityPosition1, fromTransform.position);
30.      
31.         // second calc, using distance from first calc.
32.         velocityPosition2 = targetTransform.position + (targetRigidbody.velocity * (velocityDist1 / projectileSpeed));
33.         velocityDist2 = Vector3.Distance(velocityPosition2, fromTransform.position);
34.      
35.         // third calc, using distance from second calc.
36.         targetInterceptPosition = targetTransform.position + (targetRigidbody.velocity * (velocityDist2 / projectileSpeed));
37.      
38.         return targetInterceptPosition;
39.     }
40. }
41.  

Anyway, now that I think of it, the real problem with full rigidbody physics was the difficulty in getting the AI ships to quickly get to their target positions. There was always a lag, so they'd rarely get into position quickly enough to get a hit on the player.

 

Looks like a good way to make a state machine! But still you need to specify the behaviour explicitly for different situations. That said though, behaviour trees are not incredibly different from state machines, hence they are called Hierarchical Finite State Machines. In a way they are just an improvement.

Hmm it seems like you're using the projectile speed to calculate the target's time-to-intercept or something like that. Anyway, the one I sent you should work well.

For the AI, I think you need a PID controller, used in robotics and such, it's a simple but powerful way to control something under not-so-clear and dynamic conditions, which can be the case when using rigidbody physics. That's what my AI had and I had it following spline paths pretty accurately, you just need to tweak the P, I and D coefficients so that you don't get oscillation or unrealistically snappy movements.

 

Hmm, interesting, I'll have to look up PID controllers. Never heard of that before.

 

It took me 4 tries to actually start killing stuff, I finally get a run where I kill two of the stations and right before I kill the third I hit an asteroid and bounced around to death.

10/10 would asteroid again.

Great looking kit man, the HUD is very slick and the cockpit looks great!

 

@frosted thanks for taking the time to try it out, and for the kind words!

The cockpit may get a refurbish before launch, since I think it is lacking detail, but at the moment I am busy tidying up the code, making documentation, commenting the scripts, and fixing bugs, as well as adding a few things here and there. I'm trying to make it extremely easy and intuitive for everyone to fit this kit into their games and get it up and running.

Thanks everybody for your patience! I had hoped to get it done by now, but rest assured it's very close to finished.

 

Wow, the ship controller, the movement, the radar system, everything is so smooth I wonder how performance friendly for the target detection system is? Will it work well with a herd of 30 or 40 ships? Would it be cool to have an option like Auto Target ON, so it would auto-pick the target as higher priority first.

 

Thanks! I'm really glad you like it.

I haven't run too many performance tests yet but I will test out 50 targets with the radar today and let you know how it goes.

I'm not sure I understood what you said at the end, do you mean that you would like the radar to automatically switch to a higher-priority target if one appears? For example, you are dogfighting with a lower-class enemy, and suddenly a more dangerous enemy comes in, so it switches automatically?

 

I PROMISE this is going to be the last iteration of the ship model before release. I simply came to dislike the previous version - especially the engines - and I thought it could be a lot better. Hopefully this one is more techy, sexy and cool! I will hopefully finish the highpoly today, and bake the lowpoly by tomorrow or the day after. The cockpit especially will have better materials and more detail.

 

No, I'm just thinking a way to no need to implement these 3 buttons Next Target, Target In Front, Closest Target since Mobile GUI is limited of space. But, I tried it again, the radar auto-picks the target in front just fine

 

The default targeting mode can be set in the inspector, this is what the ship does when the current target exits radar range or is destroyed.

 

Going over the thread this morning I realized I'd totally forgot to do the test I promised, sorry!

Here it is, I made an isolated test case for the radar, with nothing but the player ship and a lot of primitive targets. Targets are in view (and therefore being tracked with the UI), and the 3D radar is also tracking all of the targets. The screenshot was also taken as the ship was pitching so all of the UI was moving significantly every frame.

There are ~343 targets there (a 7*7*7 grid) and the fps drops to around 50 as you can see. Also the computer is a laptop, while pretty decent you'd get much better from a desktop.



I did notice a couple of optimisations I could make. The frame rate drops sharply because I instantiate new UI elements when more ships come into view - they don't get destroyed when no longer needed, just disabled/pooled, so it's only the first time that they're created that this is a problem. So I might estimate the number of ships that will be viewable at the start.

Also, I will likely enable you to set the frame interval that the UI is updated, just in case you're needing performance elsewhere.

 

Hi there, pretty awesome stress test for the radar target detection. Pooling for the Target UI elements is a great idea Btw, you can also spread your target detection over frames, consider how fast your AI movements, scaling AI up so that only keep updating of some target in the view only, target detection based on a specific distance, etc. I don't know since I have not get chance to read your system code yet. Just an idea, we can categorize targets in some category, for example, "target in front - in orange", "hostile target in front, or at the back, or L/R, that is currently shooting at u - in red", "boss target", etc. So, the radar system only registers "useful" targets if Smart Mode is ON for example.

 

Great ideas there, especially on radar optimization, I didn't think of adjusting the detection rate based on target speed

Regarding the categorization of targets, I'm just thinking that it's probably a bit project specific. The selected target is of course highlighted differently, as you can see on the web player, and I will probably fade out the unselected targets based on distance to the player.

However the code is hopefully structured in such a way as to allow you to add your own customizations easily, and I would be more than happy to help anyone out with implementing a specific adjustment

 

Hi everyone,

- Downloaded the Rewired trial today and tested it on the game. No problems.

- Isolated the weapons system in a new project, tested it out and added new stuff:

1. Finished adding weapon groups (same system used in Elite) along with UI;
2. Added gimballed weapons with adjustable rotation limits;
3. Separated weapons into mass projectile, energy bolt and beam weapons;
4. Adjustable raycast frequency (time or frame based) on shots for performance;

Next:

- Isolate, cleanup and test the damage system, radar UI, flight controller, camera etc.

Working hard to wrap this one up for you guys!

 

That is awesome news on Rewired support!

@Steve Tack

@guavaman

 

No worries!

I'm wondering how to best package it (since it won't of course include Rewired) without causing errors for unknown API calls. Maybe just put all the rewired stuff in its own method and comment it all out?

Otherwise I might just create an input script that lists all of the methods called by Rewired in public methods, and you guys can add something in Update to link them to the input. It would be a lot cleaner that way.

 

This thread has some tips on that subject of support external input options like Rewired.

http://forum.unity3d.com/threads/how-to-make-better-code-assets-for-the-asset-store.366355/

Some assets have separate unity package (included with their main asset) for Rewired integration and users just install that to use Rewired. Some assets also include Rewired Input Manager in a prefab. So that way users have basic mapping as a starting point for mapping.

Here is an example of the prefab method.

http://forum.unity3d.com/threads/motion-controller.229900/page-26 (see msg #1264)

 

@longroadhwy thanks!

 

@Billy4184.

@TonyLi has some good comments in this thread about input handling. (see msgs 8 and 10)

http://forum.unity3d.com/threads/rigging-and-skinning-solutions.394667/#post-2594311

 

Hi everyone, it's coming along nicely. At the moment, I'm wrapping up the feature set for now, with the addition of a power source with a triangle slider for diverting power between Engines/Weapons/Shields, as well as a heat management feature that can cause your ship to blow if you're not careful!

The weapon groups, power management and heat management are considered sort of 'advanced' level components and as such are designed to be cleanly removable from the ship without errors.

The main systems (Input, Engines, Weapons, Shields, Radar and HUD) are considered basic and while separated by interfaces (to allow you to cleanly replace them with your own code) other scripts may throw errors (informative ones of course!) if they aren't found present.

Besides finishing a couple of the features, I'm basically going over scripts one by one now and finalising them (again!).

I have a question: with the addition of weapon groups, I currently have the ability to load multiple missile launchers into a single fire group, which basically means multiple missile locks. Is this something you'd like to have (multiple locks) or not?

If not I might simply limit the group to one missile type weapon, but it would be kind of tricky to do this in a way that doesn't look like a bug! If you do, how would you want the multiple locks to be displayed in the HUD?

Thanks for your input!

 

Hm just remembered another thing: multiple weapons with different projectile speeds means multiple lead target positions to aim at.

The only practical way to solve this that I can see is to set up a single lead target reticle for one of the weapons and automatically offset the aim of the others so that they all end up hitting the same spot. But automating things this way feels kind of artificial. What do you guys think?

At the moment I'm seriously considering canning weapon groups altogether until a bit later on, so as not to delay the release, and sticking with a single selected gun and a single selected missile. Weapon groups feel like something that would take a lot of testing to get right.

 

Maybe multiple weapon groups, but player selects which one is "active", after firing, switch to next group in sequence - that way, simpler lead target (only one active at a time), but still have multiple weapon groups...?

 

That's an idea, however I feel that it isn't something that would work for everybody, which is what I'm aiming for really with the first release.

I've not played Star Citizen, but here's a thread where the players discuss the same thing, and it doesn't seem like there's a real solution to firing multiple weapons with different speeds besides automation. I'm not sure if anything more has been done by CIG in this regard but at the time of the thread, it basically meant multiple aiming points on the HUD (cluttering possibly?) and wasting bullets/energy when firing different speed weapons at the same time. This also possibly encourages monoboating (loadingthe same weapons on all stations) which kind of removes the skill/tactical factor with weapon groups.

As far as I can tell in Elite (which I've not played either unfortunately, although I'm going to get my hands on it within a few weeks) there's the same problem, especially when arming lasers (zero travel time) together with projectile weapons (significant travel time). I also want to add beam weapons before the first release, so this would make the problem even worse.

At the moment I think I'll put weapon groups on hold until I figure out something that's more generally applicable.

 

OK guys, sorry about the delay, this is still being worked on. After wearing myself out a bit on various projects, and having a few sudden changes in life (including moving countries etc) I really lost motivation and felt like I was hacking stuff to get it done, so I decided to put it on hold for a bit, which ended up turning into a couple of months. I probably should have posted something here but I kept an eye on the thread anyways and was ready to respond to comments.

For now, I'm not going to talk about release, but obviously I hope it's going to be very soon. Most of the core elements are there but I want to make sure it feels ready and complete before I say anything.

GRAPHICS

So, I made a big stargate to give the scene a focal point, before it just felt like you were lost in some random bunch of asteroids, and I also made the asteroids better:




This also helps guide the demo's level design a bit and make it more interesting.

I'm also experimenting with damage effects, especially for lasers, using a trail renderer:



At the moment, I'm retexturing the inside of the ship, as I think it looks really plastic and toyish. Much more details and texture variety, as well as hopefully more realistic PBR:





SOUND

I've spent a fair bit of time getting to know about SFX, analysing ripped sounds from games, and experimenting with building them from scratch. I think you'll find the sfx in the next webplayer update much nicer than before.


CODE

I made a bit of a mistake taking code modularity to the extreme and not keeping it simple and straightforward. So I've been going through and tightening it up a lot. It's still fairly modular, such as keeping different functionality in different components, having a strict hierarchy, etc ... but I got rid of some of the interfaces and architecture that was bloating it all up. I want the code to be approachable from beginner to advanced, and it wasn't like that before.

So that's it for now, I much appreciate all of your input and attention so far, and again sorry about the delay. I hope to get to you real soon a solid foundation for making any kind of space combat game you can imagine.

Cheers

 

Hi, I am really exited about this project, please don't drop it and release at least some kind of version of it. Want to buy it for my game so badly.

 

Hi Valakot, thanks for your interest! Don't worry, it's coming along slowly but steadily. The kit is near completion and already far better than the webplayer suggests which probably means I should roll out another one. Hopefully next week sometime. I did a huge cleanup of the project earlier this week as well (so much debris lying around!) so it feels much more ready to show off, and I also practiced creating ships and weapons in the project which unearthed a few ways to make it more streamlined for you guys.

I also updated the original post to reflect the current state of how the project will be released (and hopefully very soon as well).

I've been mainly working on my artistic skills recently (modelling, vfx and sfx, UI) which may disappoint some of you who are mainly interested in the code framework, but I was really unhappy with the quality of assets and I want them to really show what the kit is capable of. I've always been very impatient with art and tend to half-ass it a bit (especially after the first hour or so) which I'm determined to stop doing. I've also been writing a lot of custom scripts for blender lately and my workflow is getting a lot faster.

I've also had a number of ideas which despite not being a priority at the moment, I wanted to investigate to a certain extent before resuming work on the project, as they could be used by people buying this kit (and in some cases, such as a procedural sfx generator, have already been used to make stuff for the project).

Just to show some stuff (which maybe I should do more often) here's what I worked on this morning, messing around with planets in subst designer. I hope to create a lot of asset packs for the kit after release to help you make a bangin space game!

 

Hi everyone, for the demo I modified the planet shader from the wiki, basically just added lighting information (direct + ambient) as well as tweaked a few things.



As a token of appreciation for anyone following this project, here's the planet shader. I commented it pretty extensively (so anyone wanting to learn a bit about them can probably find something useful there) and dropped in the planet (subdivided cube) and ice planet texture from ^^. Hope you enjoy it and let me know if there are any issues.

Dropbox Link

 

Working on the HUD ...

 

A couple of snaps from work on the weapon effects ... this is cockpit view but no mesh atm as it is being fixed up.

 

Updated stargate ...

 

Still need to finish a couple of things, but here's the business end of this space-warping beast ...

 

Beauty shot ...

 

Sure looks like a dangerous place to park a stargate.

No, really, it all looks pretty good! Wish I had the time, patience and talent to crank out the art-side assets!

 

Haha yes, the asteroids just spawn anywhere at the moment, I have to just add something to take into account bounding boxes of ship meshes and such.

I hope to crank out quite a bit of art in the near future, and I'm always looking for ways to make art kits worth more than the sum of their parts, with modular textures and meshes (although this one ^^ is not modular at all). I've done some work on tools in Blender that I hope to transfer to unity in the form of an editor extension, that lets you easily swap out areas of texture on the model and so on which, combined with modular meshes should make for quite a lot of versatility.

FYI that model is 12k vertices and is wearing only 1 512px material, it's 3km long in the game and you can fly right beside it without much blurriness. In fact I just submitted it to the asset store for 10 bucks and it should be up in a few days if you'd like to grab it.

 

The stargate is live on the Asset Store if anyone would like to get their hands on it early.

Although I haven't gotten much done on the kit over the last week due to working on someone else's project, I spent that time becoming familiar with Photon multiplayer and adding multiplayer has become a priority for an early update - it won't be in release as I don't think it's fair to delay it any longer.

So getting back to it today, I'm refining a few things in code such as testing a fully world-based HUD (whereas before it was split across world space and overlay canvases) and pulling a lot of things together in custom inspectors so that unnecessary information is hidden and workflow is easier.

Not long to go!

 

Hi everyone, sorry for the delay, as usual I had a "well why not?" moment and then started doing all sorts of crazy stuff like adding fps characters to the demo when I should have been getting this done.

Small change of direction - I'm going to release the kit in modules the way I've wanted to from the beginning. First up is the radar. In summary it includes:

- Caching trackable objects by registering and deregistering them when they are enabled/disabled;
- Radar component with several different target selection modes;
- Missile locking;
- Lead target tracking;

- 3D Radar with zoom and linear/exponential distance display;
- On/off screen unselected target widgets;
- Lead target and locking visualisation for selected target;

So I took out the radar stuff and created a new project with the radar on its own, with interfaces for meshing with weapon components etc.

This will be released shortly as an individual module which can hopefully be easily integrated into any of your projects.

I've put together a small WEBPLAYER demo with some adjustable parameters to show off a few things. Try it out and let me know what you think! Still a couple of things to integrate back in but I wanted to get something up today.

Cheers

 

There's a lot of customisation possible in the inspector, using editor scripts to keep it neat. As an example, the HUD sprites can be differentiated based on a) the team that the trackable object belongs to, and/or b) the class of trackable object (such as ship/station/waypoint). This way different HUD symbols can clearly show different types of targets beyond visual range without you having to add a bunch of code.

The editor script automatically updates the inspector on all associated scripts when values are added to the Team or Class enums, making it easy to modify these properties with your own information, and then quickly update the colors and sprites on both the 3D radar and the visor in the inspector.

 

Updated the webplayer with the target hologram, other widgets such as health bars, target locking, sound effects and some other settings to play around with. Would really appreciate some feedback as to whether or not this ticks all the boxes for your radar needs!

Still a few performance issues to figure out but I think the layout of the code and interfaces is right. Working on a pdf as well. ETA for submission (of the radar package) is this weekend.