Games Scraps: Modular Vehicle Combat - Vehicle combat with buildable vehicles

Great progress on this game, even just messing around in it is fun.

 

Have you checked out rigidbody.SweepTest to see if that suits? If you are teleporting it might not but it it's to check future collisions of a moving object it could help.

 

Oh yeah, Sweeptest. It's probably one I should have mentioned at least. But again it sort of skirts around the goal. It seems weird to have a method to test whether something will move into something else and not have method to test whether something is already colliding with something else.

I haven't experimented with it a lot, but I wasn't able to get SweepTest to replicate a "will this collide at x,y,z position?" method. You might think you could do it just by having a very small distance value, but the problem is, if I remember correctly, that you might start inside another collider, and therefore the Sweeptest won't register it.

EDIT: Just confirmed with a test. SweepTest doesn't register that it's colliding if it starts inside something.

 

The builder release is now also available on Linux! http://www.scrapsgame.com/download

 

Its funny how attached you get to these cars...

 

I think that is what makes it all so beautiful ;D I personally would do the same if I could create stuff like this

 

Yo Nition, are you going to add the ability to create custom made maps? Or even an ingame world editor? People would create some pretty insane S*** to work on some pretty insane tracks and maps ;D Someone (can't find the link at the moment) is making a urban landscape generator/editor type thing on the forums here. I think the two projects would go hand in hand

 

I was extremely bored


This game is absolutely amazing
Be sure to include a sandbox mode in the final version where we can build huge vehicles with infinite money

[HR]
[/HR][HR]
[/HR][HR]
[/HR]
I wonder, why do the default save files look like this

Code (csharp):

1.  
2. <?xml version="1.0" ?>
3. <vehicle>
4.     <info>
5.         <version>1.0</version>
6.         <vehicle_name>Gavin</vehicle_name>
7.         <suspension>21072,21072</suspension>
8.     </info>
9.     <chassis>
10.         <name>Medium Wheeled Chassis</name>
11.     </chassis>
12.     <parts>
13.         <part>
14.             <name>Light Armour (side)</name>
15.             <position>1,0.2500005,-0.25</position>
16.             <rotation_y>90.00001</rotation_y>
17.         </part>
18.         <part>
19.             <name>Light Armour (side)</name>
20.             <position>1,0.25,0.25</position>
21.             <rotation_y>90.00001</rotation_y>
22.         </part>
23.         <part>
24.             <name>Light Armour (side)</name>
25.             <position>-1,0.25,0.25</position>
26.             <rotation_y>270</rotation_y>
27.         </part>
28.         <part>
29.             <name>Light Armour (side)</name>
30. ......
31.  

And the ones I save look like this

Code (csharp):

1.  
2. 7qr5SGhvAOqeYcVLXiBT7pzeavvpIXbKuGSwH4QRFHJbdU65Oxj5ELsYCL28KApF27h9Pex2XlCjoS820LuqdlfUYaF16dlTMDX/JEkFZcQsDduJw2cGsRNL/FXvq6pfArlrE8Gb6yVx4VlQ3TgXzw1xq8Ie8tAPn7jhRbg8QGsYEW+DYTF5fbJDp5j5OGZzTQcaP2Tz+vjUAkRFwb3S/wN5a+gPX/El0tIPm7MSKRH5fXYHzRPTATusZKuUHO11XdHPaQV4bPyeEAQO6KfSSw1cotj/0P9NKG/LG2cbKNwDFkMWJv5ZT8ejfHLQWXVagw7l9ScTsdp7pWVHSGRAAd8XtFmDoC7ifBO4iz0ORkjSRWAe5a7OkmT/r1jBhfqN65dDmkmAE4JTvDus/i/LDnRzFVqNHN+R8Tx4+HUuueRvzJ2/fONvCAmMCz6/MEyddxZ4pxPXW0ECWklkuFUvcJ38tuehKH6ilP1i1BvlI7VFdP2go48gkM0S865QUsjU+eQlAy2pTeU7RIgudUdCBQVt//H97B/FUtb4UP4YB/DXnss/xyVNEOjsvZyUwvIwZQP/IHksKn1vvP7NjflGH3IuRzRKrNOzdOHQTpO8EGHT697JoT39hxUaHCYEoQeu4JJm6NHLVklBM9vjwAcm5AUjeSmpasOBLzmlkfOKP+lX8RUpeKPeV5IAZBu23sSFqEEnm1h2ZSprTySx9MCZVJYpPnt/J5PGoPZ+7uxYa41G1S6hlF3wHGMainpV4kmH8fdxMxY9dbMhLbx6C2w2aKWfqsSwb6z+WvghZTyWqtLvNOJMA+nvc7Rn/oFHBFjPHuZPfE7KWkv+nNhWkZd8Eqjwm7c6QEclFsqjvvyHsD20xG4gdLgbsInV9L+ae262Ey27uY4FIrRQwDnI2jD9HT9bfQsidIpZ0kq8Ys8qOnqJQyH+5o2m2TTwCkn20qoVorp0zFIkxRjEDNWkfaY8cNQPZm7E91PsxIjYVXFpoHtpQl+hWufogNT/2Y63TN8KKRTx5VFc2zcCaZHNG7jVVLVucGnKt7fVmavldM4E0H1/KvCaEwLRY8MP45uqlifz/5yAYRi/C4TxH5X28wLieGAT2qkNvASnlS7eREW46qiPLch143MdudTpk90B4ujvJM4LzKiQysEF6TX3lSGlkL4GPcmLW7r7zAJtSutUSu96CsJnaZWMeuPlpYiNzB41k3IdJN3XpPa+SEftoFLyN6hkW54aHZ8nrg+UTa+L8eYHpS2/YetBK9nJ93VB/XIKLJX3f1bQ6FnF5qKQuyOAoV1KTCEwK5uLNggGCM4itRi+Y1MgJ90GcWKlgU/h7hlplYWY38b3FutQI5Y57BtQGj1K/gHKd+rp+Vps7Pn+8VBNkPu3h ... ... ...
3.  

Why is it encrypted

 

Ah, simply because I added encryption after I made the default files, and then I didn't think to update them. It's a good question though to ask why they're encrypted because you really can't use it to cheat: All the actual stats of the vehicle are recalculated when it's loaded. As you can see it only stores the minimal part info.

Basically I was just being safe in case anything ends up in there which would let someone cheat in a multiplayer match, like giving themselves extra parts for the same price or something. But tell you what, since you can't do anything of the sort at the moment, I'll set encryption back off in the next update.

I definitely want to make it easy to add custom maps and custom parts as well. My plan is basically to create a Unity template for a map and a part (or several), and people can download the free version of Unity to mess around with them, then drop them in the "custom parts" folder or whatever. The only part I have to work out still is how to package it so that for instance models and textures can be included and referenced when you download a part prefab. I've seen that Kerbal Space Program has a big system for that, but then their parts also take ages to load.

 

Will the multiplayer games be of the you-host-a-server-and-others-join type or will you have large servers that host games for everyone?

 

You'll be able to host your own games on a LAN or Internet. There won't be "official" game servers (at least not at first), but there'll be a Master Server that lists all the active Internet games. So you'll be able to find and join other people's online games like you would in Counterstrike or whatever.

So basically the "you-host-a-server-and-others-join type."

 

Then you can prevent the clients from hacking at least, but give it max one week until someone has reverse engineered the game far enough to host a hacked server where he has better parts than everyone else

 

Well, yeah, but that's their prerogative I guess. When a server registers with the Master Server though, I may be able to check it against a hash to see if it's unmodified code, and show a "modified" icon next to it.

 

If someone is capable of hosting a modified server, then you can be sure that he is also capable of modifying what hash it sends

 

Just an idea at this stage.

 

Just found a really old original design doc for Scraps that has you collecting "scrap metal" from destroyed enemy parts rather than parts themselves.

That actually makes a lot more sense. Then I don't have to handle repairing parts, how damaged they should be when they drop, IF they drop, showing collected parts on the build screen etc etc. Picking up scrap metal from destroyed parts can just go straight to your cash to spend on other things.

The only potential negative is that you will be able to build what you want, rather than having to strap on unsuited parts that you got from some completely different vehicle. So maybe we should have both, at least eventually.

Anyway, not much to report right now. Working on multiplayer but it'll be a while before I can say or show anything interesting.

 

Hey, I made like, an official Scraps forum: http://forum.scrapsgame.com

 

Just played around with your current build, im still amazed , so i want to fortify your enthusiasm about your project:

i tried to compose some viable builds with PvP in mind, my idea was to create a allrounder with these aspects:

- small outline
- good firepower (turret 2-5 smaller guns)
- speed
- low center of mass to allow sharp turns without tumbling over

the fastest speed i was to able achieve is around 500km/h without any guns.
Because motor-efficiency decreases with the number of motors there is this sweet spot of speed where you can have the turret (+enough energy to operate it) which is somewhat at 230-280km/h depending on if you want some armor plates for the looks.

Top:

M-Chassis Sleek Tank with only functional parts, maxspeed without armor is ~280km/h. The turret is placed pointing backwards so it doesn't interfere with the forbidden cockpit entry​

Middle:

M-Chassis low center of mass build (turret with 750kg is on lowest useable position)​

Bottom:

S-Chassis version of above, turret may be hard to use in bumpy terrain because of its low muzzle​

I fear that, if people aim for serious PvP battles, they may end up all using very similar builds and i cannot think of a good way to encourage diversity except the right ratio of HP/Size/speed of builds. If it is as rewarding to play a hard to hit medium battle vehicle with low HP, as a big fortress with big outline and lots of HP and firepower, diversity would be possible. Or maybe some Game-modes where players fulfill distinct roles and have to be in a certain mass-window if they want to fill it... A mode like "Escort the fortress" or such.

I hope you will succeed in balancing these Build restrictions/rewards appealing.

 

Okay, great post! Most people have been building for aesthetics but that'll all change once it's competitive. Yes, balance is very important and will probably take some time to get right, with the community's help. At least I can keep updating the game, to try and prevent one "best" solution.

I'm hoping that fast vehicles (i.e. spending on engines at the expense of weaponry/armour) will be viable since the projectile weapons take some skill to aim and the non-projectile weapons (machine guns) don't do a lot of damage in one hit. I can potentially reduce the power of projectiles to make aiming more of a challenge. Similarly, heavy armour or heavy weapons vehicles should be viable for obvious reasons. But yes it needs to be carefully balanced and yes good balance is going to be a challenge with all the possible builds.

There are other subsystems to be traded off. For instance capacitors are cheaper than generators and will do the same job for a time (i.e. letting you shoot for longer), but if the fight goes on too long then generators have the edge. Cooling is coming too which will add an extra factor, and what I want to do is have energy weapons that require power + cooling and gunpowder weapons that only require cooling, with the energy weapons being better/different, e.g. lasers.

There need to be more parts, because at the moment there just aren't that many options to diversify things anyway, but more parts also means more balancing required.

Note that all the values for price, damage etc are basically placeholders for now. I tried to vaguely have them make sense, but I wouldn't base a build too heavily on the stats right now.

 

I think something might be wrong.

 

That perfectly describes why I began looking into Unity and why I'm so excited about my first project.

Anyway, Scraps looks like it has the framework to be incredibly fun... I adore the physics-based approach and the way you're balancing the mobility/firepower. I'll have to download the builder demo and give it a shot when I get back home. Keep it up!

 

First of all, I would like to say so far this seems AMAZING. The idea sort of reminds me of Twisted metal - Cars fighting
the building works great!

In the future will we be able to rotated objects while building?

One quick thing i noticed is that when your building and an you're carrying an item, if you put it under the wheel and move it up the wheel moves up (using the suspension.) It doesn't look glitchy or anything, but perhaps is not meant to be there. It's really not a big deal, just thought i'd point it out.

Anyways, Keep up the good work!

 

http://forum.unity3d.com/threads/161708-Scraps/page8?p=1257673&viewfull=1#post1257673

Yeah, I know what you mean. It's because the item you're carrying is already a real item in the world (no point creating an extra "fake" item when you can just hold the real one and use it directly on the vehicle), but the rest of the vehicle is frozen so it doesn't react to it. It's actually a Unity bug I think because the wheel should be frozen too.

 

Did you know that Twisted Metal was based of the game Interstate '76 A game that's been LONG overdue for a remake! But yes, I am very excited!

 

You might be thinking of Vigilante 8? Twisted Metal came out before I76.

 

Hey, I just put up a post on the main site with some simple extension methods I've made for Scraps that might also be generally useful. Since this is the Unity forums, you guys may be interested: http://www.scrapsgame.com/some-unity-extension-methods

 

Cario

 

Mother of God that is awesome

 

Yes that's the one, my bad!

 

I've been working on fixing and tidying up a bunch of things in the core game, and it's time for a big update. I'm avoiding adding new content if I can until the alpha release, so this might not add much in the way of exciting new features, but it does make things a bit more robust in general. I'll be going back to working on multiplayer now which is also needed for the alpha, but the good part about this update is that it can all go into the free version too.

The biggest change is that weapons no longer clip through your own vehicle, and automatically limit their range not just to avoid hitting stuff, but also to avoid their shots hitting your vehicle's stuff. So your weapons will now automatically reduce their range if necessary to get a clear firing area. However, weapons do need to at least be able to fire straight ahead, or they'll set themselves to not be able to fire at all.

You can also visualise the range weapons will have on the build screen:


Here the cannon is showing reduced range to avoid colliding with the cockpit, and avoid bullets hitting the front wheel.


Here the two large cannons show their reduced range. You can now do these sorts of "enclosed bunker" designs without everything just clipping through your vehicle.

So go and get the updated builder demo!​

There are a lot of other changes since the last public release:

2013-08 - 0.2.0
Changes:
- General code cleanup
- Moved GUI power bar to the bottom
- Moving parts on vehicles can now collide with the vehicle
- Hovering over weapons on the build screen now displays their available firing area
- Weapons now automatically reduce their range to not collide with or hit your own vehicle when firing (if possible)
- Parts are now tinted when hovered over to indicate which will be picked up
- Improved part snapping on the build screen.
1. Parts can now snap to points which are visually behind other objects.
2. Parts can now snap to positions where a snap point is available but the part will collide with something - the part can't be placed but it helps to see why not. This is optional and currently off by default - it's in the Game Options. Feedback on which system works better is welcome.
- Added audio volume controls to Options screen
- Added 2x1 extender part (such an exciting new part)
- Armour now auto-snaps to the angle required instead of having to be manually rotated. Note that saved vehicles will now be missing their "side" armour due to that part being removed
- Turned save file encryption back on due to concerns about potential cheating in the future
- Moving parts (e.g. rotating weapon barrels) are now allowed to intersect red zones at the build stage(e.g. above the cockpit hatch)
- Other minor improvements and performance tweaks
Bug Fixes:
- Stopped parts being able to intersect wheels on the Build screen
- Fixed collider sizes on medium engine and armour, which were incorrectly preventing them being placed in some situations
- Fixed some weapon rotation issues with clipping or rotating about the wrong point
- Fixed parts not being marked as inventory and hence doing unnecessary setup
- Fixed red zone box Z positioning on the Build Screen
- Fixed suspension always becoming linked when entering test mode and returning
- Fixed rear suspension value not loading from saves
- Can now edit the vehicle name in the save dialog after clicking on an entry
- Fixed the default vehicle files not being copied across after clearing all data
- Fixed Ctrl-key commands not working in Mac OS
- Fixed a new music track not starting when the old one finishes
- Other minor fixes

2013-06 - 0.1.3 (internal version only)
Changes:
- Improved skidmarks
- Tweaks to vehicle masses
- Added antialiasing back to the inventory parts when suitable graphics settings are selected
- Flying bullets have some texture
- New trails for medium cannon (see bug fixes)
Bug Fixes:
- Stopped using Unity's trail render and wrote a custom one, fixing issues when Medium Cannon bullets reset their position
- Fixed steering so it doesn't instantly snap to 0 on key/button release

 

Sooooo excited!!! You make me very moist good sir!

 

A slight update, mainly with fixes for a few things in the 0.2.0 release:

0.2.1
Changes:
- Made the in-game "gun can't fire" sound louder
- Made it clearer when guns can't fire on the build screen
- When deleting all user data, deleting user vehicles is now optional

Bug Fixes:
- Fixed an issue with the automatic weapon range calculation
- Fixed armour snapping to the wrong angle in certain situations

 

I've been following your project for a couple of months now and it is looking more and more amazing as time goes on.

I got an old RPGer friend interested in your project. He mentioned there were no video games like Steve Jackson's Car Wars with both customization and combat, so I sent him to your site and now he's hooked!

 

Yeah, you'd think they would've made an official Car Wars game at some point, but no.

 

Fixed some issues with the barrier walls around the edge of the map. They also look a bit nicer now:



Also been doing some work on multiplayer. My multiplayer stuff is currently in a separate, simplified test app. It uses some of the assets and code from Scraps, but bolted on to the simple car from the car tutorial (although it uses Scraps physics):



I've got some freelance work to do now that's going to take about a week; then I'll be back onto it.

 

Excellent man! Keen to see what comes next! Hope to enjoy the multiplayer section ASAP Do you have any ideas for adding two wheeled chassis to the game by any chance? Or the ability to attach wheels? To make say, a tank-like thing?

 

Now that would be awesome.

 

Originally the answer would have been this: You may be able to attach rolling non-powered extra wheels in future e.g. as stabilisers, but tank tracks will be covered by having a proper tracked chassis option.

But I'm sort of thinking about changing propulsion a bit now, and you may yet see the ability to snap on extra wheels and/or different propulsion types (no promises). Mainly because I started thinking about how to handle the situation where e.g. you build something on a wheeled chassis but what the same vehicle on a tracked chassis instead.

To handle that case I'd have to provide a way to change propulsion on the fly anyway. If it means switching out the whole chassis then you'll get problems with stuff colliding, e.g. when the tank tracks take up more space than the wheels did. And working all that out might be more complicated than just letting you place propulsion systems as parts like everything else.

The issue with it is that it would still require a bunch of code changes because the propulsion code is quite integrated into each chassis option.

 

For some reason I only just thought of the fact that of course you can reference all components on an object via any other referenced component or script, not just from the GameObject or Transform. That is, if you have one reference to anything on a GameObject, you can access everything else through it. This is kinda hacky/brilliant. e.g.

Code (csharp):

1. myScriptReference.rigidbody.mass = 5;

Of course you could continue this as long as you like, creating a Russian roulette where you wait for the first null.

Code (csharp):

1. myScriptReference.rigidbody.GetComponent<Transform>().parent.GetComponent<WheelCollider>().attachedRigidbody.GetComponentsInChildren<MonoBehaviour>();

 

I'm a little confused, but then again I am only a beginner when it comes to this stuff. How would one attempt to changes the values anyway?

 

Haha, don't worry too much because that isn't a great way of doing things. But that is changing the values already, at least in the first example.

 

This game has a lot of potential. I haven't been following the development for long but I love the look of it. Do you plan on releasing this for free or costing? If so how much will it cost?

Other than that, I really like it. You seem to have a lot of people interested in it, and I think the development should carry on

 

Thanks. Making Scraps is my full-time job now and a huge amount of work has gone into it already, so it has to cost money. But a version of the vehicle creator will always be available for free.

Not sure on the price yet but the initial price will be lower than the final release price. So you can buy in early to get the current alpha, and the final when it's done, for less.

 

Basic multiplayer in my test app seems to be working well. It's nearing the time to integrate everything into the main app. Still a long way to go.

The whole networking system in Scraps is a bit unusual because Unity's physics (which I'm using extensively) can only run in real time, but I also want to retain cheat protection by having an authoritative server. I've never heard of anyone doing things quite the way I'm doing it, and I've been waiting for the moment when I realise why no-one's done it, but it seems to be surprisingly decent so far. One day in the future, I'll do a writeup on the hidden magic.

The thing is that really good networking has an authoritative server (so you can't cheat) and client-side prediction (so you don't get a delay on your commands). And lag compensation, but that's out of scope here.

So the server controls everything that happens in the game. When you press a key to move forward, your computer tells the server that you pressed the forward button, and the server moves you forward. Then it sends back the information about where you moved. The server has the authority on everything you do, so even if you hack your game to move at double speed, the server will just snap you back when it tells you where you really are. I can do that with Unity physics, no problem. But you need to do more than that, because there's always some latency.

If it takes 200ms to get to the server and another 200ms back, it's going to be almost half a second after you press forward that you actually move! There are old games that work that way, but mostly these days we try to predict. When you press forward, your computer moves you forward, then when the server sends back the authoritative information about where you moved to, you can adjust if necessary. If the movement code's exactly the same, you shouldn't have to adjust. Bam, authoritative server, and instant response. I can still do that with Unity physics.*But there's one more thing to it.

Let's say you're moving along and the server sends you a message saying "you are here". That message isn't for where you are now, it's for where you were 400ms ago (or whatever the latency round-trip is)! In the time between then and now, you could have done anything. You might have pressed jump. You don't want the server to slam you back onto the ground because it hasn't realised that you pressed jump yet.

So ideally we record all the commands that the user made since the last update from the server. Then when the server sends a new update, we can start from that moment, and <em>replay</em> the rest of the recorded user commands to get back to where we are now, but with any corrections from the server. Again, this is all to prevent cheating - otherwise we could just assume the client was right and tell the server where they are.

We actually need to constantly replay all the commands we've recorded since the last server message, every frame, until we get the next one. Now, uh oh,*Unity's physics aren't fully deterministic, and you can't step forward or rewind the physics anyway. Everything just runs in real time, all the time. Don't we have to rewind time and then step forward again to do all this?

Oh yeah. And that's the problem. You can kind of approximate Unity's physics, and there's a really good blog post on it here by Joe Best, but in the end he seems to come to the same conclusion as me, which is that it'd be a huge mess to try and do for vehicles (or for anything else really). A large part of that is Unity's lack of ways to check if something will collide without, again, actually letting time pass. See the first entry in my earlier post here.

So I wrote down what I thought Scraps multiplayer must have:
- No client control lag
- Supports latency up to at least ~500ms
- Cheating prevention
- All physics can run in real time

I'm wasn't keen for a huge job like trying to replace the entire physics system with Bullet physics or something like that. But I managed to work out a networking system different to anything I've seen before. I call it Vibrance. So far it has a few small drawbacks and isn't as "clean" as the above - it's a little bit messy - but seems to work well overall. Sorry but I'm not ready to reveal the details of the implementation. That might be a mistake as someone would probably tell me immediately why it's a terrible idea, but so far, so good.

Thanks for believing in the game so far.

Valve has some great documentation on how this stuff works in the Source engine if you'd like to know about FPS-style networking.

 

Man that sounds so great. Definitely have some comfort in knowing you've got things somewhat handled, we're all still believing in you over here

 

DIGITAL NATIONZ is on at the Vector Arena in Auckland over the weekend of the 28th and 29th this month. Unfortunately here in NZ we have a habit of presenting everything in a way that says "here's the product, and also, it's NEW ZEALAND!" and the name reflects that complete with entrenched all caps.

It's also often used as a way of justifying something being laudable despite actually being sub-par when compared to the rest of the world. It's like your friend makes something average and everyone feels obliged to say it's pretty good. Happily, in this case DIGITAL NATIONZ actually looks to have a pretty sweet lineup and a lot of effort put into it. They've got something like 12 Oculus Rifts where at PAX Australia they had maybe two. They've got hands-on play with both the XBox One and PS4, where PAX kept its XBox in a glass case for us to gaze at with museum-like reverence (and no PS4).

Anyway there's a section for indies and small-time players like myself called Homegrown, where we get a little booth for a half-day slot from which we can accost strangers and yell at them to play Super New Zealand Adventure 5 or whatever. This is the first year of the event and they seem to be in a bit of a mad rush to get everything sorted, so I haven't got final confirmation of the times I'll be able to exhibit yet. I have got confirmation however that I'll be able to exhibit.

Reasons you should come to Digital Nationz:
- There'll be lots of stuff there that's way cooler than the current version of Scraps
- I'll be there
- There'll be a playable build of Scraps that's a little updated from the one currently available

 

Oh man! If I had the money for a plane to NZ and some time off of Uni I would absolutely come! I've been meaning to visit NZ again. Good luck at the conference. Take lots of pretty pictures and videos of all the nice stuff there

 

So, in Interstate '76 there are repair buildings in multiplayer that look like this:


In case your childhood memories just got destroyed, that's a software rendering screenshot - the game can look a little better than that.

I need buildings too, that you can get back to to repair and modify your vehicle during a game. But I can't have a building like that, because I don't know how big your vehicle is going to be. Any size I make a building, someone's going to have a bigger vehicle.

So I'm thinking something more like a "repair pad" than a "repair building", but that doesn't exactly explain why you'll be invulnerable while sitting still on the ground out in the open.

So now I'm thinking maybe when you get to a repair pad a dropship beams you up, and that can also explain how you drop in when you spawn. But then I have to make a dropship.

 

Sweet dude, I also got confirmed for a slot. You work looks a lot more ambitious than mine and wayy further along. Id be keen to have a look!

 

I don't even have actual gameplay apart from driving around the test map on your own so Scraps is no finished product either. I imagine there'll be lots of unfinished stuff there. Post a link to what you're working on if you like.