Template Space Combat Kit (VSXGames) [RELEASED]

Hi McRangerRare, thanks for stopping by! First of all, of course over the last few months, for various reasons, things have become quite delayed even in my own projects such as my mobile game. I apologize to everybody for that, but what I can tell you is that from developing my own space game, the kit will be much better than it otherwise would be.

Right now in fact, except for AI, there's not a lot except that I have not nailed down in a way that I think is both flexible and easy to use. Player input, weapons and radar are all pretty much ready to go.

So with the AI, for my own game thus far, I had some sort of complicated setup with numeric valuation of different behaviours that just got too difficult to use, although most of the time it worked well. But I really needed a more flexible way of scaling up the AI behaviours for different contexts. So instead, I have just started developing a behaviour tree system, that will combine with what I have already of collision avoidance and spline path navigation, to hopefully constitute something that can easily address all the things that you guys will need (and also to fulfill what I want to do in my own game).

It's still very early days (just started last week), but I have the basic node editor done with saving and loading graphs.



Right now I am in the process of creating the different behaviour tree node types, and the all-important 'leaf nodes' that will actually carry out the behaviours according to the ship systems I already have in place. I will try to have enough leaf nodes there to get most core AI behaviour going immediately after you download the package.

This so far has been the biggest sticking point with the package, since I wasn't sure that it would be a great idea to send out a fully code-based AI system as it can get a bit hairy just figuring out what would be going on at any given time. With this behaviour tree editor, and some clearly defined interfaces for you to work with, it should be very easy for you to use and extend the system.

I've been considering pausing my game to finish this, but I'm not certain that's the best idea since I often find things that can be improved when I use stuff myself (happened with the radar package which I am using as-is in my own game), so it will probably continue to be developed alongside my game and potentially get finished in a few weeks or so.

Anyway, I hope you guys can put up with waiting a bit longer, and feel free to check in any time with any questions you might have.

 

Take all the time you need! I'm just glad to know you're still working on it along with your own game! Cheers!

 

Hi,

I've opened the WebGL player but I don't quite understand how this works. I see the controls, but is this all?
Thanks!

 

Hi John3D, are you referring to the radar package? It's designed to allow you to easily track other objects such as spaceships in the scene. Are you able to see the target boxes as they track the spaceships? Let me know exactly what you're looking for.

 

Ok. I understand now.
I wanted to shoot the enemy ships.

 

Ah ok, that's just the radar module. I'm creating the different ship systems (engines, weapons, radar, controls/AI) in separate modules so that:

• It's as easy as possible to pick and choose the parts that you want/need;
  
• It's easy to disable/modify different systems due to damage etc;
• Make it easy to attach different modules to different types of platforms, such as fixed turrets on an asteroid or something.
  
• Easily use/modify specific modules for a totally different kind of game.
  
• Also makes it easy for me to add functionality to different modules in updates, without affecting other things more than necessary.

Although, the next release is probably going to be the whole kit (all of the modules in the same package).

FYI I have pretty much everything going except for AI, that's something which I've decided needs to be built up properly as a behaviour tree with editor tools, rather than just coded as it can get a bit cumbersome to deal with that way.

 

Behaviour tree tool is coming along nicely.



On the left are all the behaviours in the Resources of the project, which you will of course be able to add to yourselves.

Editor doesn't look too different but there's a lot of stuff added/changed behind the scenes. Serialization and saving/loading of trees and tree data is a real pain, and necessitated a couple of architectural overhauls, but I think I have it worked out.

Right now the trees save fine as an asset file, and I'm working on how it will be loaded/referenced in the scene and presented at runtime, which also impacts how easy it will be to create behaviours yourselves. At the moment the idea is to simply present each node as an interface that can be called through that interface.

I'd very much like to keep the Blackboard (the collection of data used by the behaviours) as flexible as possible so I'm also working on a way to access data there by string using reflection.

Comments and suggestions much appreciated

 

Made a lot of progress on the behaviour tree asset. The blackboard (where all the data is stored) turned out to be the most difficult part but it's pretty much done. There are a few more to-do's but it's almost at the point of actually programming the ship behaviours and testing it out.

The main screen hasn't changed much, nice and simple:



Now, on the left hand panel, you can enter 'blackboard mode' and create instances of variables that your nodes can access and modify at runtime (via keys to a serialized Dictionary - many thanks to @christophfranke123). At the moment there's Bool, Int, Float, String, Vector3 as well as Ship (the main ship component). You can easily add more types by making some small modifications to the scripts.

These variables will also be exposed on the nodes themselves in the tool window, to do things like check conditions etc - haven't got to that bit yet.




Now, in the scene, every ship will have a component (named 'BehaviourTreeHolder' for now), which will not only carry out the behaviours at runtime, but also expose the values of the blackboard in the inspector, for easily modifying values across different ships.



So that's pretty much where it's at. I finally have all the data serializing properly and surviving entering/exiting play mode as well as saving between editor sessions.

Next up is to create all of the nodes/ship behaviours from all the AI code I have so far, and hook up an AI to test the system.

 

Hi everyone, I've tentatively decided to bin the behaviour tree tool (at least for this kit). Instead, I will provide a coded state machine AI, as well as integrations with behaviour tree tools already on the store such as Behaviour Designer.

The main reason is that I feel the complexity of the tool is starting to outweigh its utility as a part of the kit, and it's difficult for me to predict exactly how much functionality you guys will want from it. I'm at the point where I feel like I'm starting to drift into making some sort of visual scripting tool, where I'm exposing properties of scripts through reflection to set the values on the nodes, etc. It just doesn't make sense to me that I should be doing this when there are already polished tools out there which I can integrate.

Anyway, it would be great if you let me know your thoughts and what AI tools you would most like to see integrated.

 

Integration with Behavior Designer was actually the tool I was going to ask for integration, but since it already is(Correct?) I'm satisfied. Will the AI be able to work with behavior designer's various packs as well?

 

Not yet, but I will integrate Behaviour Designer for sure. I'm going to grab it this weekend and begin. Hopefully it's just a question of slicing up the code I already have and putting it on nodes.

 

OK the kit is coming along well, and I will put up a new demo this weekend.

Spent a couple of days re-doing the weapon architecture:

• Easier to go from individually configurable weapon mounts with in-game weapon group modification, all the way to the standard primary/secondary setup with left/right weapon mounts linked to the same module (for symmetrical weapons).

• Each weapon mount is now linked to a weapon cache so you can easily define which weapons can be loaded at each weapon mount.

• Camera focuses on the selected weapon in the loadout menu.

Here's the loadout menu:




Here's the in-game weapon config:




Today I re-did the HUD to be world-space with a custom mesh/shader for the circular bars to save on fillrate (originally those circular bars were a huge image with 95% useless empty space).

 

It's looking great! Can't wait for the demo!

 

Here's a demo (AI vs AI) of the AI controller I've developed for the game.



The AI uses the exact same force-based ship steering/thrust that the player uses, driven by a PID controller.

The AI system is basically a feedback loop that switches between attacking to evading, based on various factors such as time and the target's position.

The obstacle avoidance (which you can see with those large orange arrows pointing away from obstacles) uses a variable size data cache to store a 'short-term memory' of nearby obstacles (using some prediction for dynamic obstacles) which makes dithering less of a problem and plots a more efficient course.

Now that the AI is pretty much ready for first release (except for Behaviour Designer integration), I just have to finish the Big Demo Scene and that's it.

 

This is amazing. It's been a while since I saw a good space game starter kit! This is definitely going to help me out a bunch!

 

OK, here is the latest WebGL demo! It has all of the functionality listed in the OP post (which has been updated with better info/pics), except for the cockpit view, which will be finished over the next few days.

Tackle waves of enemy AI, try out different weapons, and have fun with weapon groups and power management!

Don't forget to hit 'I' to see all the controls in the demo!







Some notable recent additions:

• In-game weapon groups management;

• In-game power management;

• Loadout menu and weapon selection;

• Multiple missile locking on the selected target;

• Updated HUD;

• AI / obstacle avoidance.

The project is a little untidy right now as I have been focused on getting everything running ASAP, but I have begun the documentation, code formatting and performance profiling which will probably take most of next week, at which point I will hopefully send it off. As I organise things I will post more info related to how the systems are built up and what you can expect to find digging around in the code.

Look forward to any and all feedback! And feel free to ask any questions.

 

Some more pics:

Weapon Groups



Power Management:

 

Great work!!!

When is the expected release date for this?

 

Should be somewhere around next weekend. Functionally, everything is there as you can see in the demo (except for the cockpit of course). So it's pretty much a question of organising and formatting the code, making documentation and profiling performance.

Let me know if you have any questions or comments about anything in the demo, or if you caught any bugs.

 

Next question how much will the 3D Space Combat Starter Kit cost?

 

Great job! Can't wait for this!

 

EDIT @runningbird see my edited reply below. The starting price I mentioned first was partly because I wanted to give a discount to those like you who have followed the thread and already bought the radar package, but the upgrade system is a better way (and you get the kit for even less).

The Space Combat Kit will start at $40, and anyone who has already bought the radar package will be able to upgrade for the price difference (so it will only cost you $25). The price will go up over the first few months of updates/additions.

The main updates I expect to make are:

• Newtonian flight model;
• Multiplayer;
• Whatever you guys would like to see that I haven't already got!

 

Awesome can't wait.

 

OK! Here's the updated demo with cockpit, 3D radar and holograms added.




That pretty much wraps up the content. I've still got quite a bit of code to finalize and documentation to make, so I expect that to take the rest of the week, and I hope to send it off for review this weekend.

 

This is great. Only suggestion I have is really to keep things modular.
What you're talking about (and some of what you're showing), seems like it provides a lot of cool features. Some might be interested in that complexity, while others might just need a small piece of that.
Making things modular is certainly the best route I think.

Only thing I can think of is to make certain settings like the input system flexible so that it doesn't conflict with other systems that people might have in the game. For example, I saw a comment above talking about the ability to walk outside the ship.
Would it be possible to somehow have this space flight as part of a larger game with characters? Perhaps a customizable feature that lets you climb into the ship.

 

Thanks for the comments and feedback! It's very modular, so much so in fact that the different vehicle subsystems are not designed to be specific to space games, but are easily transferable onto other vehicles such as scifi buggies or mechs (hint hint). Except for the engine scripts, the spaceship specific stuff is in a separate folder.

Also, the features such as the power module are completely optional. The different subsystems simply check if a power component has been attached, and if not, they default to whatever values you've provided in the inspector for power consumption and recharge values for that subsystem (which might be zero if you don't even want power to be a factor).

The camera is completely separate from the player and can be attached to any ship including AI, and I'm also working through the setup of the HUD so that you can easily make several and switch between different ones (such as if you enter a different ship).

If you have my radar package (which is included in the coming kit) you'll know that getting rid of the 3D radar, target dash holograms, or even the target tracking itself is as simple as removing an object from the scene, and also the target tracking is very customisable in terms of what information is shown.

In terms of input, Rewired is integrated so that's probably the best way to go for flexible input. I've also got a standard input script with things like GetKeyDown and such, but it's in its own script so it should be fairly easy for you to change key values if needed.

In terms of getting in and out of the ship, I started to create that at one point but decided I had better just finish the core kit first. There is a script called PlayerPilot (which you might say represents the 'player character') which stores variables such as the ship that the player is currently controlling, and this script interfaces to the ship in exactly the way that the AI script does, so it's perfectly easy to just switch between different ships or transfer the ship to AI control. So that means that while I'm not actually creating an animated character that can enter/exit ships, it's technically possible to simply add it.

So pretty much everything in this kit is as modular as I can possibly get and it should be very easy to go all the way from a simple arcade shooter to a more complex space game. Let me know if you have any more specific questions!

 

Kit is coming along well, but unfortunately I wasn't able to work on it so much last week. Also miscalculated how much there was still left to do with architecting the functionality to be easy to use. Current ETA is mid-end of this week.

Here's an example of how the engines are set up.

From the manual document:

There's also a custom inspector for different power configurations to hide unnecessary stuff:



Atm I'm working on the organisation/documentation of the weapons, which is the most complex part left to do. I'll update again in a couple of days.

 

The amount of work you put into this is unbelievable! The amount of love just put into making the engines work is awesome. Cannot wait for the release!

 

Thanks for the kind words, and for your patience! This is the end-all of space game kits

 

Really excited to see this. Can't wait.

 

This being released soon!? Super eager!

 

It sure is and it's nearly ready. I've finished sorting out the architecture of the weapons which was the main thing still to do. I'll be posting some more information today on how the weapons work, as well as the anatomy of how a vehicle (ship) is set up in this kit. As I've said previously I'm focusing on a really well-designed core framework that makes it intuitive to add/remove and extend the functionality - making your job and my job both easier!

Still a couple of days before I send it off.

 

So I was going to post about the weapons stuff I'd done earlier this week, but instead took a bit of time to change some stuff that I think needed to be changed. So I had the weapon modules/mounts separate from any other (generic) modules/mounts but that didn't seem like a good foundation, so:

• Made all modules (including weapons and shield modules I've already got) implement IModule interface so that they can be treated the same way (such as on loadout menu lists, or swapped around on the vehicle's module mounts). This means a lot of re-factoring of code related to weapons, weapon groups, and loadout menu.

• Created module mounts which can load specified types of modules, and lays the groundwork for creating a more complex module system (such as classes, sizes etc).

Also moved weapon targeting stuff into a separate Weapons Computer component. Originally most of it was in the Radar script but there was too much stuff spread out between the Weapons and Radar scripts, in a confusing way.

Also moved all the Power-related stuff out of the various subsystem scripts and into the Power script, as it makes it more organised and easier to expand the types of subsystems, as well as keep track of how the power is being distributed/stored.

Not quite finished these things yet, but I'll post some editor screenshots when they're done (hopefully tomorrow).

 

Quick update on the Power component. Now the subsystem power storage and recharge occur on the separate Power component even when the subsystem is independently powered (before this code was on the relevant subsystem component).

This means that it's very easy to add another powered subsystem type to the ship (just add a value to an enum), and using the power for this new subsystem is as simple as calling a function on the Power component (rather than having to set up semi-duplicate code on the new subsystem component itself).

Each powered subsystem has a separate power configuration setting (Distributed, Independent and Unpowered).

Also, each powered subsystem has a slider for the fraction of the power that is available as Direct power (such as cruise thrust) vs. Recharge power (that goes to recharging the power storage, and can only be accessed by drawing from storage).

To make things easier to set up, on the Engines component, I have removed the splitting of the Direct power between thrust and steering as I felt this just makes things hard to set up. Now the control values and thrust are calculated simply by multiplying the gross Direct power by a power-to-value coefficient.

Spoiler: Editor Pics

Distributed:




Independent:




Unpowered:

So, on each subsystem component there is a simple toggle for IsPoweredSubsystem which shows different settings depending on whether it is on or off (such as default values for unpowered subsystems for those not using the Power feature).

Spoiler: Editor Pics

 

OK so I'm pretty happy with the ship architecture, and I'm still finishing off the code formatting and various bits and pieces, so here's an update on how it works.

This kit comes with a strong foundation for creating a module upgrade system in which the player can choose between different module options and attach them to the ship’s module mounts. This is based on a Subsystem/Mount/Module architecture.

Spoiler: Diagram

Subsystems

A subsystem is a core component of a ship and includes Engines, Weapons, Radar, Health and Power. These subsystems are basically ‘managers’ for managing different types of interactions between the ship, the player/AI input, and the game world.

These subsystems manage modules, which are mounted on the ship’s module mounts.


Module Mounts

The module mount is an intermediary between the ship’s main systems (Engines, Weapons, Health, and Power) and the modules that have been attached to the ship. This script provides the opportunity to intercept or create specific pathways of functionality between modules and the ship’s systems. Each module mount specifies the module types that can be attached to it.


Creating Modules

The basic requirement for creating a module that can be mounted on a ship is that it must implement the IModule interface. This interface allows it to be shown in the module list in the loadout menu, and to be attached to the ship’s module mounts according to its type.

All modules can be destroyed or temporarily disabled.

Any kind of module can be easily created in this kit, simply by having a script on the module prefab implement the IModule interface. This interface provides a CachedGameObject reference which other scripts can use to search for particular components or interfaces (such as those described below).


Weapon Modules

The requirement for creating a new weapon module script is that it implements the IWeaponModule interface (allowing the weapons to be treated the same i.e. when firing, and preventing duplicated code). At the moment, the weapon modules are further categorised by either an IGunModule or an IMissileModule interface (both of which extend the IWeaponModule interface).

The IGunModule interface provides an opportunity to calculate and set the ‘lead target’ position (for aiming at fast moving targets) according to the projectile speed of the weapon.

The IMissileModule interface provides the opportunity to lock onto the target before firing a missile.

The architecture of the weapons modules provides a good example of how it is recommended to set up module <--> subsystem functionality. The Weapons (subsystem) script stores all the weapons currently mounted on the ship as instances of the MountedWeapon class in a List. This class contains all of the interfaces that the weapon module implements (such as IWeaponModule, IGunModule, IMissileModule) as well as a reference to the module mount that it was found on. These instances are created in the Weapon subsystem script, after it searches the ship’s module mounts for modules containing a component that implements the IWeaponModule interface.

Spoiler: Diagram

Health Modules

The IHealthModule interface provides an interface to shield and armor modules, which are collidable surfaces with an energy value which can be depleted and recharged. This interface also provides the opportunity to enable/disable other health modules which are ‘encapsulated’, helping to prevent damage to shielded armor modules. This is a problem with high-speed collisions where the ship’s colliders intersect so deeply into an obstacle from one frame to the next, that a collision is registered on a shielded collider before Unity’s physics can reposition the ship.


Other modules

Any other modules can be created according to the principles described above.

 

Almost there, ran into a complicated freelance job this week. Just going through each section of the kit and checking things off now.

 

So i can use this kit for any sort of game? rts, fps ect?

Keep up the work, it looks very intresting!

 

Hi Lukis, thanks for stopping by! At the moment this kit is designed for use as a first/person space combat game, in the same gameplay style as something like Elite Dangerous.

Eventually, the idea is to be able to apply the code to any kind of abstract 'vehicle' which can operate on the architecture of Engines/Radar/Weapons/Shields/Armor (or some combination thereof). So this might include something like a hoverbike, mech, jet fighter or even perhaps a character. But right now I'm just focused on getting the spaceship combat done, and making sure that anything that can be abstracted away is created in the abstract - so that the foundation for expanding the kit is there.

The result is that the code is separated into two namespaces - 'UniversalVehicleCombat' for abstractable code and 'SpaceCombat' for space-combat-specific-code. Most of the core architectural code is in the former right now, whereas stuff like HUD code, input code and any other demo-specific code is kept in the latter.

Hope this makes sense, and let me know if you have any more questions.

In terms of when the kit will be finished, I'm still working through the finishing and polish. The loadout menu has proven a lot more finnicky than I thought it would be to finish up, because that's the point where all the architecture of the code comes together in a very interactive way, and anything good or bad about how things are designed makes itself obvious - so I need to work through it carefully and make sure I'm not patching up any design flaws.

 

Looks pretty sick dude! This has really come a long way.

 

Thanks! I hope I'm taking an approach that will make it the kind of asset that not only does what it says on the box, but isn't hard to change into whatever specific purpose it was bought for.

There's a certain kind of flexibility that I think asset store projects should have that makes it useful not just as a plug and play for people who don't code, but also offers a clear design that can be identified and built on by people who just aren't sure how to approach things.

 

Hello! Hopefully, everything is going well (take your time of course). I have a question though. In further updates to this kit, do you plan to add in AI vocals (e.g. nice shot, or missile incoming)?

 

On that note, I was sort of curious as to whether it would work with Behavior Designer.

 

Hi guys, I'm working on it consistently, and it really is very close to done, but I've had to take on a fair bit of freelancing work lately so I'm trying to find some good time management skills!

@McRangerRare I'm sort of trying to avoid creating too much art and presentation stuff, but that sounds like it could be a good idea. I'll probably add it in an update though.

@rubble1 I still haven't integrated Behaviour Designer, due to the amount of stuff I've found to do in the kit, but it's an absolute top priority and will get done. I've broken the AI code into separate behaviours so it should not be too hard.

 

A well polished kit is a lot better in the long run, I appreciate the time you take to give us this! No worries!

 

Ditto.

 

Wow this is incredible for sure I have been working on a space game for 3 years now and this makes my game look like crap lol I'm excited for this and my money is already set aside to buy it on release day nice job on this

 

Thanks Lushi! Almost ready .. I focused a lot on freelance work these last couple of weeks so that I can eat while finishing this project

 

Lol no worries take your time just know you have a for sure buy right her lol

 

Quick update on how the kit is going.

So I was about to call it ready a couple of weeks ago, but I had some reservations about how I was going about things, and on top of that I really needed to get some funds together, so I focused on freelancing for a bit. I'm in a better position now and I've attacked this project again after a little while off.

Different vehicles

As I mentioned before, although I am only focused on implementing space combat mechanics in this release, the aim of this kit long-term is to end up with a sort of Star Wars Battlefront framework where the game is able to deal with many different kinds of vehicles by using an abstract Vehicle system. In this framework, a Vehicle simply describes the entity with which the player or AI moves through the game world (including a body). The advantage of this is that not only is the complexity of the code reduced, but transitions between states (entering/exiting different vehicles) is greatly facilitated in terms of things like input, camera, HUD, inventory and other things.

Although this sounds a bit like a diversion, I have found that there is almost nothing I have to add to the framework in order to prepare it for modes beyond space combat - and it has made everything follow a logic that is much cleaner than I think it would otherwise be. Almost everything is already of the right nature - weapons, shields, armor, target tracking, 2D/3D radar, power and heat dissipation is already conceivable as a framework for any kind of combat platform (think Mass Effect suit).

The only real obstacle I had was with the Engines component, which is vastly different for different vehicles. What I have done is create the Engines part of the framework as a composition, where the Engines sends the 'input amounts' (values of -1 - 1 for the rotation and translation on each axis) through an interface (IVehicleController) to the vehicle's specialized controller, which can use these values to drive any sort of movement mechanics. Since all movement is basically a matter of rotating and translating on any or all of the three axes, I think this is as flexible as it needs to be - and the added advantage is that it easily enables swapping between a space game with arcade style and more complex thruster setups.


Inheritance

The first thing I did when I dived back into this project is to get rid of a lot of interfaces and replace them with inheritance. I've established a very solid, cross-vehicle framework, and many of the components that form the very basis of the kit, such as Vehicle and Module, were being passed around as interfaces on the unfounded notion that they would have to be accessible in an extremely abstract way, when really their concrete implementation as a base type would not change much whether you're dealing with a spaceship or a buggy. And it became obvious that I was simply perceiving "is-a" (inheritance-style) characteristics as "can-do" (interface-style) ones in an attempt to take abstraction to an impractical level, resulting in what was essentially duplicate code disguised as an interface. This made it very hard to keep track of how objects were being perceived and interacted with in the code, and would also have made updating the kit quite messy - since all of the scripts that customers might create to extend an interface would have to change every time an interface changed.

Also, inheritance (something I haven't used a whole lot) is much more flexible than I thought it was, and I think that very little or nothing was lost in terms of the ability to abstract a vehicle and the vehicle framework for different games.


Other stuff

I have the theory now that a software project is only 'ready' when the developer says "NO!" to a big feature (at least for that update cycle). In this case, it was an inventory (for stuff like shared/finite ammo for the ships weapons etc). I started putting a fairly basic one together, but given that the project is designed to be very flexible, I think it makes more sense to integrate a third party package like Inventory Pro or something - but it won't be before release.

So the features are locked down, the project is warning free, and I'm just finishing Behaviour Designer integration and documentation. I'm going to try to finish it on a bender this week.

 

I' m looking forward to it!!