Hi, I’m planning on doing a big project next but I kind of want to pseudo code the whole game in notepad or something before I start it. I’m still pretty new at programming, I plan on pseudo coding the whole game while I review C#. Does anyone know any websites that give some basic rules for the best way to write out pseudo code implementation docs on your game. I would like to follow some guidelines, and see how other people pseudo code their games because I’m just making up my own way as I go. I would like to convert all the pseudo code into a GDD eventually for whoever I work with also. Then finally start implementing each script. What are your workflows?
I plan on just picturing each feature of my game in my head and writing it down.
I don’t know of anyone who actually works like this.
If I have a complex code task to engineer I’ll often start writing out the steps as code comments in the script then use that as a kind of boiler plate to write the real code around it, but it’s not pseudo code, more just plain English comments explaining what I’m doing and why. It’s kind of like reverse rubber duck debugging.
I find working this way my scripts are always well commented, and if I ever make a functional change to them the I feel compelled to update the comments to match. For working with teams, using a rubber-duck philosophy to write code comments is a godsend.
Design Documents shouldn’t contain code, for them (at least in the indie space) you should be focusing on screen mock-ups and a more philosophical voice about the design and goals of the game. The science is in the code and should stay there IMO.
Well I didn’t plan out my last project and it took so long. I’m just thinking of trying this and I’ve heard a lot of programmers pseudo code.
Planning is different, and knowing how long something will take just comes with experience. If you’re new to game development I’d recommend setting yourself challenges like a game in a week, a weekend ect. Join 48H game comp teams and stuff. Game development is like anything else, the more you do it the better you get, just don’t get stuck doing one small part of it forever or you’ll never really learn much.
Focusing on finishing small projects will teach you sooooo much more than spending time worrying about how to plan large ones.
In my opinion it would be a little silly to do it this way
Especially since you say you are new to it all
Notepad will never tell you or even know if you made an error besides there being a few things I did wrong that Visual Studio didn’t even notice but Unity did
Just my opinion not a put down at all
I agree to a certain degree with the previous post…
While new, its probably more helpful to aim for small projects. IE carpenters don’t start out building houses, they usually build tables and chairs first.
Almost all games that break AAA status started with a Game Design Doc. Usually the GDD is split into 2 sections, 1 describing every detail of the game and another describing the technical side of things. The tech doc (second half) usually consist of the major systems in place to control the game and often include flow charts for sequences of events in the game. Some even detail a systems entire API and will rate the risk vs. success of the feature it’s aiming to implement and its difficulty level for a programmer.
From what i’ve seen for the unity side of things, the tech doc is skipped completely and only a design doc is made.
When i start planning out something, i first create an ABC list of features
A features must make it in first and be working well.
B features are made if all A features are in and working.
C features are “Wouldn’t it be cool if…” and i normally don’t have time to meet those, but i want them documented anyway.
From there i create a design doc of it.
Here’s a design doc (first half) template i pulled from somewhere on the net, though i can’t remember now, i just can’t take credit for it:
-
Name of the Game
-
Design History
-
Game Overview
-
Philisophy
-
Point #1
-
Point #2
-
Common Questions
-
What is the game
-
why create thyis game?
-
where does the game take place?
-
what do I (the player) control?
-
How many characters do i control?
-
What is the main focus?
-
Whats different?
-
Feature Set
-
General Features
-
Multiplayer Features
-
Editor
-
Gameplay
-
The Game World
-
Overview
-
World feature #1
-
World Feature #2
-
The Physical World
-
Overview
-
Key Locations
-
Travel
-
Scale
-
Objects
-
Weather
-
Day and Night
-
Time
-
Rendering System
-
overview
-
2d/3D rendering
-
Camera
-
Overview
-
Camera Detail #1
-
Camera Detail #2
-
Game Engine
-
Overview
-
Game Engine Detail #1
-
Water
-
Collision
-
Lighting Models
-
Overview
-
Detail
-
World Layout
-
Overview
-
World layout detail #1
-
Game Characters
-
Overview
-
Creating a character
-
Enemies and Monsters
-
User Interface
-
Overview
-
Detail #1
-
Detail #2
-
Weapons
-
Overview
-
Weapon detail #1
-
Musical scores and sound effects
-
Overview
-
Red Book audio
-
3D Sound
-
Sound Design
-
Single-Player Game
-
Overview
-
Game Detail #1
-
Story
-
Hours of Gameplay
-
Victory Conditions
-
Multiplayer Game
-
Overview
-
Max Players
-
Servers
-
Customization
-
Internet
-
Gaming Sites
-
Persistence
-
Saving and Loading
-
World Editing
-
Overview
-
Detail #1
-
Extra Miscellaneous Stuff
-
Overview
-
Junk I am Working on
znoey I think I might use what you posted as a template to organize all my notes I have scattered through a zillion sheets of paper hahah
I think I misunderstood the op maybe idk
Yea i thought i would expand on this because normally there’s a GDD with a tech doc in it as the second half of the doc. That tech doc usually describes with either pseudo code or real code how features work on the code side of things. More often than not, i see these in the form of UML or universal modeling language http://en.wikipedia.org/wiki/Unified_Modeling_Language
There are various applications that can help you “pseudo” code objects in UML.
I really just thought that posting this would be more useful than saying “yes you should plan things”. I’d much rather see a design doc at the very least because then i know pretty close how to make the code end work for the design side. Also it allows you to wrote more “future-proof” code because you see that you might want this feature so system A has to accommodate for that sometime later.
When it comes to guestimating the time required for a feature my formula is this
timeItWillProbablyTake = (timeIThinkItWillTake - previouslyWrittenSystemIfExists) * 3 + timeIThinkToIntegrateIntoSystem * 2
Also, check out evernote sometime. I store all my ideas in it nowadays and its across all my phones / tablets / computers.