How do you test new features?

[anon20000101]

I’m working towards implementing AI in my game.

I’ve been doing some very bass ackwards and rough things to test the very simple AI I’ve created. I do this because creating a whole new project is a pain in the butt, and all of the scripts that I’ve created are so interdependent, I don’t know how to test them. If one script doesn’t have another script to reference, or a value is null then things don’t work. I also have about 6 different versions of my game on the hard disk, some are copied from the dropbox (which is full now), others are just left over from months ago. Its a pain in the butt to figure out what the latest one is, and I don’t even know which one is my most current one unless I open it.

I suppose I should have made cases for that now.

How do you usually test different systems?

And should I implement some code to handle a script being nonexistent? My intuition screams at me “YES YOU SHOULD YOU DUMMY” but the other part of my groans about it.

In my defense I’ve never had to manage a code base this large, and I’ve never had to deal with implementing a subsystem which has to get incorporated in to the larger project at some point.

[karl_jones]

First start using source control to manage your project instead of lots of zipped files. Look at bitbucket or something similar.

For testing look at editor tests Unity - Manual: Unit Testing

Ideally you want to be able to test small isolated parts so that when a test fails its easier to isolate why.

[skalev]

As far as managing a code base, the best solution is to use a repository, like GIT or P4. This allows your team to keep the project up to date while not losing previous versions. Having multiple versions that you can’t keep track of is a big problem.

As far as testing, you don’t really want to test things out of context, so making a new project isn’t a good idea. When I need to test my AI, I have some sort of a sandbox I use, which is a scene containing the minimum objects I need. I have a few in different stages, so I can test new parts independently. After I see that it works in a sandbox, I’ll start testing it in the real game. Adding all sorts of debug hooks to allow me to change the state of the world/ai/scene so I can speed up the testing process is another technique handy to have.

[Kiwasi]

I’ll add my vote to using version control. Version control systems have a concept called branching. You can make a branch. Hack it to pieces however you like. And all the while the main branch is still there ready for build and release.

I also like the idea of training grounds for AI. I often have scenes that are not included in the build that only exist to test things. That way you can test different setups in a completely isolated context.

[Duri]

Yeah, I vote up the idea of using a VCS; Git should be excellent for you, as it can be used inside Monodevelop.

About testing, if it is purely console behaviour, search for NUnit, should do the work (don’t know much about it specifically but should work). If it involves doing something with the scene, create a test scene then.

[GarthSmith]

It’s been said but I’ll say it again because it’s one of the most important tools a programmer has.

GIT omg GIIIIITTTT (or subversion, or anything!) I can’t work without version control. Too many times I’ve worked on something, broke stuff, then had no idea how to rewind. End result is a trashed project or rolling back to a backup.

Version control is better than a backup, because it literally shows every change/commit you made to version control. Yeah, committing might be annoying at first, but after every piece of work (It could even be a single line, I don’t care) I commit to “lock in” my work. Then I can literally delete folder and I don’t even care.

Version control also lets you do things like have your main game, but then make a “branch” where you can add and test new features without touching the original code. Whenever you finish the feature you can just merge it in, or if the feature is no good just throw the branch away.

About the other things:
Null checks: Testing for null is a pain, but it’s generally a good thing to check for because you will get null references. A check will show you where the problem is right away and might even be able to recover properly. Do it enough, and it starts to become more and more of a habit to just write more null checks on things. This reduces bug fixing time, and a lot of game dev is fixing bugs.

Tests: Some things I make a separate scene for and test in there. UIs for example, or I may have a scene with a player and a single enemy to test different attacks out.

Individual systems you might be able to write a Unit test for, but in game dev the interaction between systems is much harder to test. Eg: I can do hit detection, or loot drops, or calculate stats separately, but a test on how hitting an enemy drops loot that affects stats properly? Much harder. This, combined with the fact that game design is constantly changing during development, means that games are generally tested by humans instead of automated systems. I do have Unit Test for small parts of the game though.

Compare to a finance spreadsheet. Numbers in, numbers out. Easy to check. Acting like a human in an game that has exploration? Much harder to write an automated test for. If you are testing by yourself, my suggestion would to not ignore any bugs that you might see pop up. You may not see it again, and eventually you will automatically change your play style to avoid bugs. You will need to get it in front of someone else eventually. Some bugs may be more likely to appear with a certain play style, and if you don’t play like that then you might not ever know a bug exists!

P.S. Get some version control!!! This might be more important than a IDE to me!

[GarthSmith]

Screenshot of version control. I think it’s immediately obvious how nicerequired it is to have!

You can click on a specific commit to see what changes were made.

[GarthSmith]

Another comment about the “interdependancy” of your code. Encapsulation was a thing I thought I understood in school, but now I realize it’s a career-long journey to get better and better at encapsulation. I mentioned testing a UI in a separate scene. That is possible because someone built Encapsulation into the MVP/MVC design pattern we use.
https://en.wikipedia.org/wiki/Model–view–presenter

It wasn’t until I was on production code that I realized how important encapsulation is. Now that I can read and write C# proficiently, a lot of my time is spent figuring out how to organize systems and try to keep them separate from each other.

You might want to look into discussions about “Dependency Injection”. I don’t recommend just finding a DI framework and using it, because the discussions about dependency injection are pretty invaluable to figuring out how to encapsulate stuff better.

Dependency injection

[GarthSmith]

I guess I’m going to keep posting to this thread…

[anon20000101]

Yes I know what a VCS is but I don’t have much experience with it. I haven’t used one (not for lack of trying) because I can’t seem to find a free one which works. Its been so long since I tried subversion, I’m not sure what happened but I think the problem with meta files getting broken prevented my from using it. I also frequently forget to commit when using a VCS, and I’ve been under the impression that saving the project commits it, but I’m not sure (why the hell wouldn’t it?).

I don’t have a bunch of zip files. I put my project on my dropbox. In the midst of school, somehow my dropbox became full. I think that’s bullshit because I never opened or used Unity or the project in those months. After and a little before that I copied the entire project on to the hard disk, which is why its all over the place in different forms.

Yes, I’m terrible at organization. I in fact hate being organized, it seems like a tremendous waste of time and energy but I’m beginning to see the benefits at least when at work. I typically did my game dev coding “on the fly” with no prior planning, except to troubleshoot an error. I guess that combination of no planning of the code and no VCS is the worst combination ever, now that I think about it. It could probably account for the amount of time I’ve spent on this project, and numerous goof-ups, and even my burnout with it before this past semester, too.

I did learn this semester how to plan out my code. Things go much more smoothly if you do. I aced a lab when I did that, and it probably allowed me to scrape by on the other lab (as opposed to turning nothing in) when it came due and I didn’t have the problem at hand completely solved.

I don’t know if I have the self-restraint to plan my game dev code though. Also don’t have the patience to mess around with getting SubVersion workingn and learning to use it. I guess I’m at the will of an impulse.

[Kiwasi]

Yes I know what a VCS is but I don’t have much experience with it. I haven’t used one (not for lack of trying) because I can’t seem to find a free one which works.

For a UI based client use GitHub desktop or Source Tree. Both are free and easy to use.

Technically you don’t need a remote server to use version control. But there are advantages to doing so. Bitbucket is free for private repos and is easy to use.

I’m not sure what happened but I think the problem with meta files getting broken prevented my from using it. I also frequently forget to commit when using a VCS, and I’ve been under the impression that saving the project commits it, but I’m not sure (why the hell wouldn’t it?).

Typical advice for Unity version control is to force serialisation to text and to turn on visible meta files. The only real time I’ve had problems with version control and Unity is merging conflicts. But if you are on your own you shouldn’t have many conflicts.

Version control is separate from Unity, so you will need to explicitly commit your work.

Also don’t have the patience to mess around with getting SubVersion workingn and learning to use it.

But you do have the patience to deal with the current mess your project is in?

Please don’t ask for help or advice if you don’t want to do the work to implement it. Give us some respect. You’ve hit a rare moment in the forums where every single poster has offered the same advice. I would strongly encourage you to take it. Learning version control will save you a lot of time, even in the short run.

[Stardog]

If you don’t want to use version control, you can name your project folder ProjectName_001, then duplicate it when a major change will occur and name it ProjectName_002. Delete the assembly/solution files in the root, then generate new ones with Assets > Open C# Project. Back the folder up whenever you want. Ideally you would have an HD backup service like Carbonite anyway.

For testing features you can just imagine you’re an asset store developer and try and make sure your system is open enough to work with other people’s scripts. I’ve made battle systems that can hook into any of my other projects. The only issue there is interacting with overall game state that you won’t know about, but that would be handled from outside.

[GarthSmith]

(once you have git setup and sensible .gitignore settings)

git add *
git commit -m "New Feature"

Done. Now we can roll back to this point at any time we want. We even have a message about what it was!

If the command line isn’t for you, then I suggest SourceTree. You don’t need to even upload anything. You can keep a git repository on your local hard drive if you don’t want to set up an account on BitBucket or something.

Yeah, it takes some organization. But after enough times of dealing with this kind of stuff I just get sick of dealing with it, ya know?

[passerbycmc]

Just get sourcetree and git, it would be rather crazy to work with out a vcs like git or hg and sourcetree makes them easy to use.

Also you have to commit, if it auto committed on save that would be terrible. Idea is you commit anything you could define as a unit of work, like fixed bug x or added feature y. Good commit messages make a huge difference as well.

[JoeStrout]

I’ll just jump in here and risk ostracization by saying that I hate git.

I don’t hate version control. I love version control. I use it every day, both on official work projects and on personal projects. But, whenever I have a choice, I use subversion, because it doesn’t make me want to scream. On some projects, I have to use git, because I’m working on a team where that’s what the lead has chosen… and git works just fine 95% of the time, and then somebody makes one misstep and the whole team wastes two hours mucking about trying to patch things up. (And on several occasions, even our team “git expert” couldn’t sort it out, despite following guides like this and this and this and this, and some work was simply lost.)

In 20 (?) years of working with subversion, such a thing has never happened to me there. With git, it is a regular occurrence.

Moreover, I have never personally spoken with anybody else who likes git, either. At most I get “well, if you’re on an airplane, it’s kind of neat that you can commit without access to the server.” OK, but that’s a pretty darn rare case for most of us. Usually the real reason is just, “well, yeah, we all prefer subversion, but bitbucket is free.” (If you don’t count the cost of the entire team wasting hours wrestling with git.)

And no, using SourceTree does not make git easy. Git is complex and hard to use correctly, GUI or no. Git proponents claim that this complexity is inherent in the nature of the problem, rather than indicative of a poor design… but subversion (or cvs before it) doesn’t suffer the same complexity, and it’s addressing the same basic problem.

So, there. I respect that many of you in this thread have added “(or subversion or mg or whatever)” after your advice to use git, but as Braineeee is new to this and looking for advice, I feel obliged to give him my $0.02 worth. Git will make him suffer, guaranteed. I recommend subversion. (And if you’re looking for a project host, I find Assembla to be pretty good.)

But hey, reasonable people may disagree, and I even though I’ve never met anyone in person who actually likes git, I have been assured on a number of occasions that they do exist. So, sure, give it a try sometime, perhaps it will click with you better than it did with me.

[Kiwasi]

@JoeStrout

But hey, reasonable people may disagree, and I even though I’ve never met anyone in person who actually likes git, I have been assured on a number of occasions that they do exist. So, sure, give it a try sometime, perhaps it will click with you better than it did with me.

I may have to try subversion then. I do like git. But I’ll place the caveat that I haven’t yet tried any other version control systems.

[skalev]

@JoeStrout

I’ll just jump in here and risk ostracization by saying that I hate git.

I would agree. That’s why I use P4, which is also available free on assembla.

[anon20000101]

@Kiwasi

For a UI based client use GitHub desktop or Source Tree. Both are free and easy to use.

Technically you don’t need a remote server to use version control. But there are advantages to doing so. Bitbucket is free for private repos and is easy to use.

Typical advice for Unity version control is to force serialisation to text and to turn on visible meta files. The only real time I’ve had problems with version control and Unity is merging conflicts. But if you are on your own you shouldn’t have many conflicts.

Version control is separate from Unity, so you will need to explicitly commit your work.

But you do have the patience to deal with the current mess your project is in?

Please don’t ask for help or advice if you don’t want to do the work to implement it. Give us some respect. You’ve hit a rare moment in the forums where every single poster has offered the same advice. I would strongly encourage you to take it. Learning version control will save you a lot of time, even in the short run.

For the record, I never stated that I wouldn’t use a VCS. I posted this to get help. I am not of the type to just ask for advice and then ignore it. I will however ignore unsolicited advice. I said somewhere in there that I don’t think I have the patience to deal with the mess that it is in. Which is essentially the same thing you’ve stated here. Let me also state that I was explaining my history with Version Control Systems, and part of it was rambling.

I think this is just a misunderstanding @Kiwasi . I’ve already created a repo with VS 2015 for the project and made a commit. I did that even before half of these replies were made.

This is all good advice. Make no mistake. I’m not one to just ignore someone’s answer (let alone reply), who do you take me for?

[edit] Also in case anyone cares, I just got my final grades back. Passed all my classes! Even the one I was failing >_<

[Kiwasi]

For the record, I never stated that I wouldn’t use a VCS. I posted this to get help. I am not of the type to just ask for advice and then ignore it. I will however ignore unsolicited advice. I said somewhere in there that I don’t think I have the patience to deal with the mess that it is in. Which is essentially the same thing you’ve stated here. Let me also state that I was explaining my history with Version Control Systems, and part of it was rambling.

I think this is just a misunderstanding @Kiwasi . I’ve already created a repo with VS 2015 for the project and made a commit. I did that even before half of these replies were made.

This is all good advice. Make no mistake. I’m not one to just ignore someone’s answer (let alone reply), who do you take me for?

Sorry my bad. Tone often doesn’t translate well on the internet. Let us know if you need any more specific help.

[anon20000101]

@Kiwasi I know exactly what you mean, man. I think that’s why I get kicked out of a lot of message boarding communities… I’m not a dick in person but some people just dislike me when I’m online. I think I’ve had some friendships even screwed up because all we did was text. Perhaps I’m too loose with my language. I don’t know but I’ve got a rough history with boards.