absolute focus on pseudocode or not?

[+oprystar]

I have experience with C++ and VB. Although it gets redundant at times, I was taught to ALWAYS use pseudocode to plan any program or code structure. To date the projects I have worked on have always been straight forward ( A + B = C). While sketching out ideas for for a Wherigo build, I often find myself adding more and more to the original concept. We all know how large projects can get doing that. I was wondering if others use pseudocode and how they manage to stay focused on its outline. Would anybody be willing to share their pseudocode? Thank you.

-oprystar

[Ranger Fox]

For my two cartridges, I didn't write pseudocode. I've been programming close to seven years and have developed a knack for holding a system in my head, sectioning out important parts, and exploring the details. When I do write things down, it's usually a list of requirements, design drawings, or use-case diagrams. Now this is only for when I'm the lone developer; had I been on a team, I would write down a lot more and communicate up front and constantly about what everyone is responsible for doing.

 

I suppose you're asking this to see another's process. I can try to explain, then, what I do when I create a cartridge when I'm the only developer. This will be a rather broad subject and I don't have much time to write tonight, so please feel free to probe and ask questions.

 

The first thing I do is come up with an idea. What do I want to make, what is the goal, and how should it look and function to the player? The idea is to go around and earn points by performing this and this action. The goal is to earn as many points. This is what the user should see and the main gist of what it's about. By the end of this process, I should also have a grasp on the game's mechanics and rules. This is an important step and I'm a strong advocate of having a well thought-out plan and design before the first line of code is written.

 

The next step is to create a simple testing environment. For my game, I knew it would have multiple zones, but I started out with one. From there, I had a mental outline of how the zone was supposed to react and what was going to move it. I tackled the most critical show-stopper first: making a zone appear in a random place.

 

When coding, I have a sense as to what would be a major operation and what could be reusable code. If it can be reusable or sectioned out to unclutter some other important code, I make a separate method/function (I use these interchangeably) for it. I also decide up front what could be variable even if I don't allow the user to vary it or it won't be adjusted in the final game (I could always use that to tweak game settings later on). So I start with the core, important component and build that. Every time I feel a separate method would be in order, I write the method call and continue. Some times, I'll code the other method, then continue where I left off in the main code. It depends on what is involved in the other method call.

 

After I have one piece of code, the part that will move a zone to a random location, I save my code and build it in the builder. If everything opens and builds, I go back to the code and write a little more to test that functionality. For instance, when the player enters a zone, OnEnter will cause the zone to be moved to a random location.

 

After that, I code more until I reach a point where I feel I need to test my work again. Some times, I'm not confident, so I test after small additions. Other times, I feel really good and can code entire features before testing. It's the same on whatever platform I code.

 

I find the most important structure that keeps me in line is my method signatures (the function name, what goes in, and what comes out). That helps for organization and knowing what I have to work on next.

 

I'll have to stop here for the night; I ran out of time. Was this a response you were looking for? Did this help? Do you have any specific questions for anyone to answer? There's no correct way to outline development; there are a ton of methodologies floating around online. Find something that uses your strengths and helps with the way you personally think and make that your own while still keeping your mind open, as you are now, to other ways.

[+oprystar]

Thanks for the reply. I apologize for the delay in getting back to you. I went to school Summer semester with a full load and there was barely any time to come up for air. Again, my apologies. Yes, you gave me a good idea for a layout method. I also tend to program on the fly, but when in the classroom, pseudocode is required so I use it when being graded. Also pseudocode does in fact help organize the direction to the end. Your post was a big help. I will use your tips. Thanks! -oprystar

Edited July 31, 2008 by oprystar