# How does your Pseudocode look?

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

## Recommended Posts

Okay, so I have to look for ways to do stuff fast since I am a lone developer who is new to all of this stuff. So far I know I can get a working game going, my only hangups are quality animation and the time it takes to code and debug the code. So, I am trying to speed up my coding skills (not focusing on optimization) so that I can get an idea up and going.

I have found that the best way to start out the coding process is by:

1) Thinking about what you want to do

3) Write pseudocode for what you want to do
2) Determining the PROGRAMMING COUNTERPARTS. For example, the programming counterpart to jumping is adding a force in the up direction).
3) Figuring out how the API does it
4) Fill in the pseudocode with the API stuff.

So, say I wanted to make a character jump simply by typing the name of the character, and the word "jump."

man.Jump()


This is how I would want it to work. So it seems I need a class and a function that adds a force in the up direction when it is called.

Another example:

cut_scene.Begin()
cut_scene.End()


I need a function that starts video playback and another that stops it. Etc. Perhaps the cut_scene part would be a class or something?

So, how do you do your pseudocode? Or do you even use pseudocode? I just want some ideas on how others do it.

##### Share on other sites

I only write pseudocode if I'm trying to explain something on a forum post. I tend to just write real code personally. If I'm working on something really complex I'll sometimes add dummy methods that I fill in later on so I can get the overall structure together, similar to what you describe - I might write an empty jump() method that I'll implement later once I've got it being called in a context.

Some other people might prefer to plan their whole code out with psuedo code I guess. If you aren't too comfortable with the language you are using then I can see how that might be useful, but if you're comfortable with the language its no more effort to sketch out the structure in the language than in pseudocode.

There is certainly no standard approach here.

##### Share on other sites

Haha, you always have good keywords. I guess the idea I am thinking of is a "sketch." Yeah, just like when you draw you sketch out the idea, and from there it is easier to get a feel of the thing as a whole.

It isn't really the programming langauge that gets me as much as it is the API I might be using.

Edited by Tutorial Doctor

##### Share on other sites

I only write pseudocode if I'm trying to explain something on a forum post. I tend to just write real code personally.

Same with me.

bool LoadConfigFile(const std::string &filepath)
{

//Make sure the file loaded properly.
if(!file)
{
//Log an error message and return.

return false;
}

//Crawl through the file line by line.
while(...)
{
//Check if it's a comment.
if(...) continue;

//Separate the variable name from the value.

//Push back the variable into the results with the value.

}

return true;
}


Not the best example - but if it was a more complex file format, this kind of commenting helps me (it especially helps me identify what parts should be separated into different functions).

I don't do this for every function, just ones that I need to think through. The process only takes about 60 seconds, and then I leave most the comments inplace as actual comments.

Here's another example, where I use the comments to separate sections of the function, rather than forming structure.

void intializeModelViews()
{
//--------------------------------------
//Create the models.

//--------------------------------------
//Create the views.

//--------------------------------------
//Attach the views to the models.

//--------------------------------------
//Hook up the view signals to the slots.

}

I tend to do this when I have alot of visually-identical code that needs to occur in a certain order. (e.g. I have four *different* views and four *different* models and they need to each connect two signals to two *different* slots...). Different enough that it doesn't make sense to wrap it into a function, but similar enough to group it together.

In this situation, I'm doing it more for the code's appearance, rather than to help me think through it.

##### Share on other sites

Great tips Servant. I like the layout of that style. I need to find a good cross between commenting and pseudocode.

##### Share on other sites

My experience coding the program has always been a bottom up design approach, creating each implementation one by one until it works but not having an entire understanding of how the whole code structure.

Seeing this thread makes me want to go for the top down design approach which is better because using that approach means you have a better understanding of the entire coding structure but not how to create the implementation.

If it is something more complicated like getting a collision to work, I would draw some coordinates and test my code on paper. It usually helps to have a visual aid because it gives me something to work off of and getting my creative juice flowing. Even working on 5 small games, everytime you are doing something new, it will always take longer than you think.

Comments do help to remind me which part of the code needs fixing and why I code it this way rather than saying this is how the code works.

Edited by warnexus

##### Share on other sites
I do is sort of like what servant does: Start with stubbed code, write comments to describe the steps, then implement each step using real code. The original comments are kept (except when the code is trivial).

##### Share on other sites

I often use something called Program Design Language. There is even a very old article on this site: http://www.gamedev.net/page/resources/_/technical/general-programming/using-pdl-for-code-design-and-documentation-r1384

Basic you start writing your program as high-level non technical comments and fill in the details afterwards. You end up with well documented code.

##### Share on other sites

Mine mostly looks like decision diagrams so that it is easy to translate in to real code, or it just takes the shape of english text. When it is code time it is time to write it in a language :)

##### Share on other sites
I sometimes write down the name of a function and a breakdown of the task into steps, described in English. If I do it on the computer, these descriptions might end up being comments. But I often do this on paper, as a tool to put my thoughts in order, or to convince myself that a certain approach will work. When things are clear in my head, I throw the piece of paper away and get on with coding.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 20
• 20
• 11
• 9