I'm a M.Sc from the Computer Science department at Aalborg University in Denmark. I've studied game development at DADIU, as part of my specialization in games on my master's degree and specialized in HCI. Currently, I work as a Project Manager for TimePlan Software in Denmark. I dedicate a lot of my spare time to grow in this role, while I also do investments in my own company. I don't see myself working on game projects in the near future. I have been working on BZSmod since 2007 with level design, programming, and project management. BZSmod has been a great platform to learn and develop my skills related to software development. BZSmod was released with its development files in November 2022, and we support anyone who wants to fork the mod or bring fixes to BZSmod. I blog a bit on moddb when it is related to the mod or personal experience which I find useful for the game community. To read more about my study experience and other projects, see www.ringhauge.dk

Report RSS Practical Game Design

Posted by on

Yesterday I was at a lecture in practical game design.

2 developers (a designer and a lead programmer) who formerly used to work for Deadline Games on games such as Total Overdose, Faith and a .45 (on hold) and watchmen for Warner bros, and who both works at DADIU now; have been talking about their projects and teamwork. Which not only gave info for some stuctures, but also showed a lot of in game prototype , evaluation and how to use that information.

They described the Waterfall "traditional" sector teamwork and Agile (some might know this as SCRUM) which makes a team with required members to make the "prototype".
The waterfall is good if you know what to make, and then do every developer just start on working with the element, however it isn't good for solution creation and unknown development.. or so to say, dynamic development.

Agile do only set a few borders or usually just a problem to be solved, and leaves it to a small team of 2 -4 persons, where we got one from every section needed.
example: Dash movement, how to ..bla bla , includes a coder for implantation and controls, animator for animations and modeler or 2d artist (depending on used technology)
Failure is an option.

The team then gets a few weeks to solve the problem and come up with an prototype. And that is effective in many ways:
Material which can show the feature to the team and as WIP to the public.
A quick decision on whether to include the feature or drop it.
And a dynamic type of development where the schedule fits for those who are included and where it is developed for functionality and quality instead of completion.
It is also supposed to get the morale up in the team.

It was really interesting and reflective, also because at BZS (mod) we are using both methods in our development.
Mainly the waterfall type for the stuff which can be done by one section, and the Agile where teamwork is a key for a proper product.
I think it will be good to focus some more on agile development; As long as we are in alpha there will still be a lot of the waterfall method, because it mainly consist of single persons work which sets the base of the game, as then makes it easier to build projects from that base.

Never the less, it seams that our team structure is good.
(do also see Gamasutra.com for more info)

Post comment Comments
jjawinte
jjawinte - - 5,067 comments

Good read.
These are two of the most tried and true methods being consistently used in many areas of product development today. Personally, I've found both of these methods ( among several through the years ) to be highly effective tools when properly implemented.

The team leaders ability to manage a development time-table while keeping the team focused and productive can truly be a challenge. Depending on the need ( stage ), using these methods can go a long way in keeping everyone on the " same page " and moving as one unified mind-set toward the same goal, while maintaining a necessary level of individual flexibility.

A good article you linked there too. Many new ( and older ) teams could benefit a great deal from learning and understanding these two very basic principles. Would you mind if I posted this link as well on my page in hopes of helping a couple of fledgling groups get some footing ?

( Looks like you've got a fine project going there yourself. Best of luck ! )

Reply Good karma Bad karma+1 vote
eliasr Author
eliasr - - 515 comments

Yes you may link to it or post it if you like.

If there is something individuals can do, i chose to use the waterfall method, while other jobs, will be made into assignments and worked out in a team of 3 to 4.

I do also prefer it because it let the little team learn some groupwork and leadership them self.
However it can be a big failiure if the assigned team isn't good at working with each others.

So while i currently hope to expand the development team, i try to sneak a few assignments in here and there. when some of the team learn to work with each others, it gets much easiere to make new teams where you can put a more skilled leader into it.

It is not the same thing for mod development as it is for hirred development, so the agile method can be a very good way to keep the mod in a democratic way. Which means, that none will fell that working in the mod is without purpose and just extra work.

By the way, thanks for the commentary

Reply Good karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: