• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
chromofo

Are Game Developers 15 Years Behind?

47 posts in this topic

Not sure if you guys agree or disagree, or if you can add some experience to the discussion.

Do game developers deserve the reputation they have when it comes to modern engineering practices?

[url="http://blog.chromosundrift.com/2011/04/are-game-developers-15-years-behind.html"][url="http://bit.ly/eSwMm0"]Are Game Developers 15 Years Behind?[/url][/url]
0

Share this post


Link to post
Share on other sites
It depends which company you work at, obviously.

e.g. At the games studio I'm currently working for, whenever I check-in code, it's compiled and tested by a remote machine before being pushed to the trunk ([i]meaning I can't break the build[/i]). At a previous games studio, any commits to certain libraries were automatically added to a task-tracking system flagging the need for them to be reviewed. I've never had those luxuries in corporate software jobs.

I've worked at a [url="http://en.wikipedia.org/wiki/S%26P/ASX_50"]top 50[/url] corporation ([i]not games[/i]) that was far worse -- Emailing ZIPs for version control and still laughing at OOP as some academic ivory tower concept... So I've got an equally bad stereotype of PHB's and corporate code-monkeys and "architects".

The blog post is a bit silly, in that it's pondering why a stereotype doesn't hold up under analysis.
0

Share this post


Link to post
Share on other sites
Shhh.. don't tell the guys who wrote WoW or EVE online or any massive multiplayer game which supports over a million concurrent users in a realtime virtual environment, handling millions of e-commerce micro transactions daily.. they are doing it "wrong".. obviously their "15" year old coding style just can't compete with the new fangled "agile" methods to todays programmers :)

Game development is like any other software endeavor, there are those who use best practice and do it successfully and those who don't. You can't hold up the failures and say the entire industry is doing it wrong or backwards. Hold up the best and try to make that statement? Most software projects fail, no matter it be game developement or creating a new billing system for Medicare or putting a probe on Mars.. They all have the same chance of failure because ultimately humans are only so clever.. Once software grows beyond the ability of an individual or a few individuals to predict its behavior accurately they fallback to methodology, testing, abstractions, more testing and debugging.. You can only do so many cycles of that before you just have to ship it or cancel it..

Game developers used the agile team based methods well before its adoption by mainstream. Game development has always been collaborative small teams, artists, designers, programmers and producers. And the short development cycles force them to connect and update their progress daily. This is even reflected in the layouts of game development studios, usually they are open based work place arrangements designed for quick access to each developer and facilitate micro-communication and flexible small sub-teams working on sub-tasks.. etc..

Unit testing, Agile development, etc.. I've seen them used in the real world, the good teams adapt the methods to their work style, the poor ones just pay homage to the superficial and abandon it at the first difficulty.. Ultimaitely it boils down to the skill, competency, and experience of the developers and their passions more so than any methodology, though the best teams will have a formalized methodology..

-ddn
2

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1301965451' post='4794440']
It depends which company you work at, obviously.

e.g. At the games studio I'm currently working for, whenever I check-in code, it's compiled and tested by a remote machine before being pushed to the trunk ([i]meaning I can't break the build[/i]). At a previous games studio, any commits to certain libraries were automatically added to a task-tracking system flagging the need for them to be reviewed. I've never had those luxuries in corporate software jobs.

I've worked at a [url="http://en.wikipedia.org/wiki/S%26P/ASX_50"]top 50[/url] corporation ([i]not games[/i]) that was far worse -- Emailing ZIPs for version control and still laughing at OOP as some academic ivory tower concept...

The blog is a bit silly, in that it's knowingly trying to deconstruct an assumed stereotype, and then pondering why those false assumptions aren't holding up.
[/quote]

Many game developers say that game development is more like this even though your experience is the opposite.

Also, there are plenty of game developers defending that difference saying that game development should be or must be like that.

It's reassuring to hear that your experience is that game development is better engineered than the stereotype. I can see why you would feel that the reputation is not deserved.
0

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1301968704' post='4794452']
I wouldn't say that gamedevs are 15 years behind, but 10 might be more accurate if for no other reason than the unholy obsession with C++. Combine that with the relative immaturity of middleware tools and qa processes (development processes have actually improved a bit here)...
[/quote]

There's a lot of discussion [url="http://www.reddit.com/r/programming/comments/giq5c/are_game_developers_15_years_behind_the_rest_of_us/"]here on reddit[/url] about it. Some disagree that it's true, others defend it as true because it must be.

Are you a professional game developer?
0

Share this post


Link to post
Share on other sites
I really don't get it what does it mean "to be 15 years behind". I always thought that being up to date was related more than anything to releasing stuff for the most modern hardware.

@chromofo, what do you think it means?
0

Share this post


Link to post
Share on other sites
Thanks ApochPiQ for your detailed reply!
[quote name='ApochPiQ' timestamp='1301970150' post='4794455']
Anecdotal evidence and lore from the internet do not reliable data sets make.

I find it rather humorous that someone at Atlassian of all places is questioning the practices of some of their most loyal customers ;)
[/quote]

You are right. I don't publish much evidence of the truth of the stereotype, but then there are two problems with that.

Firstly, you have to be honest, it's a well-known stereotype. It does exist and I think anecdotal evidence is proof enough of that.

Now as to whether it's true... teams who adopt these tools and practices are in abundance in the game industry. I acknowledge that. I'm very much on the side of Atlassian's customers. What I want to know is how come there are so many teams who believe these practices and tools are not suited to their industry? I've had PLENTY of discussions with AAA title developers and teams who acknowledge it's a problem but I am not going to publish their names!

However you don't need me to. You can just look around at the comments on [url="http://www.reddit.com/r/programming/comments/giq5c/are_game_developers_15_years_behind_the_rest_of_us/"]the reddit thread[/url] for example. These responses boil down to a few standards:

1. How dare you! or How would you know? (yours)
2. You are right, I know it sucks.
3. You don't understand - games are not suited to this. (I address this in my article but I acknowledge it's tl;dr)

[quote name='ApochPiQ' timestamp='1301970150' post='4794455']
Maybe in 1983.

Not today.
[/quote]


Glad to hear it!
0

Share this post


Link to post
Share on other sites
For any absurd set of thinking, you can probably find a non-zero percentage of the population who is utterly convinced of its truth. (There's a really nasty, below-the-belt comment about religion hidden in here someplace ;) )


Why do some developers think that clear-win best-practices are not applicable to games? I dunno. Maybe you should ask [i]them[/i]... to me it seems like an exercise in rationalizing someone else's delusions. Fun for psychiatry majors, but not my personal favorite hobby ;)
0

Share this post


Link to post
Share on other sites
[quote name='chromofo' timestamp='1301972300' post='4794466']
Firstly, you have to be honest, it's a well-known stereotype. It does exist and I think anecdotal evidence is proof enough of that. [/quote]It's well known for all programming shops AFAICT.

Phrases like "[i]agile[/i]" and "[i]best practice[/i]" themselves have been ruined by the hordes of "[i]certified[/i]" analyst architect systems engineer programmer sigma-6 black-belt wizards and their pointy haired bosses who can talk the talk but not actually [url="http://programming-motherfucker.com/"]program, motherfucker[/url]. Then you've got the mavericks who only care about [url="http://programming-motherfucker.com/"]programming, motherfucker[/url], but have no appreciation for formal methodology. Most people are (thankfully) somewhere in-between the two extremes.

If you haven't heard of the former, you've probably been too busy giving out copies of '[url="http://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F#Criticism"][i]who moved my cheese[/i][/url]' or getting certified in the latest fads, and if you've not heard of the latter, it's probably because you program solo :lol::P

These stereotypes are common to all software people, not just games ones. See [url="http://thedailywtf.com/"]thedailywtf[/url] for fodder.
0

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1301972883' post='4794468']
For any absurd set of thinking, you can probably find a non-zero percentage of the population who is utterly convinced of its truth. (There's a really nasty, below-the-belt comment about religion hidden in here someplace ;) )
[/quote]

True unfortunately.


[quote name='ApochPiQ' timestamp='1301972883' post='4794468']
Why do some developers think that clear-win best-practices are not applicable to games? I dunno. Maybe you should ask [i]them[/i]...
[/quote]


I am asking them, but you keep answering :)

0

Share this post


Link to post
Share on other sites
[quote name='chromofo' timestamp='1301969063' post='4794453']
Are you a professional game developer?
[/quote]

No, I am not. I am comparing my experience in bizdev at shops I would consider slightly above average to my general understanding of gamedev houses (which admittedly comes second hand from the more renowned members here), and a few educated guesses about the... less traditional gamedevs that comprise a lot of the casual/mobile gaming world.

[quote]
What I want to know is how come there are so many teams who believe these practices and tools are not suited to their industry?
[/quote]

I suspect because of time crunch. Practices are percieved as process, process comes with overhead, and we barely hit our release date last time. This is a common driving force in bizdev against process improvement, and I can only imagine that the increased time to market pressure in gamedev exacerbates it.

[quote]
I've never talked to a non-games software shop that even knew what regression testing [i]was[/i], let alone practiced it.
[/quote]

Even the terrible QA departments I've worked with know what regression testing is and dedicated time to it.


So while I don't deny that some bizdev houses (especially those that don't sell software or some software as a service sort of thing) are truly ass-backwards, my experience in run of the mill bizdev just doesn't hold with some of the stories here.
1

Share this post


Link to post
Share on other sites
Oh, I certainly didn't mean to imply that all bizdev type shops are as bad as the example I gave. Nor do I claim to have a representative set of data for that section of the software world. Just offering counterpoints to show that the stereotype cuts both ways: sometimes, the "real world software" guys are just as bad as the popular image of game developers, and vice versa.
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1301965451' post='4794440']
e.g. At the games studio I'm currently working for, whenever I check-in code, it's compiled and tested by a remote machine before being pushed to the trunk ([i]meaning I can't break the build[/i]). At a previous games studio, any commits to certain libraries were automatically added to a task-tracking system flagging the need for them to be reviewed. I've never had those luxuries in corporate software jobs.

I've worked at a [url="http://en.wikipedia.org/wiki/S%26P/ASX_50"]top 50[/url] corporation ([i]not games[/i]) that was far worse -- Emailing ZIPs for version control and still laughing at OOP as some academic ivory tower concept... So I've got an equally bad stereotype of PHB's and corporate code-monkeys and "architects".
[/quote]
Ditto on both counts.

Non-tech companies tend to operate on the assumption that they are not software shops. At one non-game company we had 5 software developers (out of 30 employees) and we were finally able to convince the owner that he needed to properly fund a proper versioning system and backup process. His business -- he kept telling us -- was to provide services to the customers, not write programs. Yet he employed five people to do exactly that. We wrote software, managed databases, kept CRM systems running, and more. He balked at some of the practices we kept trying to push, which is part of the reason I left that job. I've found that while the pay is better, treatment is far worse than the industry.

Game companies, and most tech companies, understand that software is their life. They understand that the developers are basically spinning gold from the ether, and they need to treat them well. They embrace software development best practices because they recognize they are in the software business.




His sources are anecdotal evidence from a few of his peers. He also has links to a few places that have anecdotal evidence for his claims.

Who did they talk to? If they include basement-made projects, the projects in the "Help Wanted" section that starts as an XNA template app with a few crappy drawings and then dies a week later, includes the hundreds of thousands of flash apps that litter the web, and also includes the major studios, then I would agree that collectively that group of people largely ignore modern software design principles.

However, I wouldn't call those people the game industry. I would limit it to the profitable studios, and the few studios who follow the profitable practices but then die for other reasons.

Based on my experience with multiple profitable studios, he is off base.
1

Share this post


Link to post
Share on other sites
For a blanket statement, it is definitely wrong. Software companies will vary wildly on how 'advanced' their software practices and technologies are both in and out of the games industry. I know in general, Japanese developers have some archaic practices in place that one of my friends who recently moved to Japan faced a massive uphill struggle to get some decent pipelines and practices in place. Look at the differences between the major console providers SDKs and the gap can be quite large.

When I was working at EA, we had continuous integration going round the clock every time new code was checked into the trunk and data was submitted. Errors in the build got sent to developers who checked in data and/or code. Daily discs were getting burned. Anyone could pull down executables and built data for any platform at any time from the build server. We had tools to merge two separate Perforce depos due to outsourcing security concerns.

I left the industry since then and the only area that I would say the Games Industry is behind in is investment in quality QA.

(I think everyone here who has responded have been involved in games at one stage or another).
0

Share this post


Link to post
Share on other sites
Considering close association with Atlassian, I find this write up to be disappointing and shallow. It touches on some broad generalizations of publicly available information. Except that what is public represents only mostly hobbyst development which only rarely brings any advanced insight. The article would carry same merit if it simply called all business and enterprise development a bunch of PHP script kiddies and Java code monkeys.


Console development is bound by NDAs and licenses are given only to proven developers. All of them are forbidden from discussing any details in public. Simple consequence is - there is no publicly available insight from anyone doing any kind of console development, aside from a random blurb, meaning PS3/XBox/Wii simply don't exist on the web. iPhone is [url="http://en.wikipedia.org/wiki/Nickelodeon"]Nickleodeon[/url]. Most development is trivial and irrelevant as far as business practices or quality goes. Cheap is the name of the game. Big projects with $500/hour development rates are part of corporate development and internal branding or related efforts, so they are, again, not present on the web.

Big publishers are probably ahead of most bizdev shops. A simple google for "$(AAA publisher) + agile/continuous integration" or "MMO agile/contiuous integration" brings up articles like [url="http://www.electric-cloud.com/solutions/agile-software-development.php"]this[/url] or [url="http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/"]this[/url]. Searching around gamasutra brings articles [url="http://www.gamasutra.com/view/news/31365/IGDA_Leadership_Forum_Sega_Australia_Zynga_Discuss_The_Agile_Way.php"]like this[/url]. These are companies where per-product investment is $100 million and revenue measured in billions.

The final misconception is regarding priorities. Source code is a solved problem. Not only that, but entire physical development is increasingly irrelevant as far as big picture goes. Entire development budgets can be [url="http://venturebeat.com/2009/08/26/eas-chief-creative-officer-describes-game-industrys-re-engineering/"]as low as 30%[/url], that includes creative design, testing, coding and asset creation. Success of large publishers is almost completely dependent on marketing and franchise or licensed IP.

Then there is innovation which puts bizdev into stone age. Toolchains which allow [url="http://www.computerandvideogames.com/294526/news/xbox-360s-bright-future-how-milo-kate-handles-billions-of-polygons/"]real-time versioned collaborative[/url] development on Xbox360 with scenes comprised out of billions of polygons - all real-time and interactive. How many businesses would consider one million database rows "huge".


The article illustrates a huge clash of cultures. But it has nothing to do with script kiddies learning in garages.

JIRA is de-facto toolchain for mostly OSS development stacks, primarily Java centric. That ecosystem is open, homogenous and fairly standardized. It's used almost exclusively for various forms of CRUD development. The toolchain it presents is well suited for both the culture and problems that need to be solved. The number of openly available frameworks and libraries facilitating all aspects of development is enviable.

But when one goes out of that industry, the ecosystems are closed and proprietary. While that does have slightly negative effect on quality it also skews the perspective on what goes on. People involved in such development simply do not engage into broad public discussions nor are they allowed to. Another industry where this is prevalent is industrial automation and CAD. Reason are similar - underlying toolchain is always proprietary and trade secrets and other legal implications of discussing such work freely pose too much of a risk. Evaluating these industries in same manner would be comparing them industrial automation by Arduino project.

The other aspect ignored is the actual needs. In aerospace engineering, deficiencies in CAD tools are irrelevant. If a tool does not have "select all", someone will be employed to click on all elements. LabVIEW is a pain, but solves actual needs. Bioinformatics is a mess (this is one field to look into, they really love the insight, but one needs a degree in medical or related field + CS) but pharma is big money, so throwing more manpower is still an option. Gamedev also sees abundance of labor - starry eyed kids, willing to work 90-hour weeks - they are cheaper than retraining top-of-the-line experts, whose time is valuable and expensive.

Article ignores the reality of business - in most industries, automation of certain tasks is too expensive. General IT, with falling profit margins need to minimize expenses on custom development and infrastructure. Minimizing labor makes sense. But elsewhere, just throwing more people at it works. Automation is only introduced when required or when the field becomes a commodity. This is why so much manufacturing is still done by people - they are simply cheaper. Agile does not necessarily mean machine automation.


Very few still have time to try to figure out the precise definition of the word "Agile" because ever since they adopted "agile" practices, software development is a solved problem.
0

Share this post


Link to post
Share on other sites
Forgot to mention this in my previous post: http://blog.ccpgames.com/alli/files/2010/08/Ottarsson_GlobalAgileGameDevelopmentNoPassportRequired.pdf

GDC presentation from CPP (Eve Online) who use Agile on a global scale.
0

Share this post


Link to post
Share on other sites
The major issue we have in game development are the deadlines. We can't think how we are going to code and design it, because we need to get it done fast.
In the company I work we do both, software and games. And both department are very different on that matter. Software side have more time and money, for simpler applications. The game side, there is the publisher on one side that want the game out for that period of time and the funding on the other side that is too low.

If we fix that basic fundamental issue, then maybe game developers will have more time to unit test and all that stuff.
0

Share this post


Link to post
Share on other sites
[quote name='Daivuk' timestamp='1302024359' post='4794684']
If we fix that basic fundamental issue, then maybe game developers will have more time to unit test and all that stuff.
[/quote]

Unit tests are so 2000. They were novel and interesting back then, but problems that needed to be solved were different. Writing unit tests makes sense when writing a library or an algorithm.

But for all practical purposes, they are too low level today. With a few notable exceptions, nobody can afford to develop such low level tech anymore, unless they are middleware vendor and those are increasingly absent.

What matters is delivering a product. Users never ever cared about correctness of code. Think of how many projects ship with warnings. What matters to users is functionality, even if there are some bugs.

Enterprise has been steadily moving towards behavioral testing for design, automated staged deployment for integration testing and integrated metrics for product development.

Behavioral testing can be difficult to formalize. It's easy in CRUD, where "take form, enter "Foo" assert value = Bar". How do you describe behavior in interactive simulation? This is a much bigger question than anyone is capable of answering right now since it's also subjective, yet it's what sells. But this type of tests is indeed performed - but on important issues. For example, [url="http://www.destructoid.com/ratchet-and-clank-might-be-insomniac-s-last-60-fps-game-153621.phtml"]30 vs. 60 fps[/url]. Unit tests are just too low level and libraries are provided by third-party vendors anyway so if something breaks, there's a phone.

Staged deployment for services has been the norm for anything service-like anyway. It's next to impossible to deploy web-based projects without it.

Final and important part is metrics. It has become almost mandatory to not stop testing once code is live. It's when the real development starts. So once a (web service) runs, actions are gathered, analyzed, compared to previous versions. That will shape the future development, regardless of whether a handful of features are broken.

Unit testing is almost crucial for some small parts, such as volatile third-party extensions (Facebook/Twitter APIs, for example), modules like billing or user management or when planning for certain types of ports. What cannot be ignored is constant factor cost vs. number of regressions. Many developers are highly experienced and have learned to write code using proven techniques, thereby reducing certain types of defects. Effectiveness of unit tests specifically needs to be weighted against the constant factor cost vs. number of regressions. If a typical developer has low number of regressions, the added cost of tests will not be amortized. Expected life-span of the product along with relevance of bugs (often bugs have no statistically significant impact) are also deciding factor.

In perfect world, all code would be 100% tested with 100% coverage of all code paths. In real world, one only has 2% of time needed to actually deliver. To counter that, experience, knowledge and training in battle-tested techniques removes much need for blind application of tests.

All that matters is end result. And users decide whether it's good or bad. If unit tests suddenly make users like the product more and if it increases sales, then it's used. If reducing development time through use of unit tests helps that goal, it will be done as well. Otherwise, it's just a ritual that doesn't actually solve any real problems.

As with everything: Is unit testing required: Yes. No. Maybe. It depends.
0

Share this post


Link to post
Share on other sites
Unit testing != agile.

There are several [url="http://tech.groups.yahoo.com/group/testdrivendevelopment/"]established TDD discussion groups[/url] that I have lurked and occasionally commented in for years, the one linked to specifically is generally run by many big names in TDD, automated testing, and agile development. They have periodically had discussions about what should NOT have unit tests written for it.

There are some very strong business arguments against writing test code in certain situations. Many of them have been backed up with solid financial research.

There is no dispute that unit tests are expensive to write and maintain. Full coverage will effectively double the cost of initial development. If best practices are followed they recover the costs as part of the long tail of maintenance. When best practices are not followed, such as developing over-complex unit tests or spotty coverage, there is less of a reduction to the point where it becomes more expensive to maintain the tests than it would have been to never write them. Migrating legacy code into a test harness has a significant cost which (depending on the business patterns) may never be recovered. On a similar vein, if the support period is short enough you can following all best practices from the beginning yet have a maintenance tail too short to recover the costs.

Most game code fits in that last point. In games a lot of code is once-off code which is discarded at the end of project with only a tiny bit of code folded back in to the engines. The costs of developing and maintaining unit tests would never be recovered; it is less expensive to hire an army of testers at the end of the project.


That is not to say that they aren't using modern practices. Instead it means that in many cases they are (correctly) deciding to adopt what makes sense for the business model rather than blindly following the crowd to pick up a practice which would harm their specific business.
1

Share this post


Link to post
Share on other sites
[quote name='frob' timestamp='1302030015' post='4794710']
They have periodically had discussions about what should NOT have unit tests written for it. [/quote]

Another type of discussion where broad arguments are made is static vs. dynamic typing. The common theme is that static cannot be agile or is ill-suited.

Statically compiled languages require a set of assertions to be met before they allow anything to run. Sort of implicit unit tests built into language. In some cases, these harm the development since the assertions are completely unrelated to business case. While refusing to build due to int overflow makes sense in theory, it's a fairly irrelevant bug for many applications. Or better yet, but the time overflow becomes an issue, project can fail in many other ways.

In similar vein, compiled languages typically require complete restart. This is not unique to C/C++, nor do those strictly require it. For quick iteration, minimizing the turnaround is crucial.

It's also something many agile shops forget. Agility does not come from unit tests alone - how long does it take for new developer to set up full environment, how trivial is it to add some new tool, how trivially can multiple people experiment on same issue or concept, how much can be done during run-time. Often, only one of these issues will be addressed and often in an over-generic way.

[quote]There are some very strong business arguments against writing test code in certain situations. Many of them have been backed up with solid financial research.[/quote]
Another factor is manpower.

Assuming one is working on a project that needs to be completed by a certain deadline - or else (aka, shop goes bankrupt). Unit testing is touted as being able to alert about failures quickly. But what if one has a team of dedicated testers that check out latest build and test everything. This is not uncommon. In this case, people take over the function of full testing, from deployment, integration, units, ... Another argument for making full builds trivially available. Such testing does result in more regressions but is more open to experimentation.


I think that nobody is arguing against testing, but turns out that finding cost-effective methods is far from trivial.
0

Share this post


Link to post
Share on other sites
[quote name='Daivuk' timestamp='1302024359' post='4794684']
The major issue we have in game development are the deadlines. We can't think how we are going to code and design it, because we need to get it done fast.
In the company I work we do both, software and games. And both department are very different on that matter. Software side have more time and money, for simpler applications. The game side, there is the publisher on one side that want the game out for that period of time and the funding on the other side that is too low.

If we fix that basic fundamental issue, then maybe game developers will have more time to unit test and all that stuff.
[/quote]

There is also quite often less code reuse outside the engines (Which are often licensed), so code quality isn't as important as it is for a business app where the code might stick around for 15+ years.
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1302032463' post='4794731']
There is also quite often less code reuse outside the engines (Which are often licensed), so code quality isn't as important as it is for a business app where the code might stick around for 15+ years.
[/quote]
It isn't that quality does not matter. It does.


Instead it is a matter of costs.



When code will be maintained for 15+ years then it makes sense to spend an amount roughly equal to the initial cost to build automated tests.

When code will be maintained for a few weeks it makes sense to hire a bunch of test monkeys to hammer on it for a while.




The reverse is not true:

A 15+ year maintenance would be nonsensical to keep an army of test monkeys employed for 15+ years. The near-instant automated tests have a high initial cost but replace a multi-week battery of manual tests. Several months of initial labor is small compared to 15+ years of labor.

For a game, it is similarly nonsensical to invest a year or more of labor (roughly 1:1 correspondence between production code and test code for full coverage) to replace a single 2-3 month manual process.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0