[RELEASED] Retro Mech Simulator

Asset Store
WebGL Demo

Retro Mech Simulator is a starter kit for building first-person mech simulator games. Although the sample assets in the kit are done in a retro style, you are of course free to make your game with any style of graphics.

• Numerous scripts for standard mech components, such as hull, reactor, engine, weapons, radar, targeting system, and optionally shields.
• 2 fully-functional example mechs complete with first-person cockpits with interactive displays. Pilot your mech, target enemies, fire weapons, toggle radar scale, balance shields forward and backward, arrange weapons into firing groups, toggle first-person and third-person camera, and more.
• Procedural IK-driven leg animations for realistic foot placement over uneven terrain.
• 3 skin choices for the example mechs.
• Support for HUD color themes, with three example themes.
• 12 fully-functional example weapons with models and textures (4 autocannons, 4 lasers, 3 missile launchers, 1 railgun).
• AI framework with fully functional built-in support for navigation, combat, and other basics.
• 4 example building.
• 2 example missions.
• Example loadout screen for arming a mech.
• 218 sound effects, some of which are actually good!
• 7 desert terrain textures, 2 tundra textures.
• Animated sprites for explosions, sparks, shield impacts, and more.
• Damage system which breaks weapon damage down into separate shield, armor, and internal damage categories.
• Extensive documentation with 29+ page manual.
• Various editor tools and extensions to make developing easier.
• Professionally coded, highly extensible and modular codebase that can be tailored to meet the needs of your game.
• Hundreds of included scripts will save your team hundreds of hours of development time.

 

Why the retro theme? Do I have to use retro graphics?
I grew up on 90's mech sims and have a lot of nostalgia for them. Also, I am building this solo and am more of a developer than an artist, and the retro art style is something I can manage in a reasonable amount of time. However, you are free to use whatever visual style you prefer.

Do I have to build the HUD into the cockpit displays?
No, you can always use a regular screen space canvas, and in fact I include a prefab and cockpit variant with this approach if you prefer it.

Does it support scriptable render pipelines (SRP)?
The kit uses the built-in renderer. Other than a couple of trivial sprite shaders, there is no custom graphics code, so it should not be difficult to convert to URP or HDRP. However, I can't offer any support for converting the project to use with a SRP.

What platforms are supported?
This kit is designed for standalone builds (Windows/Mac/Linux). It should not take much work to adapt the template for most other platforms, but I don't officially support them at this time.

Does it have built-in multiplayer support?
No, and it never will. I am developing this solo and multiplayer would increase the scope of this kit beyond what I can manage by myself (not to mention that it's very hard to test multiplayer solo). Additionally, I wouldn't want to tie the kit to a specific proprietary multiplayer framework.

Is this a complete game?
This kit includes everything you need to build mechs and pilot them in combat, and the basics for creating missions with objectives. The kit comes with 2 example missions, 2 example mechs, 4 example buildings, and 12 example weapons, a variety of visual effects and hundreds of sound effects, and AI for other mechs besides the player. It does not include a full campaign or special game modes.

How much coding is required?
You can build fully functional mechs, cockpits, and basic weapons (lasers, cannons, missile launchers), and drop them into combat without writing any code. Depending on your specific goals, you may need to write code for things like mission objectives, custom weapons, advanced AI, or additional simulation features.

How easy is the kit to use?
Every mech game is different, so this answer partially depends on what kind of mech game you're planning to make and what features you plan to include. I have attempted to make the kit reasonably flexible without making it horrendously complicated.

Setting up missions and balancing mechs/weapons should be pretty easy. The complexity mostly comes in building new mechs and weapons.

There are "Quick config" buttons on many key components that will partially automate the setup process and save you a lot of time. That said, you aren't going to be cranking out new mech prefabs from scratch in 5 minutes. Once you've created the 3D models and associated textures, it might take anywhere from 30 minutes to several hours to build a fully functional mech prefab. Cockpits might go faster or slower depending on whether you use a single shared "holographic" HUD for all mechs, or incorporate some of the HUD into the cockpit design as I have done in the example cockpits.

Overall I would say the kit is most appropriate for developers of intermediate to advanced skill. If you plan on heavily editing or extending the scripts, you will benefit greatly from having a strong understanding of abstraction with interfaces and generics.

How flexible is the code?
I have done my best to engineer a modular, highly flexible code base that is easy to modify or extend without having to rewrite large chunks of the code. This means heavy use of abstraction (abstract classes, interfaces, generics, etc), extensible class design (most methods are virtual), and heavy emphasis on composition using Unity's component-based paradigm. Most of the scripts are light on the CPU and you should not expect any performance loss from the use of abstraction.

How much can mechs be customized?
The kit supports a lot of customization in the Unity Editor. You can define what types of parts mechs will be built from. Using the built-in components, you can define the specific amount of armor and internal structure assigned to each part and weapon, whether the mech has shields, which body part holds each internal system, the stuctural integrity of each internal system, the maximum capacity and recharge rate of the reactor/shields/energy weapons, the speed and acceleration of the engine, the shields/armor/internals damage output and maximum range of each weapon, how far the mech's upper body can rotate, etc.

As far as built-in user interface for players, right now I only have an interface for changing the weapons loadout and selected skin. There is no built-in gameplay UI for customizing other parts of the mechs (such as armor, shields, internal systems) because every game will be different and it is impossible to develop a single universal system. One game might let you allocate armor to each part, while others might have fixed armor. Your mechs might have preconfigured engines, or you might let the player select an engine model or tune the engine. Your universe might have shields, or it might not have shields.

Does it support VR?
The kit does not support VR out of the box. It shouldn't be very difficult to add VR. I'm not officially supporting VR at the moment, but will probably get around to it in the future if the kit sells well.

Any dependencies/third-party plugins?
The kit utilizes a few of the official Unity packages from the package manager (TextMeshPro, Post-Processing Stack v2, unit testing suite). An open-source public domain IK library is used by the animation system and included in the project. No other third party tools or plugins are required (or officially supported).

How is the AI designed?
The AI code follows a Goal-Activity structure - Goals define what the AI wants to do and Activities define how the AI works to accomplish those goals. There are several default Goals, such as "attack nearby enemies" and "flee when heavily damaged", and you can define additional Goals (such as "follow waypoints", or "attack these buildings") when constructing a mission.

At runtime, AI selects a goal using a customizable weighted priority system rather than a finite state machine. Unity's NavMesh system is used for pathfinding. The AI operates a mech by providing virtual inputs that match how a player interacts with a mech.

Does it have jumpjets?
There is currently no jumpjet-style feature and I think that's outside the scope of what I want to do - not to mention that I don't want to copy features from the BattleTech universe too closely because that's a trademarked franchise that's still actively publishing games.

Does it have tanks/hovercraft/aircraft/etc?
Right now there are no vehicles other than mechs included with the kit. The included scripts are highly modular and it should not be too difficult to create new types of vehicles.

Can mechs be knocked down/get back up?
Mechs cannot be knocked down while alive because that's definitely outside the scope of what I want to do. However, mechs that are destroyed through loss of a leg will go ragdoll and fall down.

Does it have AI squadmates?
The kit currently does not include a full squadmate system. When building a mission, you can set up mechs on the player's team to follow the player. However, they don't communicate with the player and there's no in-game method of giving them orders.

If the kit sells well, I will probably add support for AI squadmates in the future. In the meantime, you can always build your own squadmate system.

 

Version 1.0.1 - 2020-12-2

• AI bug fixes and general improvements
• Added AI showcase scene with spectator camera, where you can watch 10 AI-controlled mechs in a 5v5 skirmish.
• Expanded documentation with several new sections
• Added muzzle-flash effect to autocannons
• Simplified setting up leg-based deaths (no longer requires extra steps)
• Added a way to quickly change a mech's skin while editing a scene

Version 1.0.2 - 2020-12-7

• Procedural animation fixes/improvements, including new setting to adjust the number of IK solver steps.
• Added additional constraint for IK joints to fix knees sometimes bending the wrong way.
• Added two new example buildings, Small Bunker and Large Bunker.
• Simplified setup process for buildings; use better default values for several related scripts.
• Added "Creating Buildings" to documentation.

Version 1.0.3 - 2020-12-14

• Added a third example mission
• Added three new terrain textures (2 tundra, 1 snow) and spruced up the example terrain.
• Greatly increased the Bull's acceleration for more responsive throttle and better gameplay.
• Added "start fully charged" setting for mechs
• Improvements to Shield, Reactor, and Engine Editors.
• Many bug fixes

Version 1.0.4 - 2021-1-27

• Fixed bugs on Example Loadout Screen, and improved UI fade animation
• Added notes to most of the scenes
• Minor updates to documentation

Version 1.0.5 - 2021-2-15

• Fixed target/waypoint indicator alignment bugs
  
• Added very simple mission select screen
  
• Improved how player's selected mech loadout is passed to PlayerMechSpawner (now uses a ScriptableObject asset)

Version 1.1.0 - 2021-2-25

• Refactored BipedWalker, moving some code into a new base class that can be extended with alternate animation systems
• You can now specify whether BipedWalker animates during

  Update()

  or

  FixedUpdate()

• Fixed gravity not being applied if mech's speed was 0
• Mostly fixed "skating" issue where legs would not animate when moving diagonally up a steep slope
• The bouncing part of the movement animations is now smoother
• Wasp does not jump as far into the air when moving down slopes
• Most HUD elements are now optional
• Implemented depenetration system to fix rare cases where mechs could clip through solid objects. This new system is more accurate than the previous (BoxCast-driven) system, and resolves issues with the Wasp getting stuck while trying to move diagonally up slopes.
  
• Mechs can now push each other a bit (optional, on by default)
• You can now specify a custom sort order for mission objectives, if they are not appearing in the desired order in the UI
  
• Slightly improved Inspector GUI for making mechs invulnerable/vulnerable

Version 1.1.1 - 2021-3-01

• Fixed issues with Water Treatment Plant colliders

Version 1.2.0 - 2023-3-03

• Upgraded to Unity 2020.3.45f1
• Added separate prefabs for destroyed versions of buildings
• Fixed shader compiler errors under Metal, caused by case-sensitive shader keyword
• Fixed error spam caused by extra Event System in some scenes
• Fixed mechs falling through terrain when they go ragdoll
• Set scale and position of all prefabs to (1,1,1) and (0,0,0) respectively as per Asset Store requirements
• Fixed error that could occur in Engine.cs when a mech is killed
• Fixed some TextMeshPro warnings

 

Retro Mech Simulator is currently discounted by 50%. This discounted price should be available for about two weeks. Don't miss your chance to get in on the savings!

 

Not sure if this is the right place to ask questions, but is there a reason the first example scene has large white numerals that cycle and display in front of the player/Mech when you play?

In third person, I can sometimes see it too, and it looks like it shows the distance in meters to whatever the cursor is pointed at but the text is very large.

Here's a screenshot with a large number "1":

 

Hi @julian-kinsman , thanks for purchasing the template and thanks for getting in touch! That's definitely a bug; you can see how it's supposed to look in the screenshots and videos. I see you're using 2019.4.18f1. I last tested in 2019.4.16f1, so I'll upgrade to 2019.4.18f1 and see if I can reproduce.

EDIT: Just upgrade to 2019.4.18f1 and am not seeing that bug. Some things to try:

• If you haven't already, try updating the TextMeshPro package to the latest version (2.1.3)
• It's possible that some files were corrupted when you imported the project. You may be able to fix it by right-clicking in the Project panel and selecting "reimport all". This can take a few minutes but has fixed many oddball issues in the past.

Let me know if that helps or if you are still experiencing issues.

 

EDIT: Thanks for your reply. Updating to TextMeshPro 2.1.3 solved the issue. Now the range indicator (that was what the large text was) is displaying properly as tinier font. Thank-you!

 

Great, glad to help!

 

Clicking on same mech list element in Example Loadout Screen creates more and more copies of hardpoint UI elements. Only when another mech list element is clicked, hardpoint UI is cleared out of excessive copies.
Apparently hardpoint boxes are destroyed only when mech is refreshed, but created every time the mech list element is clicked.

Weapon list and hardpoint box fade effect is not working, because weapon canvas group has alpha as always 1, so it's never transparent, and there is nothing that would reset it.

Turning mech and pressing same mech UI element also causes hardpoint boxes to get repositioned, where they try to keep a set offset from physical mech hardpoints. With mech turned this causes hardpoint UI to get offscreen, get behind mech itself and overlap each other.

First two can be fixed by forcing all hardpoint UI destruction and setting weapon canvas group alpha to 0 at the beginning of OnClickMech function. Last one I can fix but I won't say how to leave it as an exercise for the dear reader.

Documentation needs to expand on the transition from loadout/hub scene into missions, specifically, how data is supposed to be transported to mission scene. I found that LoadoutScreen.cs uses static member of PlayerMechSpawner class to keep player mech data.
Is that a preferred way for this asset that I should stick to? Or should I disregard this specific instance and just make my own "keeping data between scenes" system from scratch?

 

Thanks for reporting those bugs! I will fix them ASAP.

However, to be clear - the Loadout screen is intended more as a barebones example than a complete feature. Every mech game handles loadouts differently. Some games only let you customize the weapons and skin, like the example. On the other end of the spectrum, there are games like Mechwarrior 3 where the player can change exactly how much armor is allocated to each body part, the type of armor and internal structure, the specific model of engine that's installed, what components and ammo are installed in each body part, etc. And of course many games let you customize the loadout for a squad of several mechs, adding additional complexity. It would be madness to try to build a single loadout screen that would work for every single game, so I built a simple example with the expectation that many teams will end up rebuilding the loadout screen to suit their particular game.

I apologize that I was not more clear on preserving data between the loadout screen and gameplay. The solution I used, a static property on PlayerMechSpawner, is really just a quick-and-dirty solution. There are many ways to share data between scenes; here again the best approach may vary depending on the specifics of your game. If my simple solution meets your needs, then by all means stick with it. If it doesn't meet your needs, you can modify it or build your own system.

Other than the issues you highlighted, I hope the kit works well for you. Please let me know if you have any other questions.

 

And thank you for replying that fast!

I know that loadout scene is a placeholder, but it's the first scene one loads when testing the kit out, so I thought it's quite important to report if it glitches from button mashing or has non-working parts, as it is a part of a first impression.
Anyway, UI is something that I will definitely remake, so it doesn't matter that much.

Right, so the data question I can solve myself, without worrying about future conflicts.

So... can't really think of any other bad things to say about your work, really feels like a "very early alpha" of a mech game, needing mostly content to fill up, and very user(developer?) friendly. Not to mention it's pretty much like that right out of the box, barely a month after release. Good job.

I'll definitely post updates on my progress, don't worry!

 

@White_Mouse I've fixed the bugs and submitted an update for review. It should go live in the next few days. If you need a quick fix in the meantime, add this line of code at the beginning of the

OnClickMech()

function:

Code (CSharp):

1. virtual protected void OnClickMech(MechPropertiesModel mechProperties) {
2.     if (this.mechProperties == mechProperties) return;

 

Thank you! But I did it already my way, as I mentioned above.

 

@White_Mouse Version 1.0.4 is now live on the Asset Store.

You described "forcing all hardpoint UI destruction". The fix I mentioned above - essentially skipping

OnClickMech()

when the user reselects the same mech - prevents duplicate hardpoint boxes from getting created and thus does not require destroying and recreating the UI, nor dealing with UI alignment issues from the mech being rotated. I also reconfigured the fade animation so the hardpoint boxes will fade in again when you switch mechs.

 

Well, it really doesn't matter for a single sample script either way, but I was thinking more about how such an UI will work in an actual mech setup screen and it will not work properly if player has two or more identical mechs in the inventory. Selecting one of duplicate mechs will cause buttons for others to ignore clicks, due to mechProperties being the same.

I believe better approach for an actual game would be to go for full refresh of UI whenever possible, just to avoid strange behaviours like that.

 

For those who are still considering the kit, there is now a playable WebGL demo on Unity Play! Retro Mech Simulator - Kit Demo - Unity Play

 

Strange waypoint UI widget behaviours. Repeatable both in Unity and in WebGL demo.

First, if I turn my view more than 90 degrees away from a waypoint, it's widget starts pointing towards opposite direction of a waypoint.
Looking straight at waypoint, 0 degrees. Widget is on waypoint.
Turning right, ~70 degrees. Widget is on left screen border.
Turning right, ~120 degrees. Widget appears on the right screen border.
Turning right, ~170 degrees. Widget appears on the right screen border.
Turning right, ~200 degrees. Widget appears on the left screen border.
If I were to try to turn towards widget when turned away from waypoint for more than 90 degrees, I would get stuck looking in the opposite direction.

Second, widget tends to slide down when turning away from a waypoint, first disappearing behind the cockpit geometry, then offscreen. As turning continues, it slides down from the top screen border. I think a better behaviour would be to just get stuck in the bottom corner closest to waypoint. Or, better yet, go into compass mode, where widget slides across all screen borders and angle between reticle and widget corresponds to top-down angle between mech and waypoint.

Third, switch between widget-on-waypoint-transform and widget-on-screen-border uses angle from mech's torso, not from player camera.
If I align cockpit and torso towards waypoint, then rotate cockpit all the way left, then start rotating mech right, widget will jump off waypoint and stick to screen border when torso rotates away more than ~45 degrees from waypoint, but since cockpit is rotated, waypoint is still in full view, near reticle, when that happens.

 

@White_Mouse Thanks for the detailed bug report! I've just submitted a new build to the Asset Store; it should get published in the next day or so. The first and third issues you mentioned should be completely fixed. The second issue is mostly fixed, because the waypoint indicator now maintains proper vertical position when the waypoint is off-screen. However, if the waypoint is much lower than you are, or you're looking up, the indicator will be positioned near the bottom of the screen and can still disappear behind the cockpit geometry. As you noted, there are several ways to fix this. Different teams may want to handle this in different ways, so at the moment I'm inclined to leave it how it is.

This update also includes the mission select screen seen in the WebGL build, and some corresponding code improvements. The player's mech loadout is now saved to a ScriptableObject when the player leaves the Loadout screen, rather than saving it to a static variable on PlayerMechSpawner. The mission that the player selected is stored in another ScriptableObject so it can be loaded after the player leaves the Loadout screen.

 

Bought your asset a couple of days ago, i like it so far. But was wondering, is this compatible with say SlavaZ'z mech models on the asset store or bone driven mech models?

 

Semi off-topic: please do "Retro Sci-Fi Aerial Combat" next You know, "Terminal Velocity", "Rogue Squadron"... I have such ongoing game project on UE4, but I would be super interested in such "template" no matter what engine, I am a fan of that genre, and "Cockpit Games" overall.

 

Thanks, I hope the kit serves you well!

As far as SlavaZ's mech models: going off of his "Mech Constructor: Light and Medium" pack, it looks like his mechs are divided into these components:

• Cockpit
• Backpack
• Shoulders (both shoulders in one mesh)
• Legs (both legs in rigged mesh)

Retro Mech Simulator was designed with the idea that left and right body parts would have separate meshes and colliders, so that they can take damage separately. You can customize the body part categories and could make it work with SlavaZ's mechs, but because the shoulders and legs are not separated into left and right pieces in his mechs, you would have to have shared health (armor/internal structure) for both shoulders and for both legs (I guess you could use box colliders to create separate left and right hit regions, but if one side is destroyed there wouldn't be any way to hide the mesh on that side without hiding it on the other side). Also, because both legs are one mesh instead of being broken into separate thigh and calf for each leg, they could not be used with my procedural animation system.

Page 31 of the documentation for Retro Mech Simulator briefly covers using other animation systems for the legs. In summary, you would need to create a new class that handles some of the basic functions of BipedWalker but works with Mecanim or whatever animation system you want to use. I am planning to eventually split some of BipedWalker into a new base class to make this easier, but I don't have a specific timeframe for that in mind.

Thanks for the suggestion. I've already published Retro Space Rail Shooter, which is a beginner-friendly space shooter, although it's more similar to Star Fox or Rebel Assault than to Rogue Squadron. I'm not likely to do another space shooter kit any time soon.

 

What is the proper way to force objectives into specific order?
I assumed order of objective components does that, but they get rearranged back when game runs and two waypoint objectives keep being in the wrong order.
Changing waypoint order in Player Waypoints list in Mission Controller does not help either.

Addition:
Disabling ReactorMeter in Cockpit prefab or deleting ReactorMeter object completely causes many different errors since code treats it's existence as non-optional.
Since UI is very game specific, perhaps all its elements could be treated as optional? It would make it much easier to mix kit's UI with custom UI.

 

@White_Mouse The objectives should appear in the UI in the same order as their respective components in the Inspector. I haven't included a way to override the order, but that's a good idea, so I'll plan on it for the next update.

As far as the objectives getting rearranged: the "Mission Core" object is a prefab, and Unity is a bit buggy in regards to reordering components on a prefab instance. You're not allowed to reorder any component that's part of the original prefab. Unity may appear to let you reorder new components that you've added to the instance (but aren't part of the original prefab), but the order often doesn't get saved. You can check if this is occurring by adjusting the order, selecting a different GameObject, and then reselecting the prefab instance. Unfortunately, the only workaround I know of is to unpack the prefab (right-click the prefab in the scene Hierarchy and select "Unpack prefab".

Making most of the HUD elements optional is a good idea; I'll also plan that for the next update. Thanks for your feedback!

I don't have an exact timeline for the next update, but will try to get that done within the next week.

 

Unpacking prefab resolved ordering problem, great news! Thanks for the idea.

 

Something strange with collisions happening.

I made a big cube with a box collider.
Cube belongs to Default layer.
Cube blocks bullets, but when mech moves faster than 84 km/h, according to speed meter, it phases right through, but is stopped when speed is 84 or below.
Which is weird, since bullets seem to travel much faster than mech and have no trouble being stopped.

I made a custom layer, named test1.
test1 is set to collide with everything in unity collision matrix.
Cube is set to test1 layer.
Cube blocks bullets, but mech phases through, no matter the speed.

And unless I missed it, RetroMechSim Documentation.pdf does not contain a default collision matrix for the project, so it's difficult to see if I messed the matrix up by accident or not.

 

@White_Mouse Obstacles that the mech can collide with are defined in the "Obstacles Layer Mask" field on BipedWalker. By default, the mech can collide with "Default", "3D", "Terrain".

Bullets use Continuous collision detection, but the mechs do not. Right now the collision detection for the mechs is pretty basic - it uses a box cast each update to determine if there is an obstacle in the direction that the mech is moving, and stops movement if so. I had to make the box cast pretty short, particularly with the Wasp, so that the mechs wouldn't falsely detect slopes as impassable obstacles.

I was originally planning to add more sophisticated collision detection/handling for mech movement, but in my testing the box casts were working well enough that it didn't seem like an issue. However, it sounds like I'll need to add depenetration for cases where the box cast misses an obstacle.

 

I tried running through Large Bunker and it sometimes lets the mech through, but not as consistently as a simple large 100x100 cube.

Type of collision detection has no effect on phasing. However, mech has IsKinematic set to true, while bullets have it set to false.
Can't make mech non-kinematic, however, since it starts tumbling all over the place.

 

@White_Mouse Kinematic RigidBodies are RigidBodies that aren't controlled by normal physics; since the mechs don't use normal physics, their Rigidbodies must be kinematic. Regardless, IIRC I'm not using the mech's RigidBody to detect navigation collisions; that's done manually with a box cast, which is completely separate from the Rigidbody's collision detection settings.

Thanks for letting me know about this bug; I will fix it ASAP for the next update. FYI, here's my progress on the next update:

1. Support for reordering objectives in the UI: Done
2. Make HUD elements optional: Done
3. Split basic functionality from BipedWalker into a new base class which could be extended with support for traditional Mecanim animations: Implemented, still testing.
4. Collision detection improvements: Not started yet

I freelance full time, so I have to squeeze updates to Retro Mech Simulator into my spare time. I don't have an exact ETA on the next update yet, but hopefully sometime next week.

 

Yes, collision detection being custom really threw me off here.
I think it warrants a note in documentation as well.

So, I increased Obstacle Raycast Length from 0.2 to 0.5
This stopped guaranteed "Back to the Future effect" where speed of 88 is enough to break the laws of physics.
I also ran around ExampleMission1, aiming for the slopes at the bottom of canyon walls and Wasp at max speed climbs fairly well up to ~45 degrees slopes, stopping at anything higher, which I think is fairly reasonable.

I will proceed with building my level and will post if anything else breaks down and/or gets confusing.

 

Update 1.1.0 was published today (full release notes near the top of the thread). I ended up making some big improvements to BipedWalker while splitting some of its functionality into a base class. This update also includes the new depenetration feature, and optional support for mechs being able to push each other a bit.

Previously, the way BipedWalker handled velocity was a little hacky. It calculated a velocity each frame, but only used this velocity when the mech was airborne. On the ground, the mech was moved using a separate equation that didn't match the velocity. I've cleaned this up so now it always uses velocity.

Now that the mech moves only using a velocity value, I think it will be possible to pass the velocity to a non-kinematic Rigidbody for movement; I'm looking into that for the next update.

By default, the Obstacle Raycast is no longer used for determining when a mech should stop moving. Now, the depenetrator detects collisions and stops the mech when appropriate. This method is much more accurate, as it uses the mech's colliders to detect collision instead of a BoxCast. I kept the BoxCast in place because the AI uses it to determine when it is blocked by an obstacle. There's a new toggle on BipedWalker that you can use to restore the original functionality of the BoxCast stopping the mech when it detects an obstacle.

These were big changes, so please let me know if you spot any bugs that I missed!

 

Getting a warning about physics in example missions.

Physics.ClosestPoint can only be used with a BoxCollider, SphereCollider, CapsuleCollider and a convex MeshCollider.
UnityEngine.Collider:ClosestPoint(Vector3)
OneManEscapePlan.RetroMechSim.Scripts.Sim.DamageSystem.AOEDamageSphere:InflictDamage() (at Assets/OneManEscapePlan/RetroMechSim/Scripts/Sim/DamageSystem/AOE/AOEDamageSphere.cs:62)
OneManEscapePlan.RetroMechSim.Scripts.Sim.DamageSystem.<InflictDamageAfterDelay>d__11:MoveNext() (at Assets/OneManEscapePlan/RetroMechSim/Scripts/Sim/DamageSystem/AOE/AOEDamage.cs:45)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

 

This looks really cool, nice work!

 

@White_Mouse In the included files, AOEDamageSphere is only used by the missile to apply its AOE damage when it explodes. I am not getting any warnings or errors when using missiles in the example missions. Can you use logging or breakpoints to figure out which specific collider you're getting the warning from?

Thanks!

 

I've put a simple Debug.Log() inside AOEDamageSphere.InflictDamage() function.

Of 11 warnings in ExampleMission2, all 11 happened when InflictDamage was working with WaterTreatmentPlant, however total times when InflictDamage was working with WaterTreatmentPlant was 34.

I let hostile NPCs attack water tanks and attacked water tanks myself. Looks like warnings pop up on missile hits specifically.

 

@White_Mouse Thanks! Looks like there are several things wrong with the colliders on the Water Treatment Plant prefab. I'm uploading a new version now, but if you want to fix it in the meantime:

• Remove the second Mesh Collider from the prefab root and select "Convex" for the first mesh collider
  
• Remove the Mesh Collider from Pipes1, since there are already capsule colliders for the pipes

 

can't play the web demo, the play button doesn't do anything.

 

You must use a browser that supports WebGL. The page is hosted by Unity, so if you're still having trouble getting it to play, you'll probably need to contact Unity support.

 

Retro Mech Simulator is currently on sale for 50% off as part of the New Year Sale! Get it while it's hot!

 

Played the unity online demo. Got to say this feels really good. I will be picking it up soon when there is another sale. I just found this and if I had known I would have bought it earlier. I was wondering if you have a discord server for this?

I am a game designer. And am making my own Mech Warrior Style game called Assault Knights 2: Fallen Knight. I would like to invite you to my Game Design Social Media site if you are interested. https://aknighthawks.space. I would love to talk to you more about this awesome system. And you can also make a Space for this asset if you like on my site and show off the work you are doing.

Either way, I will def be buying this soon. So you def have a new customer. This is the 2nd asset I have found that is like Mech Warrior. Mech Combat Kit being the other. I have it and want to see how each of these assets compares to one another. Or even see if I can get them both to work with each other.

 

Thanks! Sorry for the slow reply, I missed your message. I don't currently have a Discord server. I hope Retro Mech Simulator works out well for you!

 

Hi everyone! It's been a while, but there's a new update for Retro Mech Simulator! This started out as a 30-second update to fix a typo in one of the billboard sprite shaders, but I ended up fixing a variety of bugs and errors that could occur in newer versions of Unity, and updating prefabs to suit the latest Asset Store submission guidelines.

v1.2.0

• Upgraded to Unity 2020.3.45f1
• Added separate prefabs for destroyed versions of buildings
• Fixed shader compiler errors under Metal, caused by case-sensitive shader keyword
• Fixed error spam caused by extra Event System in some scenes
• Fixed mechs falling through terrain when they go ragdoll
• Set scale and position of all prefabs to (1,1,1) and (0,0,0) respectively as per Asset Store requirements
• Fixed error that could occur in Engine.cs when a mech is killed
• Fixed some TextMeshPro warnings

Although I updated to Unity 2020.3.x, the changes I've made should be fully backwards compatible with Unity 2019.4.x if you're still using it.

It should be safe to import these changes into an existing project that uses Retro Mech Simulator, as long as you haven't made changes to the original scripts or prefabs in the project (since your changes would then be overwritten). I did change the "Pixels Per Unit" setting of some effects sprite textures, so if you have custom prefabs that used these sprites, it's possible that the sprites may now appear to be too large in-game. If so, you can change the scale of your prefab, or change the PPU of the texture back to 100.

 

Just came on here to say that I appreciate you making this! I've been fiddling around with it and it's lovely to see a bit of that Earthsiege style gameplay.

 

Thanks! I hope you enjoy working with the kit!