• 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
Kevin Lam

Indie Game Development

11 posts in this topic

Hello Gamedev.net! I have recently started an indie group and we are working on a game because our ambition is to have a product by the time we graduate in an attempt to gain entry to the Game Industry. The cruel part being the only way to get into the game industry is to have experience in the game industry.

A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything? Feedback would be very appreciated!
0

Share this post


Link to post
Share on other sites
[quote name='Godoflaugh' timestamp='1352178886' post='4997873']
I've attempted to recreate an actual company feel through creating divisions within the group,
[/quote]
Well.. how large is your group that you need divisions .... from my experiences organisation structures hinders development more than it helps. You might look at [url="http://en.wikipedia.org/wiki/Agile_software_development"]agile development methods[/url] which help developing software in a team based fashion.
0

Share this post


Link to post
Share on other sites
[quote name='Godoflaugh' timestamp='1352178886' post='4997873']
A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything?
[/quote]

This question is not about Game Design. Moving it to Producing/Managing.
0

Share this post


Link to post
Share on other sites
[quote name='Ashaman73' timestamp='1352182181' post='4997885']
Well.. how large is your group that you need divisions .... from my experiences organisation structures hinders development more than it helps. You might look at agile development methods which help developing software in a team based fashion.
[/quote]

I have about ten people working together on the project, and we are all from different area's of study some computer science, art, music, business, marketing, and other fields. I felt by having each person work on their area of expertise and then have one or two people in the middle organize and manage the team would be very effective.
0

Share this post


Link to post
Share on other sites
It really depends.
Is the scope of the project and vision clear to everyone? Is it fixed, or do you expect to iterate?
Who are the stakeholders, who do you expect to potentially alter the scope of the end-product?
What are your expectations and what do you want to ship, and when?
0

Share this post


Link to post
Share on other sites
Yes I have made it my goal as project lead to get everyone on the same page, and from the feedback that I am receiving from them at each weekly meeting is very positive. Currently the project is still a bit open and we are able to iterate new ideas and concepts, since it is still in the early stages of development.
Currently I have no stakeholders, and I'm unsure of changing the scope since the concept we are working with currently is still being fully developed.
My expectations for this game is to have a deliverable by the end of next year, and ship about 6 - 8 months after that, but that would be the most optimal timeline.
0

Share this post


Link to post
Share on other sites
[quote name='Orymus3' timestamp='1352301834' post='4998431']
who do you expect to potentially alter the scope of the end-product?
[/quote]
Note that I said "who" not "do you". If you don't have stakeholders, you still have people that will make the ground decisions. Are you the sole visionary of this project, or do you have any form of tech or creative input and direction from other members on the team? Who has a say, who has the responsibility, and who is accountable for these decisions precisely?
This is a critical information before you can determine whether you want to structure openly or not.
0

Share this post


Link to post
Share on other sites
[quote name='Tom Sloper' timestamp='1352393208' post='4998922']
That's not true. Everyone who's involved in the project has some kind of stake in it.
[/quote]

I was mistaken then, yes Tom you are correct everyone in my group then does have a stake in building this game.


[quote name='Orymus3' timestamp='1352392028' post='4998917']
Note that I said "who" not "do you". If you don't have stakeholders, you still have people that will make the ground decisions. Are you the sole visionary of this project, or do you have any form of tech or creative input and direction from other members on the team? Who has a say, who has the responsibility, and who is accountable for these decisions precisely?
This is a critical information before you can determine whether you want to structure openly or not.
[/quote]
In this design process, I am not the sole visionary everyone on the team is putting their input in and helping to develop the game. Because I believe having only one creative input has a tendencies to give a blandness, since my team is inter-disciplinary it gives a very wide range of design space to work with since everyone in the group has great ideas. However I am organizing everything, and have final say in the process, however I am very open to changes from my team. The person that is responsible for the group would be me, I am assuming responsibility/accountability for the group. I hope this answers your question, hopefully I'm not misinterpreting again. Edited by Godoflaugh
0

Share this post


Link to post
Share on other sites
Then:
[quote name='Godoflaugh' timestamp='1352178886' post='4997873']
A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything? Feedback would be very appreciated!
[/quote]

What do you mean exactly. What is the average day like? What is your process? How do you get to review what's been done and what needs to be done from there on?
What everyone's average day looks like? Are they secluded focusing on their work, or do they interact with others in order to define how to shape things up?

I think you can't reasonably demand that every engineer on the team makes art, but its not impossible for an engineer to help out with art.
The general pro you can have by determining core roles is that you can ensure a core balance: if 50% of your members are engineers, you can expect about 50% of the team to deliver technical stuff. This doesn't mean none of them can make art, but common sense implies people will perform better if they do what they do best.

On the other hand, if you do have people proficient with more than one thing, then, what they do best is simply different.

I'd recommend to build your team around the people you have, identifying everyone's strengths and weaknesses.

Let me give you an example of what I mean:

On a recent project, I was given 3 programmers. What I was told by higher management is that one of them was kickass, another average, and the last, borderline ok. These were judgments based off a very restrictive grid analysis of their performance in terms of logic. Basically, it reflected whether they could make good code or not.
What they left out unintentionally, is what each of their strengths and weaknesses were.

The Good Programmer was kickass, but he needed very strict requirements. He could only work by making an analysis of a formal and detailed Technical Design Document (TDD). On a project where requirements are known, not subject to change, and the output quality is not "guessed", you'd want to clone this guy and use him wherever possible.

The average guy was more of a frontend programmer with a strong ascendant for art. His code was decent, but he's really more the kind of guy you'd want to make sure things make sense. He had a keen sense of figuring out design flaws that would make the game irrelevant. This guy actually helped me out identify design flaws back when they were still in design. As you might know, the later you figure out the flaw, the more it ends up costing. So he was a big help.

The borderline ok coder was actually the one I relied the most on. This guy was what I like to call a gameplay programmer: he's a gamer first, with some technical knowledge. Chances are the kickass coder will have to tell him his errors, help refactor his stuff, etc, but his input is invaluable, and he'll be the one with the patience to fine-tune feedbacks and timings to make the difference between a game "as designed" and a kickass product. It really added a lot that he was also part of the target audience of the project, so he made extra researches, etc. In the end, while his input as a programmer was "ok", his general contribution made him a necessary component of the project's success.

If you divide people formally by department, you might miss on this, then again, if you don't give a more or less formal line, you'll end up creating chaos.
Define roles, not professions. Make people owners of specific modules/features, not tasks. You'd be amazed at how many times I've shipped a title with prog-art just because someone felt involved in the project and decided he'd deliver his absolute best. Give the people some freedom, but keep the line straight. Everyone needs to understand the vision, and how to get there.

Then again, know your team. Some team-member's weakness is that they just don't work that way. They need to be told what they need to do, and they'll do it remarkably well. Not everyone is a visionary, and that's ok. Once you've identified who's a "soldier" and who's a "visionary", make them understand they are the same team. No one is bossing each other out. The temptation of a visionary to boss soldiers is a constant pressure that you need to diffuse. Make them work together, but insure you keep that fine balance. Understand that everyone's thrill and challenge doesn't necessarily lie at the same step. Some people are thrilled by creating the idea, others by developing it from A to Z, and others yet by polishing it to A+.
2

Share this post


Link to post
Share on other sites
Wow, this is alot of information to digest. I'll take these tips and find out my teams true strength's and weakness! I"ll keep you updated on this in the future!
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