Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 02:16:42 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Continuous Integration and Games
Pages: [1]
Print
Author Topic: Continuous Integration and Games  (Read 1843 times)
Layl
Level 3
***

professional jerkface


View Profile WWW
« on: February 17, 2015, 01:51:08 AM »

Outside of games, continuous integration, automatic builds and test running are generally considered good practice. In games however sometimes people don't set up continuous integration for a variety of reasons. I would love to hear everyone's reasons for and against continues integration for your game projects, tips for how to set up continuous integration, and tips on how to make it give a net positive effect on your project.



To get the thread started, here's my own tip for CI. If you're working with .NET (Unity*, MonoGame, Duality, <shameless_plug>Subterran</shameless_plug>) and using GitHub, it's extremely easy to get your CI set up. I personally use AppVeyor for CI, which automatically picks up an builds your .sln file. With MonoGame make sure you're using the MonoGame NuGet package rather than using the installed libraries.

It also picks up a variety of unit testing frameworks automatically. I use xUnit for my unit testing code.

*Unity is a bit more tricky, as you'll need UnityEngine.dll to build your code. I assume you're allowed to redistribute that since it gets copied along in a game publish, but I'm not 100% sure on that.
Logged
Cheezmeister
Level 3
***



View Profile
« Reply #1 on: February 17, 2015, 10:18:46 PM »

I tried setting up appveyor to get some auto Windows builds for my CMake-based project...

Logged

෴Me෴ @chzmstr | www.luchenlabs.com ቒMadeቓ RA | Nextris | Chromathud   ᙍMakingᙌCheezus II (Devlog)
Sik
Level 10
*****


View Profile WWW
« Reply #2 on: February 17, 2015, 10:26:26 PM »

Don't forget regression tests, which are basically considered mandatory in any well organized project. With games this can be hard though since some things can be subjective and not easy to detect with software (e.g. suddenly something becomes louder than it should since it was originally programmed for a different sound effect before, and a lot more things than usual require an exact sequence of timed user input to show up).
Logged
Layl
Level 3
***

professional jerkface


View Profile WWW
« Reply #3 on: February 17, 2015, 10:56:34 PM »

I tried setting up appveyor to get some auto Windows builds for my CMake-based project...

To me it feels very much like AppVeyor is a .NET CI service more than anything else. It's very easy to set up if you've got a .sln file. Getting it to work with CMake sounds like living hell in a bottle.
Logged
agersant
Level 4
****



View Profile
« Reply #4 on: February 17, 2015, 11:10:14 PM »

Recent discussion about this on r/gamedev.
Logged
Liza
Level 1
*



View Profile WWW
« Reply #5 on: February 18, 2015, 03:02:16 PM »

I deal with builds and autotesting for a living. At home with my hobby project builds and CI is the last thing I feel like thinking about, so I'm just deploying on GitHub push using dploy.io free tier.
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #6 on: February 18, 2015, 03:12:56 PM »

^^ I do that for a living too. I also don't work on projects large enough at home to justify doing it for my personal stuff. Maybe in the future.

I've been meaning to catch up on some of the more modern build systems and see if any progress has been made. I haven't seen too many improvements in newer frameworks to justify moving over. FAKE looks interesting.

 
Logged

bdsowers
Level 3
***



View Profile WWW
« Reply #7 on: February 28, 2015, 07:13:51 PM »

I've used CI in two different game companies I've worked at. For projects spanning multiple consoles.

It's not free. We often had an engineer dedicated to just setting it up and troubleshooting problems that arose in the CI system itself. If you've already got a sizeable codebase or a complicated build system, trying to add on a CI system isn't always easy.

It also has weird workplace implications. Once the build breaks, you've got a ton of people all looking and wondering if they broke the build. Then you've got people debating who's responsible for fixing the build.

Basically, there's a lot of growing pains involved. I can't speak to how much time it saved us. It *felt* useful, but we got by fine without it, soooo...

At one company, we had an intricate regression test system. Which often had problems of its own that needed rooting out. But it was with a game engine, and we needed to make sure the engine was stable between releases, so it was pretty invaluable. For a game that goes gold and then gets forgotten, I wouldn't bother with it.
Logged

Layl
Level 3
***

professional jerkface


View Profile WWW
« Reply #8 on: February 28, 2015, 08:07:58 PM »

Basically, there's a lot of growing pains involved. I can't speak to how much time it saved us. It *felt* useful, but we got by fine without it, soooo...

That's interesting to look at, where CI makes a difference. Since my projects are always open source and hosted on GitHub, CI is an amazing tool to make sure all pull requests do not break anything by automatically trying to build it and running tests on it.

Is anyone here unit testing their actual gameplay mechanics? For example, "Player should not be able to jump over a 3 high wall". If yes, what way are you testing it?
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #9 on: March 01, 2015, 02:27:54 AM »

That where I feel unit testing breaks down for games. That should be moved to the smoke test phase which unfortunately requires a lot of  work to do correctly. You need to start thinking about maintaining state snapshots and filtering out transient data.

Existing CI systems are sometimes rigid enough that doing your own solution is actually less work then integrating something like Jenkins etc...
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic