• 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.
  • entries
    73
  • comments
    77
  • views
    81326

Why Small Companies Succeed

Sign in to follow this  
Followers 0
JoshKlint_34394

2255 views

The development of Leadwerks3D seemed like an impossible task at first. Not only did I need to write a new 3D engine entirely in C++ mostly by myself, but I had to make it run on four platforms (Android, iOS, Windows, and Mac), with a scalability all the way from the fixed-function pipeline up to the very latest hardware tessellation features. All logical sense told me this was impossible. Even large companies with 100 programmers or more haven't yet been able to put out a 3D engine with the range of platforms and scalability I am targeting. What makes me think I can do it?

As we approach the initial release of Leadwerks3D, what I thought was impossible seems much more feasible now. During the course of development of Leadwerks3D, I've learned some important ideas that give a lot of hope to me and to indie game developers everywhere.

Systemic Interdependence
When managing complex tasks there's something called systemic interdependence. This refers to the idea that when you have many people working on one project, they are rarely isolated from one another. They often have to stop and wait for another person's job to be done before they can continue with their own, and programmers often end up stepping on each other's toes when they work together.

Even though only Aria and I are working on the source right now, we have experienced this. It's very important we keep busy with separate aspects of the engine. Aria works on platform implementation issues, I work on the core engine design, and we try our best to keep the source code repository in sync. So far this works well for us, but I could easily see a lot of problems arising if we had more people working on parts of the engine that aren't so easily compartmentalized.

Think about your own game. What if I told you I was willing to give you as much money as you wanted to hire programmers, (as long as your final project gave me a big return on my money). Sound great, right? So you go out and hire ten programmers. They come in every weekday, 9 to 5. They're willing to work, but you have to instruct them and keep them busy and productive. Don't have anything for them to do at the moment while you finish one little part? Too bad, they're still on the clock and you still have to pay them.

With ten programmers, would your game get done ten times faster? Almost certainly not. In fact, as you add programmers, your work output will probably look something like the graph below. With one programmer, we have an output of 100 arbitrary units. We gain efficiency with the first few programmers, but the effect lessens with each additional worker. They have to wait for another person to finish something. Now the code repository is conflicted, and you have to figure out how who added what code. You also have an increasing number of relationships and communication between individuals.

Image2.png

Once we get past five programmers, additional programmers actually have a detrimental effect to our output. If we continue adding more workers, we can reach levels of output that are below even that of a single programmer. Imagine if 30 people were working on your game. It would be chaos, and that whole time you would be burning money as they came in every day. Meanwhile, your investors would be sitting impatiently, expecting you to get back a lot more money than they put in.

My chart above isn't precise, and the number of programmers a project can support will vary based on its ease of compartmentalization, but the overall idea stands: Software development does not scale very well with additional manpower. This is why small companies are continually springing up and outmaneuvering larger ones. Android came from a small company. It was bought by Google, but only after a small team had built the foundation. Minecraft came from a very small company. Kinect originally came from a small company. Small companies with focused goals are able to compete with much larger companies because of the effect of diminishing returns.

Performance and Motivation
Another problem big companies have is motivation. In a professional software development environment, managers like to have measurable performance metrics to evaluate employee efficiency. These are used for performance evaluations, and are the basis for salary increases, promotions, and disciplinary actions. Managers set goals and milestones that can be easily measured after a period of time. Workers respond to this by doing exactly what management tells them because they get rewarded for it. If a worker has an idea for a new technique that might or might not work, they're not as likely to spend time on it in this environment. If it works, the company gets to keep their idea and they get nothing. If it fails, they've wasted time on something that doesn't fit into their manager's ideas of measurable performance. Now, a lot of tech companies do try to encourage innovation, but if a worker has an idea for something they really believe in, they are more likely to form their own company where they can be in complete control of their vision. The professional software development environment does not encourage risk-taking and innovation the same way small companies do, because they need easily measurable metrics to assess performance. They only get out of employees what they reward, and it's hard to measure the value of new ideas and attention to detail.

Conclusion
These ideas I've learned during the development of Leadwerks3D are directly applicable to your own game projects. Don't get discouraged when you run into a tough problem. Even if you had more help, you would still have to figure out a solution, one way or another, and you wouldn't be able to shift that responsibility off onto employees. You can do it, just be wise about where you focus your efforts and plan carefully.

2
Sign in to follow this  
Followers 0


9 Comments


I've been saying this for years. Nobody seems to listen because they have never worked on their own projects. Only those who try their own work will ever understand. I work at about 60 to 100x faster on personal projects than I do at work. My graph would drop off after about 3 programmers though. You could be productive with 5, but your brains are less connected. 1 person can have a vision in which they don't have to communicate to anyone, 2 people share visions through talking and short meetings, 3 people is a discussion on mixing visions. After 3 people you need some longer group meetings.

One thing other than motivation you missed as well, is with a company of more than 10 people, people leave companies. So when you lose someone that built 1/3 to 1/10 of the entire code-base, no new hire will ever be 100% in tune with that persons code and know all the ins/outs, it is impossible unless you can physically read minds in the future.
0

Share this comment


Link to comment
I've personally experienced this at my current job. It is just me and another developer, but he designed the whole project and wrote almost all 30k lines of code. Getting me up to speed is nearly impossible, but I have been able to built new components for it and implement them. We have ran into a lot of repo conflicts a long the way. This is just 2 developers too. But I often spend more time reading the code trying to understand it then I do actual programming. I've probably added only 3 - 4k lines of code to this project so far. But we are slowly getting in sync with each other, it is quite the progress. Excellent read though, I am also way more productive on my personal projects then the ones at work.
0

Share this comment


Link to comment
Sad but true, I've spent many a lunch conversation on this topic. We tried to express these issues to corporate but it was too little to late, and now our studio has been "economically down sized" LOL good riddance
0

Share this comment


Link to comment
Curious, are you and Aria using a central (eg, Perforce) or distributed (eg, Git) source control solution?<br><br>To branch off your example, you wouldn't hire those 10 programmers all at once. You would hire them as your needs factor out grows your man power factor. You must also decide if the "need" is actually a need at that point in time. Yes, you may need a pipeline for getting assets into the engine, but you need a base class library or at least some sort of framework that handles IO, memory, etc before you even start down that road. With this route, those new programmers won't be waiting on anyone. Compartmentalization, just as you talked about.<br>
0

Share this comment


Link to comment
We use an SVN repository for source control. Of course, my article was not meant to declare a hard and fast rule that was accurate 100% of the time. Everything else being equal, a larger team will have a lower per capita efficiency than a smaller one. When developing a complex application with many interwoven systems (like a game) this loss in efficiency can be very significant. This article was written to explain some of the advantages people working in small teams have, so they can better understand their own strengths.

In the past I sometimes found myself engaged in wishful thinking that if only I had more manpower I wouldn't have to figure out some complex task...but more workers doesn't make design challenges go away. You still have to make all the design decisions, describe to your employees exactly what you want them to do and how they should do it, and verify that it was done correctly. Often times it's much easier to just do it yourself than try to assign, monitor, and evaluate someone else's work.
1

Share this comment


Link to comment
Good advice.

Game development favours parallelism in the development cycle; interdependency introduces a big communicate hurdle if you constantly have to check "are you doing this? 'Cus I'm doing [i]THAT[/i]" kind of thing. So, yeah, smaller teams certainly get a big boon from not having to deal with that particular problem set. However, manpower does have it's advantages and, if used correctly, you [i]will [/i]be able to do [i]more [/i]and [i]faster[/i] than if you had a smaller team.

The obvious conclusion is that you don't get things done "easier" if you have more people working on it, but you can get [i]more [/i]if you can get several people working on multiple (different) parts simultaneously.

Motivation is a given whether it's the paycheck or the game itself that provides it - I would agree that the latter motivates innovative behaviour more often than not (which small companies often find useful; larger companies rather want work churned out than argumentive employees trying to 'change stuff').
0

Share this comment


Link to comment
Iif a person works alone, can work very fast. Even easilly keep up against teams with 10+ person, becouse large teams needs serious coodrination, wich affects the production badly. There is only 5 thing needed: knowledge, experience, vocation, time, and pizza.
0

Share this comment


Link to comment
One person alone, is so isolating, you build walls around you and your work - at least one more, and you bounce ideas off each other, its better
0

Share this comment


Link to comment
I love this journal entry ... and your tech looks amazing, great work! I think a super dedicated single programmer "team" can achieve the same output as a team of 10 or so less motivated and/or skilled people combined with the efficiency decreases you mention.

Good work...

- Dan
0

Share this comment


Link to comment

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