Print

[TheRealMethuselah]

TheRealMethuselah

How to Plan out your Zelda Games...

I see this time and time again. A member gets it in his head that he's going to make a game, then just like that the ideas are gone, the game is never made... why? you may ask... PLANNING.

I'm going to take you through my planning process and maybe, just maybe it will help someone, somewhere.

First and foremost I make a Design Document. In the design document I describe in frustrating detail every minutia of what I'd like in the game. Items, Weapons, Enemies, Cheats, ad infinitum, ad nauseam.

I then collect as much information as I can from various sources, be it Zelda Fan Sites to Player's Guides.

I currently own 4 players guides for Ocarina of Time and use them on a daily basis. I also use an emulator and map out levels on graph paper (10 : 1 inch).

Before even writing one line of code, I will plan out exactly what something will look like in Photoshop, MS-Paint or whatever graphics program I'm using at the time, this way I can get coordinates and simply write them in my Design Journal (VERY IMPORTANT).

I do not use constants in the game (except for colors and environmental variables) so that if something needs to be changed by say one or two pixels I can simply change it and reload on-the-fly.

I would suggest sticking with a naming schema as well and a well thought out Folder style.

When programming, I will ALWAYS comment my code... even if I'm the only one who's going to use it... this is just good practice.



This way I can come back to my code and know where I left off, etc.

Yes, GameMaker DOES have to parse through spaces and comments, so what I do is in my RELEASE versions I will remove any extraneous blank-space and comments by creating a copy of the current .gm6 file.

Here's a good practice too... make sure you have a folder with Backups, dated. This way you can go back to a version if you should "mess" something up.

PAY ATTENTION TO DETAILS: I can't stress this enough. Remember, these are Zelda Fans, they will catch the smallest problem and blow it up to gargantuan proportions

I'll think of more later.

[Piers]

Piers

Re: How to Plan out your Zelda Games...

Good you've followed PPPPP (Proper Planing Prevents Poor Performence) perfectly. Pretty good guide but I really don't understand why you coment your code. I don't think I've ever done that example or not.

[TheRealMethuselah]

TheRealMethuselah

Re: How to Plan out your Zelda Games...

I've worked for large corporations doing business programming and it's just a good practice to follow (especially now that I'm in the Army and need to come back to a program after a few weeks or months).

[AoDC]

AoDC

Re: How to Plan out your Zelda Games...

You should see my Oracle of Life journal. Its full of ideas... old and new

I though, do not comment my code unless it is something that will kill me. I write my code out in theory, and then put it onto the PC.

No matter how many times I see your screenshots of your personal work, I am always surprised to see how professional you are

the a o d c

[therabidwombat]

therabidwombat

Re: How to Plan out your Zelda Games...

Good you've followed PPPPP (Proper Planing Prevents Poor Performence) perfectly. Pretty good guide but I really don't understand why you coment your code. I don't think I've ever done that example or not.

Commenting is a life saver...especially when you get to more advanced stuff. (and btw, you can get to 'more advanced stuff in GML). Once you are using logic that is not immediately obvious, or a lot of variables, it is good to have a lot of comments to keep track of, in english, what is going on. I tend to comment essentially every line of code...literally. I comment obsessively, almost. My code is almost more english than C++, because of the amount of comments I put in. And I never have any problem trying to figure out what my code does when I come back weeks or months later.

The planning thing is also very important. Before you have your first line of code, you should have some idea how every tiny detail ties in with everything else. You should have your entire game structure mapped out in your mind before you start coding it.

TRM, this is a very good guide. There's some stuff in here that's more aimed at game designers/level designers (like your coordinate stuff), but at the same time, this is a great resource for everyone. If some people start following it, we may get some good games done here sometime.

• 

[Scooternew]

Scooternew

Re: How to Plan out your Zelda Games...

I do something, not so extreme though. Your ideas are good, but people aren't going to need as many sources of information if they are creating custom games/ideas, because a lot of the information you get is already created, and you are just gathering it (since it is a fan game, it is a recreationg of something that was already made). Even so, I'm glad this method works for you - as long as someone finds something that works. I plan out stuff in Microsoft Word, rather than writing ideas down in real life. Unfortunately, I'm a horrible spriter, but I'd like to (sometime) teach myself how to sprite.

[AoDC]

AoDC

Re: How to Plan out your Zelda Games...

Good you've followed PPPPP (Proper Planing Prevents Poor Performence) perfectly. Pretty good guide but I really don't understand why you coment your code. I don't think I've ever done that example or not.

Commenting is a life saver...especially when you get to more advanced stuff. (and btw, you can get to 'more advanced stuff in GML). Once you are using logic that is not immediately obvious, or a lot of variables, it is good to have a lot of comments to keep track of, in english, what is going on. I tend to comment essentially every line of code...literally. I comment obsessively, almost. My code is almost more english than C++, because of the amount of comments I put in. And I never have any problem trying to figure out what my code does when I come back weeks or months later.

The planning thing is also very important. Before you have your first line of code, you should have some idea how every tiny detail ties in with everything else. You should have your entire game structure mapped out in your mind before you start coding it.

TRM, this is a very good guide. There's some stuff in here that's more aimed at game designers/level designers (like your coordinate stuff), but at the same time, this is a great resource for everyone. If some people start following it, we may get some good games done here sometime.

If I've spent hours writing it out, and put it onto PC, I obviously know each part. Why bother :/

the a o d c

[Pedlya]

Pedlya

Re: How to Plan out your Zelda Games...

This is very helpful...thx dan

So what! I wanna get out! 'Cos there's so much out there! So many different people, living different lives! Incredibly good guys, bad guys... Folks completely different from us! It's one huge melting pot! See, it's not about success, dying in the streets, who's better, who's not! I just want to be a part of it! I realized that even if I've no connections, no talent, even if I'm one big loser, I want to use my hands and feet to think and move, to shape my own life! We can just die here or we can try, see what we've got!

[Hyperhal]

Hyperhal

Re: How to Plan out your Zelda Games...

The development book thingy is what I did for my HM game >_>

I guess I should start visiting this website again. ._.

[Infinitus]

Infinitus

Re: How to Plan out your Zelda Games...

Yep this is the most vital stage of game development.

And just because im so nice heres somethingto help you, its a design document from a professional game called Claw that i was studing.

http://www.binaryphoenix.com/uploads/misc/Claw_Design_Doc.doc

That should give you an idea of what you need for a good game design doc.

[tippz]

tippz

Re: How to Plan out your Zelda Games...

Good you've followed PPPPP (Proper Planing Prevents Poor Performence) perfectly. Pretty good guide but I really don't understand why you coment your code. I don't think I've ever done that example or not.

Commenting is a life saver...especially when you get to more advanced stuff. (and btw, you can get to 'more advanced stuff in GML). Once you are using logic that is not immediately obvious, or a lot of variables, it is good to have a lot of comments to keep track of, in english, what is going on. I tend to comment essentially every line of code...literally. I comment obsessively, almost. My code is almost more english than C++, because of the amount of comments I put in. And I never have any problem trying to figure out what my code does when I come back weeks or months later.

The planning thing is also very important. Before you have your first line of code, you should have some idea how every tiny detail ties in with everything else. You should have your entire game structure mapped out in your mind before you start coding it.

TRM, this is a very good guide. There's some stuff in here that's more aimed at game designers/level designers (like your coordinate stuff), but at the same time, this is a great resource for everyone. If some people start following it, we may get some good games done here sometime.

If I've spent hours writing it out, and put it onto PC, I obviously know each part. Why bother :/

You know every part now, but I find when I'm coding that when you move off to do something else then come back it becomes pretty hard to figure out exactly what you were trying to do. Not saying it is necessary to comment every line, but a general comment saying what something does or how it does it is a good idea... that is why I bother, lol

[pxl_moon (dotyue)]

pxl_moon (dotyue)

Re: How to Plan out your Zelda Games...

@topictitle:

1. having an idea
2. putting together informations ( places, charakters, weapons... )
3. gfx design and first level
4. gameplay
5. i dindt come further xD
6. ehm... rest?

~~Resources~~
~Minish Cap Style~
Minish Cap Beta:Firerod Icon, Majoras Mask:ChuChu, Ocarina of Time:Gossip Stone, Oracle Series:Link plays the "Herpes of Ages", Impa, Wand Maker: HUD
~GB-Zelda Style~
Ocarina of Time: Deku Caca
~Other~
Paper Mario Style Zelda&Link, Tetra Trackers HUD-Cleanups

[JohnGames]

JohnGames

Re: How to Plan out your Zelda Games...

I comment with the idea of "If I came back after a year, would I know what I was doing?"

I do NOT comment apparent things (unless they go past 10+ lines, I give them one comment)

[Krynn]

Krynn

Re: How to Plan out your Zelda Games...

Thank You! This is really helpful. I think I will actually be able to properly plan my game this way, if I follow your model!

[Kren]

Kren

Re: How to Plan out your Zelda Games...

Woah, thats really helpful, but you forgot to add time limits, like you need to finish certain sprite for X date so the team finish the game on time.

Also, if someone doesn't do the sprite or the code on time fire him, that way he will see that you take the project really serious, because later on he will never complete the task you assigned him.
.

[Krynn]

Krynn

Re: How to Plan out your Zelda Games...

Woah, thats really helpful, but you forgot to add time limits, like you need to finish certain sprite for X date so the team finish the game on time.

Also, if someone doesn't do the sprite or the code on time fire him, that way he will see that you take the project really serious, because later on he will never complete the task you assigned him.
.

Fire him? At first? I say give him two strikes, then hes out.

[Kren]

Kren

Re: How to Plan out your Zelda Games...

Woah, thats really helpful, but you forgot to add time limits, like you need to finish certain sprite for X date so the team finish the game on time.

Also, if someone doesn't do the sprite or the code on time fire him, that way he will see that you take the project really serious, because later on he will never complete the task you assigned him.
.

Fire him? At first? I say give him two strikes, then hes out.

That depends on the people and how they act..
also i found this on another forum DONT think i write it..

he first little goblin is one I like to call "we don't need a contract." This is the first
and most fatal mistake for most development teams.It doesn't matter if you're on a team
 full of people who have known eachother since the first grade, you need a contract.
 You need to establish what happens if someone decides to leave. Do not leave any legal holes
 for the project to be destroyed if someone loses their temper. This happens time and time again
 with small projects. Get rid of the "we don't need a contract" goblin immediately and burn this phrase
into your head: "verbal agreements rarely hold up in court."  Yes, you did read  that correctly, it doesn't
 matter what was said out loud. You need to have the game protected on paper. If everyone on the team
 truly cares about completing the project and not just about their own interests, they will see that a
contract is the best way to go. The signature of every person working on the project needs to be on a
contract and the company owner should have them safely stowed away in a fire protected safe or box
 (many department stores sell them.) Do not go past the "concept" stage until this is complete.

Here are some things you may want to include in the contract:

-The "company"  or "group" owns all pieces of work made for the game, no exceptions.
-If someone dissappears for weeks on end without any attempt to contact the project leader
and/or company owner they give up their position and all rights to their work for the game automatically

If someone on your team refuses to sign a contract, get rid of them immediately.
Thats a hint right there that something could go wrong further down the road. You may
even see these little guys pop up in a heated argument:

"Its mine because I made it!"
" I never signed anything!"
"You can't tell me what to do, nobody owns it!"

Game design is very stressful and you're going to see a side of people that
you may not have seen before. This makes contracts all the more important.
If a person is not willing to agree to a reasonable contract when they are calm, what do you
think they are capable of when angry? Deleting or leaking the source? Putting something offensive
 on your group/company's web page? You bet. The more power someone has, the more papers need
 to be signed to prevent them from abusing that power.


The next nasty little goblin often comes out of the programming department and goes
something like this "We don't need source control, there are only x number of us." Big mistake.
This one will get you into trouble especially if one programmer leaves abruptly and you need to
 replace them or you only had one programmer to begin with.  Have your programming team
setup a system where you can revert to any version of the game at any time simply by recompiling
 that version. Get the programmers in the habit of documenting everything. It is very important that
 you do so.

From the depths of good intent rises our next little bundle of  green joy, "We're all friends here,
 we don't need a leader." Chances are on your team there is a person who wrote the majority of
the design documents (which of course you better make sure you have) and/or wrote the original
 concept of the game. This person is key to keeping the "dream" of the game intact. They should
 probably be the project leader. Gather your team members together and elect the person you all
think is most likely to not try to change the game for their own reasons. In many cases  this person
 will be the one who gathered up the team to begin with (and in the case of a company, the company
 founder if it is the first project.) The company owner may however want to elect someone else.
 If you don't agree with the choice, voice your opinion early. You don't need to get nasty, you
don't need to get mean, just make sure you speak to the person who appointed them and say
 why you don't think its a good idea. A "board" of people can also work but it may often end
 up in stalemates and/or disagreements among members especially if personal ideals get in the
 way of the original concept of the game.

  Most people will probably ignore this one out of all of the goblins. This may be because they do not see
 the value in having a leader. I can't even count the amount of stalemates I was in during the course of
 Illutia because of the way the "power" was setup. Stalemates slow progress, they slow it to a point where
 compromises  are going to be made that hurt the game rather than help it.  In my experience, more gets
 done and the game is more likely to stay on track if one person is in charge of making sure the dream of the
 game is kept intact. Co-leadership or having a "board" of leaders only works if everyone's interest is in the game
 concept that was created, not their own.  If you're working over the internet the chances of everyone being on
 the same page at all times are very slim (especially  if you ignore another little goblin that I'll describe later on.)
I'd honestly suggest having every staff member work out their own game idea (on their own time) so that once you
r initial project is done you can work on someone else's idea and have them be the project leader for their own idea.
 This gives everyone the hope of being able to be project leader if they finish  the current project and should encourage
them to listen to others when its their "turn" to be project leader. I know this sounds like a very elementary school
solution but you don't always know the maturity of the people you're dealing with, and most people have the dream
of being in control of their own game in this industry.


 Now we arrive at the gruesome twosome. These need to be avoided at all costs even if it means getting
 rid of someone."Keep x artist happy at least until they finish" and "keep x programmer happy until they finish."
 No one team member should be valued over everyone else based on their "talents." You may be equipped
with the best artist and  the best programmer in the world but if they have an attitude problem and keep
 pushing for control of more and more, they just aren't worth it. If the programmer or artist refuses to follow
 the plans that everyone else has to follow, and the rest of the team is keeping them happy in hopes they'll listen,
 your team is in trouble. They know you're going to appease them no matter what, they're never  going to listen.
 If you're the project leader, put your foot down early. Here are some warning situations that might arise over time:

Project leader: "We need to get x feature done."
Programmer: "I don't want to work on that, I want to work on this system."
Project leader: "We don't need that system yet, we need this feature."
Programmer: "If you push me, its not going to make me work any harder."

(If any team member is "threatening" you so they can do what they want, get rid of them immediately.
 Never give someone power enough to be able to stay and do as they wish
especially with something as important as the programming of the game.)


Project leader:" I need a "wild beast" as soon as possible."
Artist: "I'm working on goblins right now..I'll get to it when I can."
Project leader: "Please work on the wild beast for now. Its needed more."
Artist: "You can't make me drop a project in the middle to work on something else
You asked for my help and I'm giving it to you, but some things need to be done my way."

(Make sure you're being assertive with your team members, if they can't give a valid reason why
  they can't work on something else then they should not argue. Beware of people who have a
"card" they play from their hand often.)


 Please Do not get me wrong here, sometimes there are very good reasons to assert that something
 else needs to be done first to your project leader. The leader of the project should not be able to do
whatever  they please, or treat anyone however they please,  just because they are the leader (unless
of course they own the company too, in which case you're screwed.) If you can't assert yourself in a
reasonable way without being punished then its probably best you leave the project and/or find another
 one. Hold meetings regularly and make sure everyone voices their opinions as early as possible. Holding in
 your feelings about a particular way the project is going is only going to build resentment.


 The final goblin I wish to cover at this time is " I'm very busy, I don't have time to keep myself up to date."
WARNING: This person is probably lazy.  If they expect another team member to be their "secretary" all
 the time because they do not feel like reading through the documentation, posting on the team forums
 and/or going to meetings, this person could cause problems later down the road. If they care fully about seeing this
 game through to the end, they will be very interested in joining with other team members to discuss the project
. It is very rare that someone is going to post fifty pages of documentation and updates every day for other
members to read, they can take time out of their day and keep themselves up to date as it will increase everyones
 productivity for them to do so. If they believe that keeping themselves informed is a waste of time,
 they are a waste of time.I know people who work their butts off day in and day out and still
come home and read the newspaper or turn on the news, why? They want to know what is going on in the
 world around them. Even though they have a lot to do they know its important to keep up to speed with their
 community and the rest of the world.

Every team member has something important to say, sometimes goblins will appear when they do,
everyone needs to be right there to squash it when it happens. Pay attention and address issues
when they come up. If you are all good friends working on a project together, remember this phrase
 if nothing else; " True friends wouldn't want you to suffer for their actions, even if you weren't friends anymore."


For everyones sake, slay the goblins.


-Faeryshivers

Thats also helpful >.<

[Krynn]

Krynn

Re: How to Plan out your Zelda Games...

Phew.. done reading that. Thats actually really helpful. Considering TRW's and Faeryshivers I think i'm ready to actually get somewhere with my game

[Vandavil]

Vandavil

Re: How to Plan out your Zelda Games...

I agree. I use microsoft powerpoint to make the document. that way you are more organinzed. :tek:

[Dejay]

Dejay

Re: How to Plan out your Zelda Games...

Nice guide, I've really got to start planning stuff more often, instead of rushing into it. :lol: