Project Management

[ZadoAsh]

Here I think it would be cool if we all posted tips on managing a project I'll post a few I quiet like to keep in mind while running a project


- Always stick to ONE project at a time, if you start jumping from project to project you'll get lost and get nothing done!

- Your coding should be carefully done and structured so you can use it for future projects making your task a hell lot easier the next time round! Make a folder somewhere on your PC like 'Code Snippets' for what code could come in handy and another 'Game Template' for the actual game for all the main stuff DB Structure, sign up, login, MB, chat, training stats, earning gold, markets, staff controls, main layout etc etc. You'll see how much easier it is when you come to do it!

- Write down every thought and idea! Never rule out an idea, just leave it out and do the other stuff first. You might come back to realise that the idea is infact possible to be included. (I've made this mistake over and over!)

Anyone else?

I'll edit this post as people reply and add their ideas to this. I'll also keep your name next to it so you know who to thank.

[Lythinari]

I prefer to keep a dictionary of certain variables and algorithms.
These arent coded forms but help a lot, especially when you want to bring other people up-to-date with your code, it helps other people look into your mind and see what you are trying to do with certain parts of your code.

When you develop any project, game or not, you should always think about making code as generic as possible, as said before, structure is one of the most important factors for project life.
That having been said you want to look at making your code very neat and tidy - minimal global variables, simple single task functions, meaningful variables.

If you think greatly about expansion, or giving your child away(yes.. a project is very much indeed your child), you will certainly have other people read it, and they will want to know what does what.

Otherwise, clean code has always saved me from trying to remember what my previous coding life has done.

[ZadoAsh]

Yeah, I've only recently started coding neatly and giving variables appropriate names, before I use to name them anything that was on my mind or just some random word... no idea why cause when I came back to finish the script I had no idea what half of the variables were and what they did!

So now that I code cleaner and use sensible variable names I have been working more efficiently! and can come back to my code and remember exactly where I left off.

[JohnMunsch]

For what it's worth, I've been a professional developer for 21 years, hopefully these are my equivalents of "Use Sunscreen":

• Use Version Control - If you aren't already using Subversion or CVS you should be. They aren't hard to use and they can make the difference between losing code and having problems working on a project with multiple people and not having any of those problems.
• Comment Your FREAKIN' Code - Here's a simple way to always comment your code and you really will do it. Before you write the code, write the comments describing what it is you're trying to do. What you're doing is organizing your thoughts and then you fill in code to actually implement those plans. Six months down the road when you encounter that code again, you'll be really happy you did.
• Plan to Iterate - Unless you've built something before, in fact, unless you've built several very similar things before, you aren't going to have a clue what your final design is going to look like. If you design some complicated thing on paper and think you have to stick with it to the bitter end you'll end up with a broken patchwork that barely works and won't perform. Instead, build up from a core of the application trying to always keep something that is a functional working application. Tear pieces out whenever it is appropriate to do so and throw them away. Do NOT fall in love with your own code. It's only a way to get you to what you want and you have to let go of it sometimes even if you spent a lot of work on it if it's just not the right code for the job.
• But Above All Use Version Control

[leZourite]

As i do usually some heavy commenting myself i have some remarks though.

When making the project using OOP most of the time (and of course if the methods and properties are explicit by themselves) documentation is less required unless there is some heavy calculation going on.

The same may apply to good old procedural programming it all comes down on how the project is built to begin with, using $c as variables everywhere isn't going to help for sure.

Also the backend is important as well the more obvious the name of the fields and tables the easier it is to read/maintain.

My advices would be :
- Work with small fast, easy readable chunks of code instead of heavy files with hundreds or thousands lines of code. There is a performance hit to rely heavily on "includes" but at the same time the project is so much easier to maintain.
- Keep it simple stupid, making complex code is not going to make the project perform faster.
- Make your project as modular as possible (even some part of the core) you should be able to disable parts of the project without the whole thing going down.

[JohnMunsch]

> When making the project using OOP most of the time

Hmm. Maybe I'm reading that wrong and you're just talking about how OO makes the design of the application a little clearer but it almost sounds like you or someone else might not be using OO all the time. If that is, in fact, the case, then let me add another couple of extra pieces of advice to my list.

• Use an Object-Oriented Language - I last used a non-OO language 18 years ago. If you're even considering something that's not OO for your development work, then stop. Immediately. Ruby on Rails is an excellent choice, Java might be nice, or how about Python?
• Learn Model-View-Controller - Some of the comments by le Zourite above called to mind that whether you're using an OO language or not, it doesn't mean that you're using it well. Learn the MVC pattern and apply it. Get the book Design Patterns and learn the basics of each pattern. You don't have to memorize them all, but get a little bit of familiarity with each pattern and what problems it helps you solve.

[leZourite]

I am no expert in OO  but what i meant was mostly that when using OOP, if your object/class is well made and the properties/methods speak form themselves (ie they are clear and explicit on what is their meaning) then you can use less "documentation". Example:

$player->get_userstat('health');  <= this line of code is fairly explicit you are invoking the get_usertat method from the object $player and want to retrieve "health". This is what i meant by "less" documentation that would be redundant to do :

$player->get_userstat('health'); // Invoke the method get_userstat to retrieve the health status.

At the same time if you are speaking about static documentation (ie an external file that lists all your methods and properties and what they do) that can be used as a helper without having to look at the code, then it's another matter and is needed when working with large projects.

[JohnMunsch]

Cool. We're both on the same page then.