• 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
Nicholas Kong

How much planning do game programmer before writing a single line of code and how do they plan it out

28 posts in this topic

Despite the planning, are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

 

As a self taught game programmer who has been writing the codebase for one month and 2 weeks for a role playing game, I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

 

Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

 

Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

 

What exactly would they talk about before writing a single line of code?

 

How do they put the codebase together before writing a single line of code if they never written the code before? 

 

What is the process like? Is it necessarily

 

1) communicate some. write pseudo code on whiteboard to spot bad code design.

2) everyone build their side of the codebase

3) merge the codebase together

 

Repeat the above steps

 

Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase.

 

On a side note: When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

 

I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

 

I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.

 

Any feedback about the above would be appreciated. biggrin.png

Edited by warnexus
1

Share this post


Link to post
Share on other sites

Have you read a bit of systems engineering? System analysis? Requirement engineering? UML? Software lifecycles?

 

There are a lot of moving parts on project planning. And for software development, there have been a lot of things made to start planning and experimenting without writing a single line of code.

 

For example, this "parameter passing" is something you would define in an UML class diagram (having beforehand established each class responsibility and collaborators), you'd define what fields such class would have and what methods it would need to fullfil its responsibility.

 

But what if you don't clearly foresee all the methods you might need? Well, there are sequence diagrams that can demonstrate all the "messages" the different objects would need to know to make a certain interaction with the system work.

 

All of this is often interweaves with other methodologies (not so much about planning but development, like the trendy "agile" methodologies).

 

Most often not all of the programmers are involved in this process, programmer do the coding, the grunt work, software design is a different thing altogether, in these design processes is where software architects are involved, not all programmers.

 

In short, "planning" is a very broad subject, you can do lots of it before starting to code, and there are been lots of people studying exactly what you're asking, how to do software planning.

2

Share this post


Link to post
Share on other sites
At my work we always try to structure things out before we begin coding...of course you can not catch everything! We also are mostly working with php and mysql when working together and planning.

It looks like you have some of theright ideas and im wonderimg if you are gettimgto the point where you should be working with a small team on a small project to continue your learning.

I also am not sure if you are familiar with using git but it might be worth your time taking a look at learning it for a version control system while working in a team. I say this cause eventually you will run into version control and will need a way to merge with your other team members code.

I guess I didnt answer anything reslly specific but I hope you find my post useful.
1

Share this post


Link to post
Share on other sites

Others covered that there is no magic approach used in planning, but I want to urge you to fail. You're holding yourself back trying to avoid failure, but failure is part of success. My previous job was obtained by failing at the interview, but impressing just one manager so much that he created a position for me. And it was a way better job as a result. It didn't really have a job description, so I just got to do insane and amazing stuff without worrying if it was in my job description. I got to work with the driver guys, the UI guys, QA, the build team, the team in India, and everyone in between. Most projects I've worked on failed to achieve the original goals, but still succeeded in achieving amazing results. Every bug I ever closed involved failing on every single solution attempted except the final one.

 

So start working with teams even if you don't think you're ready. Apply for every job you think would be a blast whether or not you meet the qualifications. And tell people straight up that you don't have the experience yet, that you're going to make mistakes, that you're going to learn a lot as you go, but that you're going to work your ass off to make up for it, and you're going to love the work and the challenge.

0

Share this post


Link to post
Share on other sites

I never write proper UML.

 

I do though often write boxes with arrow between them to map out classes and dependencies.

 

It borrows from UML, but I basically just use 3 kinds of arrows. inheritance, component (class directly owned by another class) and general more loose "depenceny" (dashed arrow). 

 

For all of them though I read them as "A depends on B", and then all the arrows go the right direction in my mind...

 

I find it easier and more persistant to have it on file, and it helps to spot when where and how to refactor.

 

It's very much a living document in the beginning of a project, until the general infrastructure of it all solidifies.

 


Every bug I ever closed involved failing on every single solution attempted except the final one.

 

How could it be any other way? :)

0

Share this post


Link to post
Share on other sites

Others covered that there is no magic approach used in planning, but I want to urge you to fail. You're holding yourself back trying to avoid failure, but failure is part of success. My previous job was obtained by failing at the interview, but impressing just one manager so much that he created a position for me. And it was a way better job as a result. It didn't really have a job description, so I just got to do insane and amazing stuff without worrying if it was in my job description. I got to work with the driver guys, the UI guys, QA, the build team, the team in India, and everyone in between. Most projects I've worked on failed to achieve the original goals, but still succeeded in achieving amazing results. Every bug I ever closed involved failing on every single solution attempted except the final one.

 

So start working with teams even if you don't think you're ready. Apply for every job you think would be a blast whether or not you meet the qualifications. And tell people straight up that you don't have the experience yet, that you're going to make mistakes, that you're going to learn a lot as you go, but that you're going to work your ass off to make up for it, and you're going to love the work and the challenge.

I would not say I never failed. Every feature I wanted to get right in my rpg game was a failure because it never works the first time. It was only after many hours of thinking was I able to improve the code design and got the feature to work. 

 

Great tip! Thanks!

0

Share this post


Link to post
Share on other sites

Maybe I am reading this wrong, but is this not the same thing, with the flow pattern inverted.  If I inherit from you, should not the arrow point from you to me ?

UML being just an example to illustrate a point, I am not willing to go too much further with it, but I will at least just respond to this.
This is exactly my point. The mental image you have constructed tells you to have the arrow pointing one way, while my image tells me it should be pointing the other way. I think the arrow should indicate what is being taken, but you think it should indicate what is being given.

Obviously I’ve learned to deal with it, but the conversion process from one line of thought to my native line of thought takes time, and that is the end result any time you tell anyone else how to think.


L. Spiro
0

Share this post


Link to post
Share on other sites

Every UML diagram I've ever seen has inheritance arrows point from the derived class to the base class. If you have co-workers that do it the other way round, hit them over the head with the thickest UML book you can find.

 

In terms of planning, don't overuse UML. It's neat to "get the point across", but to do that, you need just a very basic subset. No point in cluttering up a diagram with tons of obscure symbols to describe unimportant details. Nobody will want to look at that complicated mess and that's where the whole point of using UML in the first place is utterly defeated. For the most part, I'd stick with class diagrams and flow charts.

 

Tempting as it might be to just start hacking away to get stuff to show up on screen, nail down as many requirements/features as you can in advance. Adding stuff to a code base that isn't prepared for it tends to be messy. At the same time, trying to prepare it for everything you imagine may or may not be needed 10 years from now is even worse.

0

Share this post


Link to post
Share on other sites

If I understand the question of the OP, it's how to deal with the problem of bad dependencies in code, especially working in a team.

 

There's a lot of written material on agile development, but I think the key here is communication. A large enough system will consist of several subsystems, and this usually makes for a natural division of labor. Team planning should focus on the boundaries between the subsystems, because these are the large scope dependencies. 

 

A little planning will help you avoid some of the bad dependencies. But more importantly, you have to constantly keep looking for them, and take the time to refactor the code whenever they pop up. It's just as important as fixing bugs.

 

As for UML, I find it invaluable for high level brainstorming, and worthless for low-level specification. As for the arrows, it's only a language, like some feel subject-verb-object order is more natural while others prefer object-subject-verb.

0

Share this post


Link to post
Share on other sites

There's a different between thinking and communicating. If a superior would impose UML it would be for communication purposes, and it's what UML was designed for. One of the key features of UML is precisely the arrows, which represent the various kind of dependencies that occur in a complex system, and I think that's why it's was brought up here.

 

UML is just a language, and it's efficient for some purposes, but not for others. I find it easy and natural to think in UML but thats me, and just because I've been doing it for a long time. But again, in a team environment communication is important, and it's only possible with a common language, whatever that language may be.

0

Share this post


Link to post
Share on other sites


This is exactly my point. The mental image you have constructed tells you to have the arrow pointing one way, while my image tells me it should be pointing the other way. I think the arrow should indicate what is being taken, but you think it should indicate what is being given.

This is the point of this thread.  Everyone will have separate opinions on how things should be.  This is fine as long as you are working alone, you can have things the way you want.  While I respect your point of view, you should also respect mine.  As part of a team, the direction of the arrow could be part of the planning discussion.  If the group decides, based upon your vast experience, (which I am willing to concede) or your leadership qualities that having the arrow point your way is better, I am fine with that.  If not then maybe I should not be part of the team.

  This is why you need to have team meetings,  everyone needs to be on the same page, or you will be singing 1 song while the choir sings another.

In the end, it is all positive.

2

Share this post


Link to post
Share on other sites
Nothing beats your own experiences in determining how much forethought and planning you need before you start the actual programming process. With that said, I would start with the basic premise of the application: List the features that you would like to have, categorizing them into “needs” and “wants”. Weed out the “wants” until you get something manageable—keeping in mind that some of the “wants” you weeded out can be placed back into the final product. At this point you should make a structure that everyone in the team can understand—this is the key. Now you are ready to code. How much detail involved in the planning phase is up to the team. Don’t let any convention block you from starting you coding.
0

Share this post


Link to post
Share on other sites

Nothing beats your own experiences in determining how much forethought and planning you need before you start the actual programming process. With that said, I would start with the basic premise of the application: List the features that you would like to have, categorizing them into “needs” and “wants”. Weed out the “wants” until you get something manageable—keeping in mind that some of the “wants” you weeded out can be placed back into the final product. At this point you should make a structure that everyone in the team can understand—this is the key. Now you are ready to code. How much detail involved in the planning phase is up to the team. Don’t let any convention block you from starting you coding.

I see. Thank you!

0

Share this post


Link to post
Share on other sites

Despite the planning, are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

 

As a self taught game programmer who has been writing the codebase for one month and 2 weeks for a role playing game, I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

 

Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

 

Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

 

What exactly would they talk about before writing a single line of code?

 

How do they put the codebase together before writing a single line of code if they never written the code before? 

 

What is the process like? Is it necessarily

 

1) communicate some. write pseudo code on whiteboard to spot bad code design.

2) everyone build their side of the codebase

3) merge the codebase together

 

Repeat the above steps

 

Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase.

 

On a side note: When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

 

I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

 

I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.

 

Any feedback about the above would be appreciated. biggrin.png

To answer your question, it is best that you become familiar with the SDLC (Software Design Life Cycle) and the AGILE-Scrum process of this cycle, including what stories, sprints and backlogs are.

 

There is something called the Technical Design Specification. It is a book, created by the designers and in part, the developers of the SDLC. It encompasses just about every diagram you can think of: Use Case UML, High Level Class Diagram UML, Database Design, ERD, Dataflow Diagram - Flow Charts.

 

Before a single code is worked on, the Technical Design Specification should be completed. The reason is because of the first page of this book, being the contents regarding its Purpose and Description of the Requirements.  In a nut shell, if either the Purpose or the Requirements are breached or not met, then you either have one really passive and generous client or... you can't adequately define your sprints, which results in project failures (and people start losing their jobs and companies start losing a lot of money). All the pages there after the first page, break down what the program should do.  And that breakdown, allows a sprint log to be created, which allows management for the overall project.

 

As a one man programmer, yes, you can get away with not using this.  As a two or three man programmer, you might be able to get away with not using this. But as the numbers increase, so does the unlikeliness of succession from not using the Technical Design Specification.

 

 

Hope this helps.

0

Share this post


Link to post
Share on other sites


Doing something for the first time is always the hardest.
Hence no amount of planning can trully prepare the developer for a solution to the problem. 
 
Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better. 
Rather than having talks with people of what could be and what not.

 

Correct. This is why almost all internships do diagrams and charts rather then pure coding. Conceptual understanding is critical, or you're just coding blindly. It's also an easy way to spot a very obvious bug that could be over looked in development. What saddens me is when people bash charts and diagrams, claiming it to be useless. For some, such things may be a hindrance. But here's my outlook on it: 1 great programmer can not program nearly as good as a 100 moderately good programmers working as a team. While it's critical to be confident, its crucial to identify when confidence is tainted by belligerence and ignorance. I would much rather work with the person that needs the flow chart and communicates well with me than someone who is too good for anyone else.  So yes, communicating to the point of what is needed (typically in a chart or diagram) can be of a invaluable asset for leadership and direction, which means more man power to complete the larger task at hand.

0

Share this post


Link to post
Share on other sites

 


Doing something for the first time is always the hardest.
Hence no amount of planning can trully prepare the developer for a solution to the problem. 
 
Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better. 
Rather than having talks with people of what could be and what not.

 

Correct. This is why almost all internships do diagrams and charts rather then pure coding.

 

 

This is contrary to my experience. Certainly I was working on the codebase from the start in all of my own internships. Most other people I've talked to also worked on the code during their internships and only used diagrams as prototyping or documentation aids. Maybe this depends on the company, but every place I've worked has preferred that I use my skills to actually write code and accomplish things rather than play with diagrams all day.

 

 

 

1 great programmer can not program nearly as good as a 100 moderately good programmers working as a team.

 

I don't think those are really comparable and I'm not sure I see what you're getting at beyond the obvious (more people = more man-hours). Sometimes you neither have nor need 100 moderately good programmers to do something and happen to have a great programmer on hand; would you advocate dropping the great programmer and hiring 100 moderately good programmers? Plus, those 100 moderately good programmers could have trouble communicating with each other, leading to much lost productivity. There is such a thing as too many cooks in the kitchen and adding more people beyond a certain point does not automatically mean more actual work being done.

 

 

 

 I would much rather work with the person that needs the flow chart and communicates well with me than someone who is too good for anyone else.

 

The bold text is what I think is the real issue. You want to work with someone who thinks like you. But do you really need the flow chart or diagram if the person can explain an architecture or algorithm to you without it? Is a programmer who can explain how the code works without a diagram really "too good for anyone else?" After all, ultimately a flow chart or diagram is just a tool we use to communicate with each other. There are other ways of communicating ideas.

1

Share this post


Link to post
Share on other sites


There is something called the Technical Design Specification. It is a book, created by the designers and in part, the developers of the SDLC. It encompasses just about every diagram you can think of:

 

I cannot seem to find the book with that title.

1

Share this post


Link to post
Share on other sites

I didn't read the entire thread, so its maybe been said or alluded to in so many words, but here's the way I think about and approach planning:

 

In general, planning stages shouldn't think about code at all -- Never have I sat down to bang out a new project with even a single preconceived line of code at the ready.

 

Planning isn't about capturing the code -- code is just an expression of the responsibilities, relationships, rules, and requirements of the project at hand, and therefore your planning should attempt to capture those four Rs and to explore them until you are satisfied that you have a reasonable idea of how to put them together in a way that achieves your intent. Sorting those out identifies the data structures and algorithms that are necessary for expressing that intent, and the code itself follows from there.

 

Aside from that, one of the difficulties neophyte developers seem to have is an unwillingness to throw away design or code when its outlived its usefulness. Throwing away such things isn't a sign of failure, just of an evolving solution to a potentially-evolving problem. The code must evolve to keep up, and sometimes in the course of evolution nature and programmers alike reach a dead-end. When that happens, the old solutions fall by the wayside and newer, better, stronger ones take their place. Its as natural as it is effective.

 

Don't be afraid to simply explore programming challenges in isolation -- no one ever said all the code you ever write had to find its way into a product. Ruthlessly prototype, iterate, and throw code away until you understand those challenges before trying to fit them all together.

 

No detailed plan survives contact with the real world. You can only plan for the level of detail you can reasonably anticipate.

Edited by Ravyne
0

Share this post


Link to post
Share on other sites

Against most of wat was said above (probably, for what I can gather since I didn't read it all), none at all.

In my experience, in order to do things right, you must first do them wrong, at least one time.

The first thing a GAME programmer should do (this most likely does not apply to other more structured programming tasks) is to make a working prototype.

On one hand the designers need to have a working prototype to test their ideas as soon as possible, they may not want it, they may not ask for it, they may even refuse to use it after you made it, but you should do it just the same.

Why? because before you can design anything thoroughly, you must understand its deepest inner workings, and you can't just sit and think for hours until you got it all in your head, make drawings and write and re-write designs until its just perfect. You are gonna forget something. And even if you do get a clear design that looks good on paper, you still don't have any empirical evidence to support your theories and most likely at some point someone is going to want you to change it, maybe even yourself.

 

So make prototypes, the best way to understand everything involved in the inner workings of a system is to implement said system.

Once you got it working, make note of its flaws, its dependancies, profile it, and then go to the design process with all that knowledge that no amount of thinking can magically conjure up.

 

If you are asked to implement an input reading system and you have done so before, design might come easy to you, but then they tell you "it has to work on touch screens", and you never done that before, go do it, understand its needs before trying to apply your known designs to it, once its working you'll know if it fits your designs or you need to adapt them and how. If you've implemented Character control many times before, but you are asked to do so in Unity, which you never used, go make it work first.

Go for quick and dirty and just get it working, you'll have something to show for and you'll be able to make better estimations when asked to.

I've banged my head against the wall trying to come up with designs that foresee any need of a system many times before, I've always understood it much better after making it work.

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