Advertisement Jump to content
Sign in to follow this  
Nicholas Kong

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

This topic is 1805 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!