Looking to become more efficient using Unity? How to Cheat in Unity 5 takes a no-nonsense approach to help you achieve fast and effective results with Unity 5. Geared towards the intermediate user, HTC in Unity 5 provides content beyond what an introductory book offers, and allows you to work more quickly and powerfully in Unity. Packed full with easy-to-follow methods to get the most from. .NET Reflector: Addon: https://github.com/sailro/Reflexil/releases.
What you will get from this page: Tips on maintaining a stable and flexible build to save yourself time and money. Get pointers on using version control, utilizing your changelists, clean cheat functionality, bug tracking and more
After years of shipping large titles with even larger teams, typical AAA studios know how to keep their productions on track and maintain a clean and stable build. Sascha Gundlach, from MetalPop Games, highlights how independent game developers can adapt the AAA approach to their own production.
With a clean build, it’s easy to change or add things, as well as maintain and debug features. Overall, you’ll be able to develop your game faster and more efficiently.
Maintain a clean and stable game build and you’ll reap the benefits in the long run:
- Release more stable games with fewer bugs.
- Save production time, due to fewer bugs and a cleaner codebase.
- Lower your chance of ‘breaking the build’.
- Create demo versions and special builds easier.
Not all AAA build practices are suitable for indie teams. But there are a lot of things you can do to make sure your build stays clean and stable that are free (or affordable) and can be implemented by teams of any size.
Even if you are a one-person operation, these tips will help you to maintain a better, more healthy build of your game.
Even today, with the availability of free version control systems (VCS), there are still teams out there working with shared folders or dropboxes to collaborate. Developing without version control is a bit like driving without a seat belt. Wearing a seat belt might not always be comfortable and will restrict you a bit, but once you crash full speed into that tree, it will save your life.
You can’t afford to lose work no matter the size of your team. A hacked dropbox account or a broken hard disk should not cause you to lose days or weeks of work.
There are plenty of free solutions out there. Perforce, Git and SVN all offer free versions. And, with Unity Teams built into Unity directly, things become even easier.
Utilize your changelists
In addition to the safety a VCS provides, another benefit is that you will get changelists, which will help you to keep an overview of the changes done. The image above is of a Perforce folder history showing all changes.
Although most systems don’t force you to submit a description for a change you did, it’s good practice to describe the changes clearly.
In addition, creating ‘patch notes’ and similar documents becomes easy when you start using prefixes for your changes, such as these:
- !B: A bug fix.
- !V: A visual change or improvement.
- !G: A gameplay change.
- !X: A change that should be ignored in the patch notes.
When you submit changes to your VCS and describe them with leading prefixes, you can run a script later over every entry and sort everything into a nice and clean patch notes document.
A clean submission to your VCS would look like this:
“!V Made explosion particle effect bigger”
“!B Fixed crash when picking up a weapon”
“!G Increased amount of health in med-kits”
If you keep all your check-ins clean and well described, it’s easy to compile patch notes documents when you need them. It’s a more efficient approach than manually going through your recent changes to identify things that should be listed in your patch-notes.
Practice good hygiene
It’s important that everybody on your team is familiar with the basics of good build hygiene. Here are the top five best practices to keep it clean.
- No build-breaking code
Don’t check in anything that you know is broken. If the feature you are working on is not finished but you need to check it in, either disable it or shelve your changes so they don’t break anything for the rest of the team. The rest of your team should not be blocked by a broken build because you checked in non-working code. - No hard-coded keyboard shortcuts
It’s convenient to add custom shortcuts for certain cheat or debugging functionality. “Just make the the F12 key the money cheat key, no one is going to press that anyway, right?”
But hardcoding functionality like this to a key is dangerous because it’s easy to forget. You might end up shipping it accidentally, or your testers might be unintentionally activating it and polluting your bug reports this way. - Mark bad and missing code
Sometimes you have to hack. No matter how much you would like to avoid it, you will at some point have temporary hacks in your code. When you are adding a hack or workaround make sure to mark them in the code with easy to find keywords. Mark a hack with //HACK or missing code with //TODO. This makes it easy later on to search through all your code for those tags and find and replace them. - Log spam
Logging things in your code is useful and can help you track down problems. However, it’s important to clean up the log spam now and then so that important warnings and errors don’t get buried. Unless you are actively working on a feature, your console should be as clean and empty as possible, so that if something pops up, you see it right away. - File names and naming conventions
The size of your build will eventually grow to hundreds or possibly thousands of files. So it’s important to keep a clean naming convention.
When you start a new project take the time to come up with naming conventions that make sense for you, and force yourself to stick to them. Once you have names such as texturetestFinal01.png or backup22.fbx in your build, things will get messy fast.
Do routine checks and clean up any dirty file names which made it into the project.
Here are a few quick tips:
- Use descriptive names
AttackButtonBehavior.cs instead of atkBtn.cs - Use camelCase or PascalCase
notsocleanfilename.cs isn’t as readable as MyCleanFilename.cs - Use underscores to make things in filenames more clear.
WoodenHouse_Blue, WoodenHouse_Green, etc.
Keep cheat functionality clean
You will constantly need to debug and cheat when developing your game. You might want to jump to a different level, give yourself extra cash, make yourself invulnerable, spawn extra enemies, etc.
You could add those cheats wherever you need them and disable them after you are done but it’s preferable to have a clean way to switch this kind of cheat functionality on and off.
Even for smaller projects, it’s worth investing the extra time to build an easy to use debug/cheat menu. Something that can easily be turned on and off by your developers and provides access to all the usual cheat and debug options.
Doing it this way minimizes the risk of accidentally shipping cheats with your game. In addition, having your ‘cheat code’ in one central place also makes sure everything works and is easy to extend.
Another benefit of this approach is that dev-cheating becomes much faster, saving you time in everyday production. Just pressing a button in your nice and comfortable debug window is a lot quicker than hard-coding values in your scripts.
Manage and track bugs
Your game will have bugs. Every game has bugs and your game will not be an exception. The question is, how do you deal with bugs.
The workflow to efficiently handle bugs is pretty straight forward: your QA department finds and enters bugs in your bug tracking system. Then they assign the issues to your developers, who in turn fix the issues and mark them as such. Finally your QA team verifies the issues and marks them as closed. An easy three-step process, right?
Wait, what? You don’t have a dedicated QA department? Your testers are also your developers?
Don’t worry, because you don’t need much to stay on top of your bugs.
First of all, track your bugs. This is easy even if you are a one-person team.
Pick a bug tracking software (there is a plethora of free and affordable ones out there) and set it up. If this sounds like overkill to you, go ahead and just use Excel or the even the notepad on your desk, it doesn’t really matter. What’s important, is that you have one central spot to collect and track problems. Once you have a system in place to track your issues, it’s all about discipline. A buggy build slows down production speed and can even create more new issues.
Here a few quick tips to stay on top of your bugs:
Bug-Fix-Fridays
Bug-Fix-Fridays are a great way to keep your build bug free. Every Friday, instead of working on new features everybody works on items from the bug list only. This approach ensures you start the new week with a bug-free, stable build.
Don’t put it off for too long
If you know your bugs are getting out of hand it might be a good idea to stop working on new features and focus on stabilizing the build until things are back on track.
Don’t fight fires all the time
If you have a lot of bugs that reappear, investigate the root cause. Is a certain part of your level building pipeline always causing levels to break? Is the way you parse your gameplay values from your .xml files breaking down every other day?
How To Cheat Engine Unity Games
If you identify a system that is constantly causing problems it might be worth the time to rebuild it instead of repeatedly fixing the issues it causes.
C# Unity Cheat Sheet
With all these best practices and tips in mind, it all comes down to discipline and how much attention you pay to the state of your build. You can mix and match these suggestions and apply them to your indie production. The time you use on keeping your build in good shape is always worth it.