Template Space Combat Kit (VSXGames) [RELEASED]

It is saying that this model has not yet been published.

 

Should work now.

 

It works

 

Make sure you are using the latest Rewired which is 1.1.19.6 version.

Set up the Rewired Gamepad template up first to get familiar with templates.

Feel free to ask about the HOTAS template (and anything Rewired Template related) and @Steve-Tack and I can help guide you on the path. We always find something new and exciting every time we dive into HOTAS things.

For HOTAS Template (you can start with mapping these)

(1) Stick X
(2) Stick Y
(3) POV HAT (you have my example mentioned previously for that one).
(4) Stick Trigger
(5) Stick Rotate (twist stick which most HOTAS seem to use except for all CH Products sticks and ThrustMaster Warthog stick).
NOTE: This is mainly used for those who do not have flight pedals but map it to flight pedals for a start)
(6) Throttle 1
(7) Throttle 2

NOTE: Every throttle seems to be different enough when it comes to buttons and mini-stick support and not counting all of the HATS. Throttle names are different too so it does make it a bit more challenging.

Flight Pedals Template

NOTE: (Should correspond to Stick Rotate to be consistent).

(1) Left Pedal
(2) Right Pedal

In game controller remapping by end users:

If you want in game controller/keyboard/mouse remapping you can always use Rewired's Control Mapper. Everyone always wants to map a controller differently for some reason.

More details can be found here:

https://guavaman.com/projects/rewired/docs/ControlMapper.html

 

Greetings,

I am using Unity as a way of creating Maya fbx animations for my short films, so I have a very newbie question: I am considering your asset for use for any spaceship combat scenes and I want a more realistic depiction of locomotion in space. Can I use Space Combat Kit in conjunction with something like Gravity Engine to achieve realistic results? I am not concerned about gameplay, using weapons, radar, HUD or any of that stuff. I am only concerned with ship movements.

 

Hi, it's not completely clear what you'd like to do with the space kit here. Will your project involve the player controlling the ship? Or are you interested in the AI movement? Which parts of the kit are necessary for your project?

Feel free to send me a PM to discuss this, or email me at contact at vsxgames dot com.

 

I guess it's only a matter of days now when Unity will approve and release the version 1.2 update? Excited to continue my set up and discovering how to use SCK. Has handling sound fx related to vehicle movement already been updated on that version?

 

I just bought this kit, looks pretty good. Is there a lot work to get multiplayer working?

Billy, I seen an earlier post were you mentioned some things about setting up multiplayer. Could you be more specific as to what needs networking support?

And I'm not sure about the master client reference. Most game engines don't allow any clients to be the master of anything to prevent hacking.

 

Unfortunately the submission was declined, because of the integration UnityPackages (now hosted on my website) as well as some problems with the way that the models were imported. All fixed and re-submitted. If anyone wants to get their hands on the new update now just send me your invoice number and I'll link it for you.

I didn't quite make the last weekend for the capital ship update, but it's all done except for the cap ship AI which I'm working on right now. I'll put up a demo/video very soon.

I haven't updated the background engine sound settings, it'll go in the next update.

 

Hi, thanks for buying! The multiplayer alpha package is available for anyone with an invoice number for me. It's not complete but it's a beginning. It'll take quite some more work to get it ready, and I can't say exactly when it will be.

The way you want to set up the game authority is up to you. Master client authority works quite well in a lot of cases because a group of friends can play, and also because (at least the idea is that) no one will play in a game hosted by a cheater, so cheating hosts end up finding themselves without anyone to play with. This is different from a cheating player being able to hop around from game to game, joining as an ordinary client and wreaking havoc, which is not possible (not for long anyway) with a properly set up Master Client.

In any case, unless you're doing the entire game on the server (players sending input commands only) or something like that, the code/logic for master client authority should be easily transferable to a server authority.

 

Oh darn. I will just wait further as I prefer to get the Package through Unity's system so it has already been checked. I don't really care much for new models as I will replace them. But prefer just having the updated codes. Thanks for the info!

 

Looking for some help in setting this up within an existing project to just use the AI systems for avoidance and to reach a target destination. Any tutorials on this? After attaching the scripts the AI just sits there, not moving...

 

I thought about features that could be worth adding and one occurred to me. A sort of projectile evasion system would be nice, think an expanded version of a radar warning for a missile but instead of beeping it tells you which of four/six directions to thrust in to avoid the incoming shell/missile/bullet/beam.

Something that could let you fly into a swarm of oncoming missiles, projectiles and meteors that would provide avoidance instructions for things within a certain radius taking into account the different speeds of projectiles so you have the appropriate amount of time to dodge provided there is enough distance between you and the enemy firing to actually move out of the way before the projectile hits you or say activate a directional shield to nullify the damage.

An example might be...

You're flying towards a group of capital ships in a fighter-bomber in open space, they start firing flak and beam cannons at you. Every time a projectile or beam is slated to impact you, you're given a warning shortly before it hits you so you can avoid, if the system was programmed not to instruct you to thrust in a direction that would put you in the path of another projectile without a chance to dodge.

The idea would be that you could use such a system to thread the needle to through dense AA fire to land hits on capital ships or static defenses in combination with countermeasures and directional shields.

 

A tutorial on the AI is definitely in order, although it's on the list for a bit of an overhaul as it's not at the level of usability that I'd like it to be.

1. Did you set up a patrol route for the AI (add a GroupMember component to it and set the Patrol Route field)? Without that, it has nothing to do when there is no combat going on.

2. Did you check the 'IsInVehicle' variable of the AIExample component to make sure it successfully entered the vehicle?

3. Go to the AISpaceFighterControl component that is on a child of the AIExample component's transform and, just before the line 'switch (currentBehaviourState)' on Line 211, add the line 'Debug.Log(currentBehaviourState)'. This should be Patrolling (if no enemies in range) or Combat (if there are enemies around).

Let me know how it goes.

 

That sounds like a cool idea, but would require some game design management to prevent the HUD from getting too noisy. With all the target boxes/arrows, the cockpit HUD, and HUD messages, adding directional indicators for all projectiles might put things over the edge in terms of visual readability.

I think however that directional indicators for missiles is not a bad idea, since they are not fired at anywhere near the same rate as projectiles.

I'll put some thought into capital ship combat when I upgrade the GameplayDemo scene (sometime in the next several weeks) to include fighter vs capital ships, and subsystem targeting. Loads of AA fire from multiple cap ship weapons definitely need to be considered in terms of gameplay balance.

 

Version 1.2 is still pending review, but you can play the demo now on WebGL.

 

Instead of displaying individual notices, I was more thinking the evasion system would work sort of like DDR in the sense that you could have row for each direction of evasion with arrows indicating when to thrust up, down, left or right to evade. So you wouldn't be calculating the evades yourself, just pulling in whatever direction the computer tells you when it tells you to evade anything standing still or moving in a straight line towards you.

I can see what you mean about a noisy hud though, at it's simplest it could just be a glow from the direction you need to pull in to avoid or four arrows on a dashboard that glow when you need to evade in that direction.

You wouldn't be tracking individual bullets on the HUD either, you'd merely be giving indicators of which way to thrust to evade anything that is incoming. Giving you a way to avoid capital ship AA even if you're seeing the indicator as soon as they open fire because you're that close, could fudge things a bit at closer ranges so that if you evade in the right direction within a certain amount of frames of something firing at you, you could dodge whatever was fired by reducing the size of the valid hitboxes or ignoring them entirely if precisely timed to simulate a dodge.

Even adding this function to missiles alone would allow you to juke them off your tail without turning around in your seat to see which angle they are coming from or even spin/pitch/roll/yaw to fire at them so quickly you barely even have a chance to aim.

https://imgur.com/a/RQn05Hy

I hope this mockup gives you an understanding of the basic concept. There would never be more than four or six arrows, they would just light up giving the player a chance to evade. Someone using their eyes would be able to pick which if more than one option appears is best to remain on course/not to dodge into denser regions of fire and end up having to constantly time their evades.

If it was done right, to other players it would look like people are dodging S*** before they see it because that is exactly what they'll be doing.

 

Hey Billy, we updated to the new version and it broke multiplayer. We reverted to the old version to continue development at our end. Hopefully we can sort thru the new project and figure out where to get the health and rearm stuff. It would be awesome to get the new features working in multiplayer. Is there a multiplayer update coming out for the new version?

 

Hi Billy,

This is Paul (Ariock's partner in crime). We are still using the network version of your Space Combat Kit.

Is there a way to set a vehicle's armor value back to it's starting value in the network multiplayer version?? (i.e repair the armor)

Paul

 

I can't promise the multiplayer will be updated along with the singleplayer version. It's functional but not ready at all for primetime, not even with version 1.1 of the kit (hence why it's alpha). I mean to work on it for a while every week, but it's going to be quite slow compared to the rest of the updates.

You basically need to reset each of the health modules, and then transmit this to other players via the NetworkHealth component. I'll see if I can find some time tomorrow to update the package with this.

 

Thanks!

 

Hi Billy,

Just to say thanks and awesome work with the multiplayer version. Tried it out on the weekend and it works really well - only thing I couldn't get working was the flyByParticles seems to be there but just not seeing it rendered on screen for some reason.
Have not used Photon before I think that it was the right choice given that UNET is now being deprecated.
Keep up the good work on this excellent kit and looking forwards to any future updates.

 

Great to hear it!

 

nice work, always love to see other people working on space projects. The ground is boring isn't it!?

Nice simplistic GUI. The hard part comes when you expand and have a lot of complexity to display to the user. Keeping it simple while still being able to display complex information to the player is the difficult part.

This would be a great learning project for those wanting to learn GUI and how to do a targeting indicator system.

 

Hi everyone, the package was declined again, fixed again, and resent. Unfortunately there was an offending Unitypackage in the Rotorz folder that I didn't notice, as well as a couple of other details.

Again, if you have an invoice number, just let me know in PMs that you'd like to try out v1.2, and I'll send a download link

 

I will wait further. I just read the Asset Store Submission Guidelines and found it quite strict. But it's ok for me as it's extra protection and assurance for the product I've purchased. It's also for peace of mind. Thanks for the update!

 

It's live!

 

Woohooo! Finally!!!

 

New Version! Thank You !!

 

I am soooo with you in this!

 

Just imported the update

Just FYI
Assets/SpaceCombatKit/Scripts/SpaceCombat/AI/Behaviours/BehaviourState.cs(9,17): error CS0101: The namespace `VSX.UniversalVehicleCombat' already contains a definition for `BehaviourState'

I open "BehaviourState" and it's just a couple enums (BehaviourState, CombatState), I found the same enums in "AIExample". (AIExample has bool isAI in it)

UPDATE:
I assumed that AIExample was meant to be removed. Which I did.
Trying to run GamePlayDemo
- error CS0115: `VSX.UniversalVehicleCombat.Player.IsAI' is marked as an override but no suitable property found to override (You probably meant to put .isAI in GameAgent)
- error CS0115: VSX.UniversalVehicleCombat.Ship.OnDestroyed(VSX.UniversalVehicleCombat.GameAgent)' is marked as an override but no suitable method found to override (OnDestroyed in Vehicle?)
error CS0115: `VSX.UniversalVehicleCombat.ShieldGenerator.ShowHitEffect(UnityEngine.Vector3, float)' is marked as an override but no suitable method found to override (ShowHitEffect in HealthGenerator?)

I am frantically trying to marry your code with my ship mechanic code for an exhibition on Sunday. So far I've run into snags from both sets, of course.

One of my problems is that the GameAgent doesn't seem to call OnFocusedVehicleChange, when I EnterVehicle initially (Thus no camera view change). I was hoping your new code fixed that ...

 

I moved the BehaviourState and CombatState enums to their own script because they don't belong in any script that has 'Example' in the name. Besides, they are also used for the autopilot.

Yes, I got rid of the AIExample and Player derived classes as they had no additional necessary functionality. I probably should leave the GameAgent class as an inheritable class though, just to make it easy to create additional functionality for different types of game agents.

Player.cs can be removed, just use GameAgent.cs instead.

Use Vehicle.cs instead of Ship.cs. Again I got rid of it as it has no additional functionality, but again I will make sure it is fully inheritable for you to derive from if you wish.

Use HealthGenerator (setting the HealthType in the inspector) and get rid of ArmorGenerator and ShieldGenerator. I got rid of these as I moved the shield effects code to HealthFixture where it belongs.

Just to be clear, a HealthFixture is a fixed part of a ship to which you can link a HealthGenerator module. The HealthFixture component basically consists of a mesh (for visibility/effects) and collider, and passes hit/heal events to the HealthGenerator component linked to it. Therefore it makes more sense to craft the shield VFX on the HealthFixture component, and not have it as part of the HealthGenerator. So that resulted in no need for the derived classes ArmorGenerator and ShieldGenerator, so I got rid of them.

1. Use GameAgent.cs (not Player.cs or AIExample.cs, which you can get rid of).

2. Make sure there's a UVCEventManager component in the scene.

3. For an interior camera view, make sure your ship has a child transform with a CameraViewTarget component on it, positioned in the cockpit of the ship, and with the Camera View variable set to Interior.

4. For an exterior camera view, make sure your ship has a child transform with a CameraViewTarget component on it, positioned behind the ship, and with the Camera View variable set to Exterior.

5. Set the Default View in the inspector of the Vehicle Camera to whatever you'd like the camera to default to when entering a new vehicle.

Good luck with your exhibition! And feel free to ask any more questions. I definitely should have written some notes on the changes, and the UserGuide needs updating too.

 

Thank you so much for the quick response. I'll be at it till late tonight.

 

I've now successfully set up SCK in an existing project after the second try (1st try I received an error about "MemoryStream" is corrupted and had to restart Unity 2018.1.6).

Since I will be using this in a non-space game and have already imported the files in the Project Settings before as well as have an existing Post Processing Stack (v1) files, I didn't include those items from the version 1.2 package (not sure if that is ok and any impact it may cause). Below, I'm just sharing the steps that I did that made it work up until the setup of the Radar Tracking:

1. I deleted the SpaceCombatKit folder, removed any connected SCK scripts in my GameObjects, and any Post Processing Behaviour scripts attached to Cameras. Console errors and warnings will appear if those were not removed before import.
   
   
2. Updated/Downloaded SCK vers. 1.2 and imported it in my project.
   
   
3. Had to comment out Line 284 in Vehicle.cs as it is throwing a Console Error.
   
   
   Code (CSharp):

   1.  
   2. protected virtual void Start()
   3. {
   4.      // -- RadarSceneManager.Instance.Register(this);
   5. }
4. Followed the instructions in the Youtube Video Tutorials 1-6 here.
   
   
5. Brought back (commented in) Line 284 in Vehicle.cs because the RadarSceneManager was already setup in Tutorial 6.

So far so good! Now hungering to watch the next video tutorial on setting up the HUD!

Great job Billy! Thanks for this update!

Note: The update trashed my Canvas Minimap/Compass though and somehow removed any specified values that I have indicated for it before. But I am ok with that as I will be replacing it with the 3D Radar + HUD later on.

 

What does the new update add besides architectural changes ? I noticed you mentioned a capital ship example but I didn’t notice an example scene ?

Also love the new ship movement and models . Looks fantastic

 

Not sure what could be causing this issue for you, I haven't had any problems myself opening in 2018.1.1.

Yes, the package includes Post Processing Stack 1.2, so if you have any other version in your project, you'll have to choose one or the other.

The radar functionality needs a RadarSceneManager component in the scene, always. This makes it much easier to register, store and access target information from one place.

Glad you like it! I'll get that next tutorial vid up very soon.

Not sure how this could happen, do you have any more information on this, preferably some kind of stripped down test project I could look at?

 

Thanks! Most of the work over the last few months went into multiplayer, and in fact a lot of this update is simply tidying up the changes that the multiplayer necessitated in the kit.

Note that multiplayer is still entirely separated, it was mainly a question of adding events that multiplayer could hook into when a player did something, and providing the ability to 'force-activate' functionality on network vehicles receiving data over the network (for example providing the ability to fire weapons without consideration of power availability or fire rate).

As described on the Asset Store listing -> 'Releases' dropdown, the main changes were:

- New demo scene.
- New ship and cockpit models;
- 6DOF flight;
- Floating origin system;
- Improved camera view system;
- Improved health fixtures;
- Improved loadout menu;
- Full code documentation;
- Lots of tidying up;

That's probably not the whole story, because as I worked on multiplayer I made many incremental improvements and changes to the base kit and (silly me) did not log them. I'll be sure to do a better job of logging changes next update, which should also help smooth the updates with your projects.

The capital ship demo is coming along well, it will be sent to the asset store in the next update on Monday.

 

Yeah, that was the first time I experienced the MemoryStream error. Immediately after that my Scene view got blanked out so I had to restart Unity. A prompt window also appeared informing me about that. But I had a backup so I was not that worried. For the MiniMap, I was using a free asset that I customized to have a Compass. Right now, I've accepted replacing that one with your 3D Radar and HUD so I'm ok and would prefer just spending time to continue learning setting up SCK.

I've now managed to set up a control for a basic Boat Vehicle by modifying Vehicle.cs and adding "Boat" in the VehicleControlClass enum. Then I duplicated SpaceVehicleEngines.cs into BoatVehicleEngines.cs, changed the Class Name into BoatVehicleEngines and attached that script to my Boat GameObject already w/ Buoyancy, Rigibody, and the other necessary SCK scripts. Lastly, I then had to specify my Boat GameObject as the Starting Vehicle in the Player GameObject and changed Vehicle Control Class field value into "Boat" under the PlayerSpaceFighterControl GameObject. Also had to set Input Type to "Keyboard". Now, my Boat can move at sea! But forward movement rotates the Boat to front dive and pressing Q and E makes it dive/rotate sideways. Mouselook also of course doesn't work. Can you provide me some tips on what files do I need to modify to correct this? Will send you a PM with a video on how my previous controls work without SCK to give you some idea.

 

Answered in PMs.

 

So will be able to walk around on the capital ships as well as walk and drive around on planets? Be fantastic if you could walk around on a capital ship or space station

 

I will only be providing a simple demo for these things, but technically yes, that's what you will be able to do with these updates

 

Cool, I know what to use now to get multiple units though I have to go and put some more cash on the bank and get it but great Look forward to the demo

 

Thanks Billy for helping me earlier! Anyhow, I'm wondering why just include a demo for those planned features? If you will do that I'm afraid there might be a tendency that the version in the demo becomes more updated than those in the main scripts and it might be difficult to track which parts have changed. If you will be pushing for that, maybe you can just indicate some information about it in the Asset Store's page to avoid the possibility of confusion upon installation of the asset by new users. What I suggest though is still including only the improvements to the core engine and things that will make it easier to do the initial setup of the core features.

If you're planning on releasing paid add-ons to SCK in the future to extend its features, just separate those things that are truly optional. I guess this is so it would also make the engine easier to dissect and control the development / release of non-core features. For customers, they will be able to just get only the features that they need and it might become easier for you to determine which features to focus development on based on demand/sales of each. This may also be a good way to display the kit's excellent modular design.

Just my 2 cents.

 

Thanks for the feedback! When I say 'demo', I simply mean that as I add features to the kit, I will create simple demos similar (or maybe an addition to) the GameplayDemo scene. I will not be creating huge demos for specific implementations of the features.

The kit already contains a clear separation of the 'core functionality' from genre-specific functionality. That's why there is the folder named UniversalVehicleCombat (which contains the bulk of the code and is actually not particularly specific to space games) and SpaceCombat (for space game specific code). If I add a third person controller integration, any code and art specific to it will go in a separate folder.

When I do start branching out into a variety of different vehicle types, the code and assets for it will also be modularly separated from that foundational code. I'm not sure yet if I will release multiple packages, or release one new package that contains everything (probably the latter as I prefer the idea of maintaining one big product), but whichever way it goes, it will never become more difficult to remove the parts that you don't want, and the parts that you do use will never become cluttered with code for the parts that you don't.

As I said before though, at the moment I'm focused on improving the current space kit package, improving the workflow and documentation until it's very easy to use. This will benefit everyone, including people who, like you, are using the kit's modular nature to adapt it to different genres.

 

Ok, I understand. Definitely agree with you on improving SCK especially by making it easier to use. I think the majority of Asset customers prefers ease of use and smooth setup on the assets they acquire because most of us actually want to save time by not doing the nitty-gritty parts for some of the stuff needed to make a complete game. This is so we can instead focus more on those parts in the development process that we actually want to tackle.

Right now anybody who wants to use SCK to have a more customized game (especially if its not a space shooter) must learn Unity Interfaces. Here's a great introductory Youtube video by Jonathan Weinberger.

Edit: Aside from Interfaces, you would really need to delve deeper into SCK's system and understand how everything ticks for your type of non-space Vehicle. Prepare some significant amount of time for this on research and coding.

 

Agreed Most of us haven't got the time to do the nitty gritty parts as you need to get the web sites ready and any promotion or Crowdfunding, Kickstarter ready if we are going to be serious with your game Preferably I guess people would really want to set up the missions and levels and focus on that rather than the mechanics to be perfectly frank plus getting in voice actors if your game is going to use voice acting and the promotion of their games for if you want your game to be successful these have to be done.

I have a few games in mind one an FPS/RTS in space and on other planets and another game which would be your average space fighter combat FPS with planetary ground levels so units that could be commanded from a keyboard menu would be great and cut the making game process down to an acceptable time level would be fantastic .

Looking forward to those demo's

 

When I bought SCK, I was looking for an experience similar to when I first set up and used Enviro. It was just a breeze and I was able to focus on other requirements of my game. It really reduced a significant amount of time on production. To date, I still haven't found any other Unity Asset with that capability and ease of implementation + outstanding support. But I really can't make an accurate comparison of the two because my requirements now is different and how I chose what type of Asset to utilize to meet it. Just sharing my experience.

Anyhow, regarding the current version of SCK, for my type of requirements, I feel it is more of a framework really rather than a system that can just be simply setup and run. But for your average space fighter combat FPS requirements, I guess it suits it better and you will probably have an easier experience than mine. For the RTS, you will need significantly more time to customize SCK and that I'm sure will be more difficult than my initial requirements which is just being able to drive a Boat with a third-person view and a mouselook while hopefully utilizing the various Subsystems and Modules later on.

 

A follow-up from a previous post. I made it work, but I had to do some pretty fundamental changes. I am working on an FPS game, but the player object I have wasn't a Rigidbody, using a Rigidbody controller. So I made a new Rigidbody Vehicle called "PlayerBody" and hacked up the Standard Assets Rigidbody Controller, converting it to an IVehicle controller. It works, but it sure isn't smooth. I need to find a better FPS Rigidbody controller.

 

Thanks for the feedback! It's really great to get a clear perspective on how it comes across for customers.

You're absolutely right that right now, it's main strength is as a framework. When you want to create spaceships (and other vehicles) with all sorts of different parts and functions such as engines, weapons, radar, HUD, armor/shields etc, and also create it all in a way that you can extend and add to it without the code becoming messy and tangled, it's not a trivial problem. Part of the utility I wanted to provide was an architecture for vehicles, and particularly spaceships, that solved this big design problem for people.

I totally agree that the main thing I need to do now is to take what I've got and make it more intuitive to see how it works without going into code, and make it as easy as possible to use the flexibility it provides from the inspector.

For spaceships, I feel the kit provides a pretty good coverage of most use cases. But certainly, although the code already provides a lot of flexibility for different vehicles (such as boats or characters) it still needs coding skills. For example, to make the kit work with your boat, you needed to write a new input script (using the IVehicleInput interface) and a boat controller script (using the IVehicleController interface). With that, your boat was perfectly compatible with everything else the kit provided. Yet you did need to learn interfaces for this.

I'm not entirely sure how to reduce the need for some amount of coding when you're making changes at this level, except for writing controllers for different vehicles. Which is what I intend to do eventually, but I have to focus on improving the ease of use of the kit right now, as it is. After that I will focus on broadening the types of things you can do out-of-the-box with additional examples.

If you have any more comments and suggestions, I'd love to hear them. I'm always thinking about how things in the kit can be more logical and intuitive, and especially how I can extend the range of uses while simplifying the architecture and the code.

 

Actually the Customer (developer) needs more than just coding skills and understanding Unity Interfaces. To totally make use of most of the features, a substantial amount of time is needed in studying the framework (for my type of requirements that is)... like what does this piece of code do and how a particular function works, etc. That is really the big hurdle here. The codes are commented so it provides some clues but you still won't easily understand how things connect with each other and you don't know where to start looking hence it becomes overwhelming at times. So at the current version of SCK, the important question that each developer must then ask themselves and decide upon is: How much time am I willing to spend to learn how things work in SCK to implement what I need vs. would I rather just write the system myself and maybe save time by just creating my own project needs?

I guess the answer then would really depend on the complexity of your requirements. I will try to spend a few more days to understand SCK and see if I can make just the movement part working while having it compatible to connect with Subsystems and Modules...

I think one of the most important thing for SCK to improve upon is to make it easier to support setting up the Movement of basic Vehicles. Maybe one for each type: Air, Land, and Sea. Then maybe even use something like a Vehicle Profile (i.e. ScriptableObjects) to be able to edit some properties of each Vehicle type through the Inspector. If SCK already has that, developers can more easily just refer to the Profile closest to what they require and if they want to extend it further, they can just look at those fewer codes without having to understand more than what they need to. In each Vehicle Profile, having a way to enable/disable the use of various Subsystems and Modules (maybe by using checkboxes) would greatly make the set up easier. Well, these are just some initial stuff I would be wishing for in a system like this. This would definitely boost the ease of use. If someone can't even set up movement easily, they won't be able to utilize the other features.