Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


How does your Pseudocode look?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#1 Tutorial Doctor   Members   -  Reputation: 1811

Like
0Likes
Like

Posted 08 March 2014 - 12:56 PM

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. 

 


They call me the Tutorial Doctor.


Sponsor:

#2 Aardvajk   Crossbones+   -  Reputation: 7717

Like
4Likes
Like

Posted 08 March 2014 - 01:27 PM

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.



#3 Tutorial Doctor   Members   -  Reputation: 1811

Like
0Likes
Like

Posted 08 March 2014 - 02:07 PM

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, 08 March 2014 - 02:07 PM.

They call me the Tutorial Doctor.


#4 Servant of the Lord   Crossbones+   -  Reputation: 22758

Like
4Likes
Like

Posted 08 March 2014 - 02:22 PM

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.

 

For complex functions, I sometimes add comments to help me figure out the structure flow:

bool LoadConfigFile(const std::string &filepath)
{
     //Try to load the file.
 
     //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.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#5 Tutorial Doctor   Members   -  Reputation: 1811

Like
0Likes
Like

Posted 08 March 2014 - 03:27 PM

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


They call me the Tutorial Doctor.


#6 warnexus   Prime Members   -  Reputation: 1531

Like
3Likes
Like

Posted 08 March 2014 - 03:51 PM

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, 08 March 2014 - 03:53 PM.


#7 Nypyren   Crossbones+   -  Reputation: 5544

Like
0Likes
Like

Posted 08 March 2014 - 03:59 PM

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).

#8 Madhed   Crossbones+   -  Reputation: 3348

Like
0Likes
Like

Posted 08 March 2014 - 04:15 PM

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.



#9 NightCreature83   Crossbones+   -  Reputation: 3288

Like
1Likes
Like

Posted 08 March 2014 - 04:41 PM

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


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#10 Álvaro   Crossbones+   -  Reputation: 14634

Like
3Likes
Like

Posted 08 March 2014 - 04:45 PM

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.

#11 Tutorial Doctor   Members   -  Reputation: 1811

Like
0Likes
Like

Posted 08 March 2014 - 06:26 PM

Great variation of approaches. Looks like I am going to stick to the PDL design, which seems to be the common factor of the posts here, for most of my projects. I am sure there are times when I will do something like you NightCreature, especially if I happen to be doing some type of program for a robot or something. Thanks again! I am going to go and practice PDL to see how quickly I can get something done using that method. 


They call me the Tutorial Doctor.


#12 Tutorial Doctor   Members   -  Reputation: 1811

Like
4Likes
Like

Posted 08 March 2014 - 06:33 PM

Oh Yeah! This is going to do just fine. 

--while a key is pressed, start the character walking. When the key is released, stop walking. 
-- walking is playing an animation while translating the character. "Stop walking" should not only stop the animation, but set the animation to it's first frame one the walk animation has finished.
--Use two booleans to turn walking on and off. If walking is on, thhe walking function plays. If walking is off, the walking function stops. 

walking = false
idling = true

function walk(character,speed) --character and speed not added yet.
	if onKeyDown(key) and idling then
		walking = true
		idling = false
		playAnimation(walk_animation)
	else if onKeyUP(key) and walking then
		idling = true
		walking = false
		playAnimation(idling_animation)
	end
end



--Game Loop
function onSceneUpdate()
	walk(joe,2)-- joe walks at 2 units per second/frame.
end

--Turn a light on when a button is pressed:
 
--if a key is pressed down, turn on a light and play a sound. When it is released, the light should be on still, and another sound should play. 
 
 
if isKeyPressed(key) then
    turnOnLight(light) --sets a light variable to true and turns a gameObject light brighteness to 100%
    playSound(sound) --plays a sound
end
 
if isKeyReleased(key)
    playSound(sound2) --plays a sound
end

Edited by Tutorial Doctor, 08 March 2014 - 06:54 PM.

They call me the Tutorial Doctor.


#13 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 10 March 2014 - 03:50 PM

Oh Yeah! This is going to do just fine. 

--while a key is pressed, start the character walking. When the key is released, stop walking. 
-- walking is playing an animation while translating the character. "Stop walking" should not only stop the animation, but set the animation to it's first frame one the walk animation has finished.
--Use two booleans to turn walking on and off. If walking is on, thhe walking function plays. If walking is off, the walking function stops. 

walking = false
idling = true

function walk(character,speed) --character and speed not added yet.
	if onKeyDown(key) and idling then
		walking = true
		idling = false
		playAnimation(walk_animation)
	else if onKeyUP(key) and walking then
		idling = true
		walking = false
		playAnimation(idling_animation)
	end
end



--Game Loop
function onSceneUpdate()
	walk(joe,2)-- joe walks at 2 units per second/frame.
end

--Turn a light on when a button is pressed:
 
--if a key is pressed down, turn on a light and play a sound. When it is released, the light should be on still, and another sound should play. 
 
 
if isKeyPressed(key) then
    turnOnLight(light) --sets a light variable to true and turns a gameObject light brighteness to 100%
    playSound(sound) --plays a sound
end
 
if isKeyReleased(key)
    playSound(sound2) --plays a sound
end
Wow. When did you start learning C++?

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#14 Lactose!   GDNet+   -  Reputation: 4438

Like
5Likes
Like

Posted 10 March 2014 - 06:14 PM


Wow. When did you start learning C++?

Assuming the first part of each snippet is the pseudo-code, followed by the proper implementation, the stuff you quoted is not C++:

- Comments in C++ do not start with "--", they start with "//" (or "/*" ended with "*/").

- Expressions in C++ end with a ";".

- When declaring variables, you need to include the data type (in this case, most likely "bool" before "walking" and "idling").

- Function definitions in C++ do not start with the word "function". They start with the return type of the function (e.g. "void", "int", "float"). "function" could be a badly named data type, but the function doesn't return anything, so it isn't.

- Function definitions in C++ include the data type before the parameter. 

- Functions and if statements in C++ do not end with "end". Scope is indicated by "{" and "}".

- If statements with multiple conditionals do not use "and" as a keyword. In this case, "&&" would be the correct operator.

- If statements do not have a "then" in them to signify start of block.

- If statements with multiple expressions in C++ are scoped using the "{" and "}". Failure to do so can lead to stuff like the "goto fail" Apple bug that was recently discovered.

 

There are potential other issues as well, but for the sake of this reply I'm assuming those things were done correctly outside of the code snippet in a C++ scenario.

---

EDIT: On-topic: I tend to do the same as Servant.


Edited by Lactose!, 10 March 2014 - 06:24 PM.

Project journal, check it out!

http://www.gamedev.net/blog/1830-lactoses-journal/

 

Hello to all my stalkers.


#15 Aurioch   Crossbones+   -  Reputation: 1304

Like
2Likes
Like

Posted 10 March 2014 - 06:19 PM

Pseudocode? What's that? XD

 

I have two approaches:

1) When explaining to others, I usually write short amounts of code, cutting out any unnecessarry stuff with "// snip" line (or replacing them with arbitrary methods), similar to what Servant does.

2) When doing it for myself, I write it mostly from head; when dealing with a complex problem, I usually take pencil and paper and sketch what it has to do, simulate algorithm behavior or some other things without writing any (pseudo)code,  depending on the simulation. For example, if I need to simulate cannon fire, I'd sketch the path of cannon fire and write formulas for sling etc., then try to implement that in the code.


Edited by Aurioch, 10 March 2014 - 06:20 PM.


#16 King Mir   Members   -  Reputation: 2067

Like
1Likes
Like

Posted 10 March 2014 - 10:30 PM

IMO it doesn't make sense to write psudocode in most cases. I might use a UML diagram to design objects and their responsibility, but for functions the approach is different. I just write out set by step, what the function does in actual function calls and control flow. Then for each function call I stub out the definition. Then you fill in each function so created by the same process, possibly adding parameters as needed.

So using Servant of the Lord's example, a first pass would look something like this
bool LoadConfigFile(std::vector<result> &results, const std::string &filepath){
     auto file = load_file(filepath);
     if(!file) {
           log_error("Could not open file");
           return false;
     }
     while (auto line = read_line(file) ){
           if(line_is_comment(line) ) 
               continue;
           auto var_name = get_var_name(line);
           auto var_value = get_var_value();            
           results.emplace_back({var_name, var_value});           
     }  
     return true;
}
Notice that that function a nice and short 13 lines. That's about as short as I try to make my functions. About 20 lines is the cutoff for when I'd think about splitting code out into another function. So if say, the while loop became too busy and long, I'd try to replace the while body with just a function or close to it.

#17 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 10 March 2014 - 11:26 PM

Wow. When did you start learning C++?

Assuming the first part of each snippet is the pseudo-code, followed by the proper implementation, the stuff you quoted is not C++:
- Comments in C++ do not start with "--", they start with "//" (or "/*" ended with "*/").
- Expressions in C++ end with a ";".
- When declaring variables, you need to include the data type (in this case, most likely "bool" before "walking" and "idling").
- Function definitions in C++ do not start with the word "function". They start with the return type of the function (e.g. "void", "int", "float"). "function" could be a badly named data type, but the function doesn't return anything, so it isn't.
- Function definitions in C++ include the data type before the parameter. 
- Functions and if statements in C++ do not end with "end". Scope is indicated by "{" and "}".
- If statements with multiple conditionals do not use "and" as a keyword. In this case, "&&" would be the correct operator.
- If statements do not have a "then" in them to signify start of block.
- If statements with multiple expressions in C++ are scoped using the "{" and "}". Failure to do so can lead to stuff like the "goto fail" Apple bug that was recently discovered.
 
There are potential other issues as well, but for the sake of this reply I'm assuming those things were done correctly outside of the code snippet in a C++ scenario.
---
EDIT: On-topic: I tend to do the same as Servant.
I knew it wasn't c++ but it was good pseudocode

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#18 Ectara   Crossbones+   -  Reputation: 3088

Like
1Likes
Like

Posted 10 March 2014 - 11:29 PM

My pseudocode is always a fuzzy C++, with some inaccuracies to allow laziness in expressing thoughts.

 

To be honest, I hate pseudocode. When writing pseudocode, I find that I have to revise my ad-hoc grammar repeatedly to allow the rest of the pseudocode to make any sense at all. At the end, I've about made a new language, and it was no simpler. I may as well basically use an existing language as a basis; after all, my usual goal of pseudocode is not to pass through pseudolint, but to quickly prototype and explain ideas to others, where the reader can fill in blanks.

 

So, for me, I write in fuzzy, untested C++. In communicating with others, a fuzzy C. Who doesn't know C?


Edited by Ectara, 10 March 2014 - 11:30 PM.


#19 EricsonWillians   Members   -  Reputation: 288

Like
1Likes
Like

Posted 11 March 2014 - 11:27 AM

My pseudocode looks like Python, because Python looks like pseudocode anyway haha (I'm serious).


Creator and only composer at Poisone Wein and Übelkraft dark musical projects:

 


#20 samgj   Members   -  Reputation: 399

Like
0Likes
Like

Posted 11 March 2014 - 06:55 PM

I'll do hand drawn flow charts if the program is very complex, but I usually don't do pseudocode. I just write it in a real programing language with some dummy methods for things that aren't clear.


MLNM-ONE: open source video game engine

Unincorporated Media's Website: my company's website





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS