Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

How do you test new features?

Discussion in 'Scripting' started by Deleted User, May 4, 2016.

  1. Deleted User

    Deleted User

    Guest

    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.
     
  2. karl_jones

    karl_jones

    Unity Technologies

    Joined:
    May 5, 2015
    Posts:
    8,230
    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 http://docs.unity3d.com/Manual/testing-editortestsrunner.html

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

    skalev

    Joined:
    Feb 16, 2012
    Posts:
    264
    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.
     
    Dave-Carlile, Kiwasi and ericbegue like this.
  4. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    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.
     
    theANMATOR2b likes this.
  5. Duri

    Duri

    Joined:
    Dec 5, 2014
    Posts:
    29
    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.
     
  6. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    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!
     
    Last edited: May 4, 2016
    theANMATOR2b and Kiwasi like this.
  7. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    Screenshot of version control. I think it's immediately obvious how nicerequired it is to have!

    upload_2016-5-4_14-46-53.png

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

    upload_2016-5-4_14-47-58.png
     
    Last edited: May 4, 2016
  8. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    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.
    https://en.wikipedia.org/wiki/Dependency_injection
     
    Dave-Carlile and Kiwasi like this.
  9. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    I guess I'm going to keep posting to this thread....
    upload_2016-5-4_15-39-37.png
     
    karl_jones likes this.
  10. Deleted User

    Deleted User

    Guest

    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.
     
  11. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    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.
     
  12. Stardog

    Stardog

    Joined:
    Jun 28, 2010
    Posts:
    1,910
    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.
     
  13. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    (once you have git setup and sensible .gitignore settings)
    Code (csharp):
    1. git add *
    2. 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?
     
    theANMATOR2b, Deleted User and Kiwasi like this.
  14. passerbycmc

    passerbycmc

    Joined:
    Feb 12, 2015
    Posts:
    1,741
    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.
     
    Last edited: May 5, 2016
    Kiwasi likes this.
  15. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    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.
     
    theANMATOR2b, _met44 and Kiwasi like this.
  16. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    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.
     
    JoeStrout likes this.
  17. skalev

    skalev

    Joined:
    Feb 16, 2012
    Posts:
    264
    I would agree. That's why I use P4, which is also available free on assembla.
     
  18. Deleted User

    Deleted User

    Guest

    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 @BoredMormon. 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 >_<
     
    GarthSmith likes this.
  19. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Sorry my bad. Tone often doesn't translate well on the internet. Let us know if you need any more specific help.
     
    GarthSmith likes this.
  20. Deleted User

    Deleted User

    Guest

    @BoredMormon 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.
     
    GarthSmith likes this.
  21. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    You are always welcome around here.
     
    JoeStrout and Deleted User like this.
  22. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Unity just announced their new attempt at their own VCS. The feature list is straight up an insult to the Unity user base, but it might be a decent choice for a first tool for a single user. Barely. It's called Collaborate.

    I disliked git a lot when I started out using it. But I also disliked SVN. Merging is hard. In the end, git won out because the distributed model is so incredibly powerful. If a team member has a patch that I need, I can grab the patch directly from them - there's no need for me to be in sync with the server, there's no need for them to be in sync with the server. If a team member has a bug blocking them from working, I can make a horrible hotfix on a branch, have them merge the branch, and not have that bit of code touch anyone else.

    Going back to a world where I have to pull from and merge with the sentral repo before I can give code to team mates is just not an option.

    All that being said, git isn't perfect in any way.
    How do you revert a file to the last version you have pulled? git checkout!
    How do you get a file from an old commit? git checkout!
    How do you switch to a branch? git checkout!
    How do you create a branch? git checkout!

    Of course, if you're alone on a project, the complexity overhead of a distributed model is meaningless.
     
    Kiwasi likes this.
  23. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Really? There are some services that are not well catered for by the market, Unity Ads and Cloud Build and the like are good ideas. But there are already good VCS that everyone is already using. They would have been better off improving scene merging with existing systems.
     
    JoeStrout likes this.
  24. Deleted User

    Deleted User

    Guest

    I would like to revive this thread, because I'm curious to know just how you would separate systems within your project.

    I'm sorta worried atm because though I've put a lot of time in to this project, I've not planned hardly any of it (except for a few features I have floating around in my mind). I am worried because I just learned of something called "Program requirements decomposition" in a summer class. Its basically breaking your problem down in to subproblems, so that eventually you get a number of functions which can be reused in parts of the project. I haven't done any of that (let alone plan). It also makes things ever more difficult to change as time passes and maintenance and requirements change. That's what worries me the most!


    Back to my first question: how would you separate those systems? Would I change code that accesses other parts of the code to work if the other script(s) don't exist or are disabled? I am having a hard time imagining just how that might work. What might default behavior be if a script or three are disabled/non-existent in the project?
     
  25. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    There are lots of ways to break those dependencies. One of my favorites is to use UnityEvents. So, if a script invokes an event and there is no receiver, it has no effect. And if a script is invoked by an event that nothing ever calls, then that script simply doesn't get invoked.
     
    TonyLi, karl_jones and Dave-Carlile like this.
  26. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    A lot of free VCS services create public repositories that anyone in the world can download. Please don't become an inadvertent pirate by uploading commercial assets (such as Asset Store purchases) to public repos.

    Unity provides a lot of good technical features for breaking dependencies, such as UnityEvents as Joe just mentioned. But having a fancy hammer doesn't make me a carpenter just yet. I wager it'll be well worth your time to do a little reading on decoupling in general. Google "decoupling code" or borrow a book such as Code Complete from the library. It'll serve you well in all your development endeavors.

    Two thoughts regarding testing:

    1. If you can modularize your subsystems and break dependencies with other subsystems, you can design focused tests that thoroughly exercise each subsystem to give you confidence that it works right. Integration testing (e.g., testing the game as a whole) is important, but it builds on top of a strong foundation of individual unit testing. It may seem like a lot of effort to initially set up a test, but during the course of a project it saves tenfold in time, effort, and frustration.

    2. Manual tests are rarely run. And if tests aren't run, they're useless. Automate tests as much as possible. Unity has a decent testing framework. And I always like to plug uTomate to automate anything in Unity, including tests. I have no affiliation with uTomate except as a customer, but I don't know how I'd get through the QA process without it.
     
    JoeStrout and Kiwasi like this.