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

Need tips for CS project management on game/application development

10 posts in this topic

For my winter vacation assignment, I plan on creating a project scheme for me and two colleagues. Our job is to create a 1-year project in which we can plan, develop, and produce a product for everyone to see at a small convention held next year in Spring. It's something that we have to do in order to graduate in CS.

Our main problem is that our project planning scheme is very poorly designed, and we're not good at project planning. My professor asks for a solid project scheme that lasts for 1 full year to 1.3 years, then we can edit it off based on everyone's opinions. Currently, we're wasting time due to both of my colleagues have full-time jobs and I'm left to do most of the planning. I hate to admit it, but this is the best we can do.

Right now, I have planned out a small 6-week schedule, separated into 3 2-week groups, as we also have classes in-between these schedules.
[list]
[*]Initial Planning
[list]
[*]2/13 ~ 2/24:
[list]
[*]Design game genre, game type, story plots.
[*]Graphical layout, on what language, and on what platform.
[/list]
[/list][*]Preproduction
[list]
[*]2/27 ~ 3/9:
[list]
[*]Plan out the basis on the game
[*]Decide upon game controls
[/list]
[/list][*]Program
[list]
[*]3/12 ~ 3/23:
[list]
[*]Program the basis.
[*]Add the game controls
[/list]
[/list]
[/list]
This is all I can think of. I know that this is very short, when compared to a full year, but since I haven't been able to grasp some aspects of project management, I decide on planning things from the small scale, learn a few things, and then slowly jump towards the full scale.

I would like to ask for tips/advices on how to create a project scheme that lasts for a year, based on game development; Or, in a general sense, based on an application development.

One unusual task my colleague gave me before he goes abroad, is that I need to create at least 3 project schemes, so that we can have at least 2 projects to fall back upon, in case our first project fails to meet expectations. I liked to think of this as a practice, and not a burden, unlike what my colleague thought when he told me.

Thanks in advance. If you need more info, please let me know.
0

Share this post


Link to post
Share on other sites
[quote name='tom_mai78101' timestamp='1327138496' post='4904791']
I hate to admit it, but this is the best we can do.
[/quote]

Your grades should be based on the best you can do, not the best we can do.

Others that might help will be more interested in how you developed the plans as opposed to what they are.
0

Share this post


Link to post
Share on other sites
I would suggest agreeing on some sort of shared workspace and free CM tool like Subversion, Mercurial, or Git an one of the appropriate free hosting sites like GitHub, Codeplex, or Google Code. Most of these offer ways to manage the project within them with issue trackers, wikis, etc. Makes working together without stepping on each others feet great.
0

Share this post


Link to post
Share on other sites
[quote name='tom_mai78101' timestamp='1327138496' post='4904791'] I haven't been able to grasp some aspects of project management,
[/quote]

Then read. Here are two books:
Introduction to Game Development (Rabin) - I wrote the chapter on Production.
The Game Production Handbook (Chandler) - I wrote the foreword (the author was my associate producer at Activision).
0

Share this post


Link to post
Share on other sites
What about the project management itself?

Like, how do you provide a scheme that takes control of how much time we need to use up? What can I do to extend my original 6-weeks scheme into a 50-weeks scheme?

If a group of people wanted to do a project, and keeping the software part out (programming, version controlling, etc.), and wanted to plan how the work force, what work should be done, how the work is like, and how long the total amount of work should be done by the time that group is about to reach a deadline, shouldn't they start off with a plan/scheme/something that the group members can rely and work without worrying about what should be done next?

I am grasping that little concept of project management. I hoped that I can get more from this.

EDIT:

@Tom Sloper, do you mean (after reading your post for the third time), you want me to read both of the books' chapters (Production chapter and Foreword)?

EDIT 2:

@Telastyn: Do you mean on how I should develop my plans instead of what they are? When it comes to developing a plan, what are the key aspects if you're starting out from scratch? Do you start from the beginning of the project or from the end? What did I miss out? Thanks.
0

Share this post


Link to post
Share on other sites
[quote]@Tom Sloper, do you mean (after reading your post for the third time), you want me to read both of the books' chapters (Production chapter and Foreword)?[/quote]



No. Read Chandler's whole book. Do not read my foreword.
And, either before or after you read her whole book, you can read my chapter in the other book.

[quote] Do you start from the beginning of the project or from the end? [/quote]

Both at the same time. You have to work it from the back end to determine what the unchangeable events at the end of the project are, so you know when you have to hit Beta. Then plan from the beginning and make sure you don't have too much work to accomplish by Beta.
0

Share this post


Link to post
Share on other sites
[quote name='tom_mai78101' timestamp='1327170851' post='4904888']
Do you mean on how I should develop my plans instead of what they are?
[/quote]

I mean that it's important for you learn how to do something, and it'll aid people here to guide you in learning that if we understand how you developed [i]these [/i]plans.
0

Share this post


Link to post
Share on other sites
If you can get a hold of MIL Handbook 881 (Work Breakdown Structures) it helps alot with breaking down the tasks of projects of any size (software to ships). Once you get past the military jargon, its a real asset. Another good one is MIL Handbook 61a (Configuration Management). What makes these nice is they are free (unlike IEEE, ISO, and EIA). Additionally, ISO, IEEE, and EIA were based off of them ;)
1

Share this post


Link to post
Share on other sites
[quote name='Tom Sloper' timestamp='1327172220' post='4904897'] No. Read Chandler's whole book. Do not read my foreword. And, either before or after you read her whole book, you can read my chapter in the other book. [/quote]

@Tom Sloper, could you recommend another book? Seems to me [url="http://www.eslite.com/Search_BW.aspx?query=Game+Production+Handbook"]the Game Production Handbook is not available in my country[/url]. I'm outside of USA, so my book resources are limited at my disposal.

[quote name='Telastyn' timestamp='1327177355' post='4904913'] I mean that it's important for you learn how to do something, and it'll aid people here to guide you in learning that [b]if we understand how you developed [i]these [/i]plans.[/b] [/quote]

I started developing these plans based on 2 things:[list=1]
[*]Visual graphs made by my professor on his computer, in which it displays the project's lifetime and its deadlines. I've only briefly seen a project scheme that shows a large project split into 20 subgroups, each with an arrow pointing from the main group labeled "Project Name". Each subgroup contains a duration deadline of 2 weeks. This is where I develop the 2-week length for my plan.
[*]Little, but vague facts from my professor, who told me that software projects have to start off with a plan. And without any plans, it would be hard to progress. I don't think that I told him clearly that I do not have the expertise to construct a plan, and at that time, I didn't think much about this until now.
[/list]
From there, I hypothesize that for a project to be fleshed out, it needs to have at least 3 stages, splitting the entire timeframe of the project (lifetime, the duration of the project, etc.). Thus, I planned out the Initial Phase, Preproduction and Programming, the first 3 subgroups which are part of my small "Project Unnamed" project (the 6-week project).

I have not had any experiences in project planning, so the only sources I get from is from my professor, who only taught me that much, when I finally thought of it just 2 weeks before winter vacation (and 1 week before the finals). I had tried emailing my professor, and I'm still haven't received any replies. So, I couldn't get more information from him.

Is that, all of this, known as the answer to the question, "How I develop my plan?" Or I'm still unable to get the picture?
0

Share this post


Link to post
Share on other sites
"Plans are nothing, Planning is Everything" - Eisenhower

Don't worry so much about putting stuff on paper, worry more about the proplem at hand and how you're going to go about dealing with it. That is what planning is: Your approach towards solving a problem. It doesnt need to be complete to the n-th degree, its just a guide you put together to remind yourself what you need to do next on your path to solve a problem. Human memory is faulty, and as programmers/engineers, we tend to get lost in the weeds more than we should and loose sight of where we're heading. Plans help to remind us why we were chasing problem x down the rathole or why group x was chasing that problem. They also tell us where we've been so we dont end up duplicating work as well or tell us where we may have made a wrong turn, so we dont have to start over entirely.

So to sum it up, don't worry too much about "having the ultimate plan", just make sure that you think about how you're going to solve the problem(s) before you, and write that approach down, so you can make use of it and formulate a strategy to resolve it (planning). Do that and you'll have a useful plan.

P.S.:
Remember, NO plan is complete nor correct at the start, not a single one. So don't expect yours to be. They can change and modify as you learn more about the problem you're solving. Additionally, remember this: be able to accept that you may have to start over from scratch if you learn your original assumptions were wrong. Sometimes your initial approach will be the exact opposite of what you need to do to solve the problem, so be comfortable with this idea. Anyway, good luck.
2

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