• 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
bzroom

Being a good technical director

10 posts in this topic

[font="arial"][size="2"]I've recently been given the position of technical director at my studio. I've worked there for almost two years. When i started there were 7 employees. Now there are nearly 40, 8 of which are programmers, spread across 5 projects! I've been there the longest and have the most experience with the code base. I also feel that i am most personally connected to the existing code and seek to preserve its essence and ensure that it's extended in the right directions.[/size][/font]
[font="arial"][size="2"]
Like any promotion i'm having a bit of stage fright at the moment. Being in charge is a lot of pressure. I need to stay open minded, and listen to the needs and suggestions of my colleagues. But i also need to be firm and direct about my stance on the matters.

On my first day as TD we reinterviewed a programming candidate and i decided we needed a set of real questions, not just the "hey how ya doin? do you like programming? what did you do in school?" questions. I feel like I put together a very fair set of questions, covering a wide spectrum of topics. It was by far our longest interview and unfortunately the candidate did not pass the test. I feel like for the company this was a movement in the correct direction.

I really love designing and writing code and I dont want to see myself slip into a purely managerial role. I want to lead with experience and prove by example. I kind of have some possessive issues when it comes to programming though. I'd rather do everything myself and see that it get's done correctly than to allow someone else the chance of screwing it up.

But now i need to delegate more than ever. To lead game/engine programmers, IT, art leads, designers, test teams. I must really live up to the name director. And I most certainly need to get more organized; start documenting and planning more. I need to look at the very long range picture as well as the near range, weekly tasks.

I'm posting here because i'm seeking advice.

What kinds of things would make me a better technical director?
Will you please share your experiences, either as, or dealing with a technical director?
What would have made that experience a better one?

Thank you very much[/size][/font]
0

Share this post


Link to post
Share on other sites
I can't speak to being a "technical" director, but the hardest part of being a manager is accepting that your task is no longer your work, but the success of your team. You no longer have the right to "just get things done myself." It's the ultimate compliment of respect to your team to say, "I trust you to get this done correctly." If you delegate a task and it doesn't get done correctly, it's no longer your job to just get it done yourself, it's your job to build your team so that they can accomplish the task directly. Just to be clear I'm not saying you can't work on anything, just that your focus should not be on working, but on delegation and people building.

I just read a book on leadership in management and one survey on new managers found that if the new manager kept the "just get it done" mentality they ended up not moving up in their career and ended up hating their new jobs. Of those that embraced the task of delegation, they ended up advancing further and enjoying their jobs more.

I can't imagine this is any different for a technical vs non-technical job. I can promise that if you don't change the way you think about your new job you'll only grow to resent it. You can't handle your managers, the demands of your job, and all of the people reporting you, if you feel like you're the only one that can do things correctly. You'll end up burning out in short order. I'm speaking from personal experience mostly. I had the perfectionist mentality and it was detrimental to my team. Luckily my boss is a good teacher and helped me see the light. Since then, my job has been easier, my direct reports are happier, and I have given my team the ability to get promoted instead of pigeon-holing them into their initial roles.
1

Share this post


Link to post
Share on other sites
here is my piece of advice:
be patient. do not make any drastic changes, no matter if you feel that the company need them(e.g. the interview procedure). be methodical. and one thing must be clear to you, some people do not care for the software product (or quality of the code) as much as you do. try get them involved and make them feel they are important to the project.
i am sure i am not telling you anything new and you already knew these things :)
0

Share this post


Link to post
Share on other sites
[quote name='bzroom' timestamp='1322732747' post='4889357'][font="arial"][size="2"]
2.What kinds of things would make me a better technical director?
3.What would have made that experience a better one?
[/size][/font]
[/quote]
1. Congrats :D
2. Bring in Donuts.
3. Donuts.

I didn't answer your second question because most of my interactions are once removed from the technical director so he's more like a guy who sits in a corner somewhere and occasionally comes out to mess with our stuff in my interactions with him.
0

Share this post


Link to post
Share on other sites
Well if you still know almost all of the codebase, it might be a good time to document it. The first thing I always ask (which is never documented/diagrammed) is the game/update workflow at a high level and how the components talk to each other.
For instance:

Main program loop
-Physics (thread 1)
-Rendering (thread2)
-Sound (thread3)

Sound
-Read program settings, if changed, update sounds
-Interface by calling Play/Stop()
-How are sounds loaded?
-Does sound hold all the sound clips?
-How does physics engine connect to sound engine when a collision/sound occurs? Maybe a message system. What class/api do I use to do that?

For my personal engine I diagram everything because it helps myself when going back and looking at it and so far nobody documents anything when it matters when you are working on a team.
0

Share this post


Link to post
Share on other sites
Great idea dpadam!

Wow these forums have really died down lately though. :(

Thanks for the other replies also!
0

Share this post


Link to post
Share on other sites
Read useful stuff.

http://pragprog.com/book/rdbcd/behind-closed-doors seemed quite good for example.
0

Share this post


Link to post
Share on other sites
I've found that so far the best tool we have is communication.

All of the programmers are talking more than ever, because there is a clear leadership position.
They bring a majority of their problems to me and then i can answer their questions, quash their concerns, pair them up, or redirect them to someone else who would be better at helping them.

I create inquiries for other people, refactor the information, and pass it on.
One of my main objectives is to stop new programmers from reinventing the wheel, in major, sometimes catastrophic ways. (dont change all the guid keys to new sequential ones just because they looked almost sequential) I can only do this by talking the programmers regularly. Poking around in changelists and throwing in my two cents on code they've written.

And since all the really heavy stuff ends up on my desk, i still get to have a lot of fun.
During a crunch, a game programmer may ask, hey can you look at this camera code? or can you help me with a crash? and more often than not i have a few cycles to burn for that purpose.

But other times i have to say no i can't help you right now, i'm implementing an entirely new renderer, or other major system.
All in all i'm pretty happy with the way things are going.
0

Share this post


Link to post
Share on other sites
@BZRoom: congrats on your new position!

I'd like to ask you what is your education level to reach this position, and if there is any specialization you're missing right now for it (some extra-curricular course you wish you had taken for this, for instance).

Best of luck.
0

Share this post


Link to post
Share on other sites
Most of the time the junior programmers are happy not to have to do the things i volunteer for. I think we all win in that case. Specifically engine design related tasks. I dont want to give them the freedom to make design decisions in the engine. They can make all the design decisions they want in the game project though, since a poor decision there won't infect the entire code base.

Kryson, i have no real formal training. I've been a basement programmer for 11 years. I've made many very crappy engines. 10 or so physics simulations. The only way to learn is by making mistakes. If i could finish a course now i'd like to take more calculus.
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