• Advertisement
Sign in to follow this  

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

This topic is 1439 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement

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.

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.

Share this post


Link to post
Share on other sites


This is one of those questions that should never be asked.

If a leader never ask for input, Then they never have any opinion or idea other than their own!  I think all of his questions are relative, Maybe not to me but definitely to the asker. Thus, no answer given should be taken as final, just food for thought.

  When working on any project, after the project is defined, I like to make notes on a large index card for different parts.  As with most games, you will find a core set of functions and data parameters.  What comes to mind in a roleplaying to me first are the PCs & NPCs.  Figuring out what they can and cannot do will help define some of your programming requirements ( 1 small step ). By putting these definitions onto 1 or 2 index cards you begin to develop some flow.  < At least this works for me!  You will have to find what works best for your team, this may be a "Trial & Error" type system.

  Older programming teams used to develop a "Top Down" program Flow Chart.  I find now, for me, a core design with many outflows and returns type "Road Map" presents a better representation of a program, Like the Circle of traffic flow around the "Arch de Triumph" roadway in Paris.


In a UML diagram, arrows point the wrong way.
A base class points up to the class that inherits from it.
Whose idea was this? How does this make sense in any universe? “I inherit from you, thus I take properties from you, thus the arrow should point from me down to you.”

 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 ?


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

Everyone will have strengths and weaknesses and their own ideas.  When working with a team, and leading a team, I think it would function much better as a team if everyone feels they were able to contribute to the team.  Get input and ideas from everyone.  Discuss everything.  Keep an open mind!!  Come to a consensus, Not everyone will get want they want, but if they feel that they were at least listen to, they will more likely give a better effort.  Remember, the team leader has they final say on what direction to go.

  The Team leader should also be ready to take "Full Responsibility" for anything that goes wrong, and "Share Credit" for when it goes right.

Share this post


Link to post
Share on other sites

In general, I believe confidence is the quality that you're trying to identify (not to be confused with arrogance). Confidence that what you're about to write will do what you want it to and that it will be as extensible as you need it to be. Also instilling that confidence, most likely by communications in writing (design docs, diagrams, whatever), in your co-workers and clients. It may be that confidence comes from discussing things with co-workers or clients or it might come from research, experimentation, or past experience.

 

That is not to say that confidence will necessarily generate a result that follows best practices. Of course this is also a desirable quality but I don't think it could come without the experience of writing code.

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.

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? :)

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!

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

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.

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.

Share this post


Link to post
Share on other sites

classdiagramno3d.gif

 

This means something to someone, but that someone is not me.  I have no clue what is happening here.

 

Which way the arrows actually point in a UML diagram is beside the point; I just recall them rubbing me the wrong way (or perhaps because base classes are displayed above inheriting classes, which is a fundamental violation of the idea that base classes are below their superior classes) and if a “superior” was to impose them upon me then it is exactly the same as asking me to reduce my efficiency by half.

 

We all have our own way of thinking.  That is the lesson the original poster needs to understand.

 

 

L. Spiro

Edited by L. Spiro

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.

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.

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.

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!

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.

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.

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.

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.

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

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement