Server/Client? or content?
by David Isaiah House · in Game Design and Creative Issues · 11/24/2010 (11:22 pm) · 4 replies
The idea was I'm creating a little virtual entertainment for me & my friends, & I'm wondering if (since there will be quite a bit of work in the content, mainly programming.) should I create the game world first? or get a client/server running first? thanks.
#2
I suggest using the pomodoro technique.
However it's important to DO SOMETHING, hesitating endlessly only leads to ,procrastination.
02/18/2011 (5:57 pm)
Nice pictures usually help more than nice code to atract some interest on your project. I think that if you have no choice in doing things that you like and things you hate in your project you should split your time equally between those good and bad tasks, rewarding ourself with the fun part, after achieving something in the "bad" part.I suggest using the pomodoro technique.
However it's important to DO SOMETHING, hesitating endlessly only leads to ,procrastination.
#3
In my experience this is how most people try to approach game development when they are being serious about it (as opposed to the hobbyist who only works on "fun" things).
However, I have seen this go wrong a number of times. A lot of the "funner" things or "easier" things are stuff that is related to how the user interacts with the game and it is really important to know every step of the way how those interactions are coming along.
For example, say I plan to have a big complex AI system with really smart "bots" who can take cover and use the environment to maximum effect. I could easily spend months working on the backend (harder/riskier) part of this system (pathfinding, collision, physics, fuzzy logic, etc) only to find out that when I drop an actual player in the game, they enjoy fighting the "dumb" AI a lot more than my smart AI.
Without a constant balance of backend features (traditionally harder) mixed with frontend features (usually easier), it is really easy to get lost in the implementation of one or the other (don't want to spend weeks fine tuning the main menu of your game when you can't even shoot the bad guys yet).
What I like to do is to continuously (usually weekly) re-evaluate the tasks needed to finish the game and to prioritize towards the ones that get me to a playable game the fastest. This does often mean that I end up only doing partial implementations of the "risky" systems but I have been surprised at how often those partial implementations are good enough for a fun game =)
A lot of the most successful game studios have a weekly playable build that they can hand to a new user which will demonstrate some sort of visible, measurable change (even if it is a small one). There is nothing quite like having to "present" your product to bring the task priorities into focus in a hurry (that is why GDC and E3 are often major milestones for game companies).
02/22/2011 (5:11 pm)
Quote:
I work on the harder things first and get that out of the way before movin on to the funner things.
In my experience this is how most people try to approach game development when they are being serious about it (as opposed to the hobbyist who only works on "fun" things).
However, I have seen this go wrong a number of times. A lot of the "funner" things or "easier" things are stuff that is related to how the user interacts with the game and it is really important to know every step of the way how those interactions are coming along.
For example, say I plan to have a big complex AI system with really smart "bots" who can take cover and use the environment to maximum effect. I could easily spend months working on the backend (harder/riskier) part of this system (pathfinding, collision, physics, fuzzy logic, etc) only to find out that when I drop an actual player in the game, they enjoy fighting the "dumb" AI a lot more than my smart AI.
Without a constant balance of backend features (traditionally harder) mixed with frontend features (usually easier), it is really easy to get lost in the implementation of one or the other (don't want to spend weeks fine tuning the main menu of your game when you can't even shoot the bad guys yet).
What I like to do is to continuously (usually weekly) re-evaluate the tasks needed to finish the game and to prioritize towards the ones that get me to a playable game the fastest. This does often mean that I end up only doing partial implementations of the "risky" systems but I have been surprised at how often those partial implementations are good enough for a fun game =)
A lot of the most successful game studios have a weekly playable build that they can hand to a new user which will demonstrate some sort of visible, measurable change (even if it is a small one). There is nothing quite like having to "present" your product to bring the task priorities into focus in a hurry (that is why GDC and E3 are often major milestones for game companies).
#4
I'm currently running 3 projects, two of them are for pure entertainment and will probably be released openly (one already is) for my community to enjoy, while the other is one I plan on going commercial with (hence the reason of my very powerful RSA based authentication package that I resourced). Most of my work has been on the more subtle projects, but only because it's the scripting from those projects that benefit my larger one.
You'll see that as you create more and more using this engine, you only expand the amount of resources you have towards other projects, which is something I hold to great value in development :).
02/22/2011 (7:14 pm)
Nicely said, my process is pretty similar, but seeing as I work with a smaller group, the process can be a little slower. But, to correlation, my more important aspects come first (IE: Transmission of important data from client to server [AKA: Authentication]). Most of my current work has been of the harder orient, sticking with the tougher aspects (C++ edits, and the tricky portions of TorqueScript). I do multiple test runs on all of my edits to ensure they are working to what my plan is set for.I'm currently running 3 projects, two of them are for pure entertainment and will probably be released openly (one already is) for my community to enjoy, while the other is one I plan on going commercial with (hence the reason of my very powerful RSA based authentication package that I resourced). Most of my work has been on the more subtle projects, but only because it's the scripting from those projects that benefit my larger one.
You'll see that as you create more and more using this engine, you only expand the amount of resources you have towards other projects, which is something I hold to great value in development :).
Torque 3D Owner Pitfall