I’d like to officially announce that BuildR 2.x is in production!
I’m currently building a new version from the ground up. Over the years I’ve received some amazing feedback from you guys and while I’ve striven and successfully added a lot of your requests, there is a lot that can be added that was either just a lot of work or just impossible with the current BuildR code architecture.
BuildR started out as a way to generate simple buildings to fill your levels. I didn’t want to just create square buildings like some programs, I wanted complex shapes supported. Over the years – and it’s been over three already! – interiors, stairwells, custom windows, Substance textures, runtime generation, and many more things were added. But I’ve now reached the point where we need to start again, picking the best bits of BuildR 1.x and creating something that can support some of the things you’ve requested over the years.
Here is a list that I’m committed to doing. They may not all appear in 2.x but I currently have no reason to believe these won’t make the final build.
Interior generation including walls, doors
Deep support for custom geometry
Strong support for procedural runtime generation
I’ve been on the store for over 5 years now and a Unity developer for much longer so there are many things I would like to implement for this. There will also be significantly tighter integration with the Unity editor, expect a lot more drag and dropping and simple ways to create buildings.
Price wise it’s probably going to be a $100 asset with an upgrade path from 1.x for about $10 though I’m still weighing all these options right now and this could change. ETA is maybe an early beta by the end of August for people who want to try it out and test it for me. Hit me up on my email with your BuildR invoice number if you’re interested.
As of today we’ve moved to Edinburgh. We’ve said goodbye to London, our friends and family and we’re going to start a new life here in Scotland.
More, if not all of my work will be remote now which will be equally new and old to me after two years in Hong Kong where I didn’t contract but worked on mostly Asset Store products and looked after our daughter.
It’s a very exciting time and we’re looking forward to living in a house after years of living in flats!
The Update function in MonoBehaviour is where you’ll end up running a lot of you game code. However, it’s always worth asking yourself does the code need to be running every frame? Some parts you can get away with running a few times a second or event every few seconds. Every time you’re building something into Update, understand if this is where it must be.
Level of detail code is a very obvious one that you might only want to update every second or so. I’ll usually run InvokeRepeating for that.
If you’re switching between projects or planning to create a new one when starting Unity, it can take a while for it to warm up and allow you to do this. One way to open another project is to find a scene in that project and open Unity from that. Of course that’s not as quick as clicking on the Unity icon on your desktop (you do have a shortcut on your desktop right???) as you have to find a scene buried within the needed project.
If you press and hold Alt when you open Unity it will open the projects dialog instead of the last opened project. here you can select a different project or create a new one!
The first thing you need to do on a new project with modelers is to agree on a scale. This is especially important if there are multiple modelers on the project, you don’t want them all producing content at different scales! The best way to determine scale is to ask each modeler to produce a one unit cube as they see it. Bring the cube into Unity and compare it to the primitive Unity uses (Menu > GameObject > Create Other > Cube). The Unity cube is one unit squared and one unit is one meter.
Why is it important that we stick to Unity unit = 1 meter? For starters, it just makes sense right? When you code anything in your game, it’s easy to move something 1m/s.
Also, if there is any physics in your game, you’re going to need to stick to this concept. The physics simulation is based on 1 unit = 1 meter and any other scale is going to give you a physically weird world. Things will fall too quick or slow.
There’s going to be a point when you crash Unity or your built game. It might just be an instability issue, it might be a loop in your code that can go awry. Sometimes you have no idea and that’s when you need to dig through the log files. All the information you need is on this page to find them.
The quickest way to the editor log is to use the button located top right in the Unity console window. You can also find things like build size breakdowns after you have built your project. It makes tracking down inappropriately massive assets in your build easy.
Log files also contain all your Debug.Log outputs which can be very useful if you’ve compiled and built your game and it’s now crashing on another machine.
It’s the last one of these happy little fellows and it can come in quite useful. I must admit I don’t think I ever used it for the first year using Unity but it came in handy when I needed to pinpoint a frame and what was actually happening in it. All it does is advance your game, frame by frame, in pause mode. So keep an eye out for when it will come in handy…
It’s very easy for a scene to become very cluttered, especially in the hierarchy where you can end up with thousands of GameObjects. The simple way to control this though is to create empty GameObjects that just hold the children. It can keep a large bulky project clean and hide a lot of assets and GameObjects.
Remember to make sure they have their origin set to world zero so things make sense though. Do this before nesting objects so their position isn’t affected by moving the parent to world zero. Unity will place newly created GameObjects where to scene editor camera is so they end up being in arbitrary places. After nesting three or four times, the local position of the children could be anything. It might not matter at first, but it could trip you up later on.
I have recently released the latest version of Track BuildR which has been christened the “Stunt Update“. This version comes with support to create circuits with loops, jumps and twists after rebuilding the track cant implementation.
It also includes Substance texture support, FBX, OBJ and XML export, track extrusion and some minor bug fixes. I’m very proud of the fact that Track BuildR since release has had only one bug!
The update did come at a slight cost – 1.0 tracks are not supported… With the new undo system that Unity 4.3 implemented along with the hell that is using ScriptableObjects, I needed to change the base implementation of Track BuildR to Monobehaviour. The problem is it breaks backward compatibility… I do have a plan for users needing the upgrade. It involves exporting the 1.0 track to XML (with some re) and importing it into a fresh 1.1 track. This method was used to bring the Spa Francorchamps track to 1.1 and it’s pretty easy.
I hope it’s well received! You can check out videos, demos and further information.
You have a complex scene with many nested GameObjects and then you accidentally click on that small pebble in your scene making your hierarchy explode to reveal that pebble. Fear not! You can alt click the top level parent arrow to collapse every collapsible child GameObject and return your hierarchy to normality.
It also works the other way around, allowing you to expand every nested GameObject instead of only the current selected one.