Re: time budgets and continuous integration

"Craft, Steven" <[email protected]>
Newsgroups gmane.games.devel.sweng
Message-ID <011AE49D146BF149982F73AD7EC3EFE7F7B07F@wbwknupexmr01.intl.warnerbros.com>
Hi, I do something along these lines. One of our constant integration
jobs (we use TeamCity now, after switching from CC.Net) builds our
games, brings the game data up to date then launches the game. We
implemented a testing framework in the game that will cycle through the
levels, one by one, and after each one loads it dumps out a text file
with information such as average frame rate, memory used by various
systems, time taken to load, etc. TeamCity also allows you to send
statistics to its database, which it will then graph up for you (I like
using this to monitor code size for text/data/etc. so I can see if
someone commits some bloat, accidentally or not - but it can equally be
used to plot average frame rate from build to build). We have a test
harness will launches the game tests; the harness is responsible for
relaunching the game test when it crashes, and picking up the messages
the game sends (messages such as callstacks on crash, crash dumps, error
messages and so on).

We actually have quite an extensive range of tests we run, for example
another job will build all of our engines (PC/PS3/360/Wii - PS2 and PSP
not long ago too), all of our tools (exporting from Maya, platform
specific converters, plugins for Photoshop, and so on), and then runs a
series of tests that involve taking Maya scenes and generating platform
specific data, which we then load up in our engines (per platform), and
then generate a screen, which is then diffed against some reference
images, to ensure everything keeps working. It is amazingly effective,
and I cannot imagine living without it now we have it - as it is
constantly picking up 'knock on' type errors that would have otherwise
slipped in. This particular job generates a HTML report that shows the
results of all the tests, with the image vs reference image vs diff
image, and other information about how to recreate the test and so on.

We also have TeamCity hooked up with our source control (AccuRev) in
such a way that on a lot of streams, the way code flows up the tree
(promoted) is by passing TeamCity jobs. We use this to sync code between
different teams (we have multiple projects on going here), so
essentially the code one team is working on has to pass a lot of compile
tests, render tests, tools tests, game tests, before it gets promoted
high enough for other teams to be exposed to the code. We currently do
not stop code flowing based on frame rate, or code size, we have the
functionality there to do it, but various issues make it a little
tricky, not least of all because there are a lot of legitimate reasons
why there might be an increase in code size, or drop in frame rate and
so on. Just in case you aren't aware, AccuRev is a source control system
that is based on a tree, so you can have different 'streams' of code at
different levels, with code automatically flowing down the tree - I
thought I should mention that to make the above paragraph make more
sense to those that haven't used AccuRev or something simliar.

There are loads of areas we could improve on, but I have been working on
our build system here for a few years now, and it is definitely starting
to come together. We don't always use CI as a way to stop 'bad code' or
'bad data' getting pushed around, but we do use it as a system to keep
an eye on things, it provides an excellent way to find out exactly when
the frame rate halfed, or the level memory doubled, of the scene got
darker and so on.

Steve


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Richard
Sent: 02 February 2010 16:13
To: [email protected]
Subject: Re: [Sweng-Gamedev] time budgets and continuous integration


In article
<[email protected]>,
    Hernan Saez <[email protected]>  writes:

> Now, how do you warrantee a constant framerate by using CI? Is it
possible?
> What tools are there? Sorry, I don't really have much experience on
this.

Go back to the start of this thread where I outlined a way to do this.

All you're doing is treating performance as another testable
requirement.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
 
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.