So where do we go from here?

[Meep]

Hello there!
I am in the process of creating a Fox sim, hopefully to be launched around October/November 2010
(we will see how fast I can get everything together, I have no job and lots of time on my hands).

Anyway, I have basic knowledge of PHP, I have Easyphp and a MySQL database, and i'm wondering:
What exactly do I do, in what order?

I've got my login/register script up and running, but i've never attempted a sim site before...
and I don't know what my next move should be, gosh I feel like an idiot. Help? 

Thanks in advance,
Adeline 

[JGadrow]

Honestly, the first thing that you need to do is make sure you have a playable prototype of your game on paper. Seriously, without this, you might get lucky, but more likely you're doomed to failure or mediocrity.

Once your game is playable in some format, the coding part will go easier as a lot of the big questions have already been answered. Once you get into making the game, since this will be your first, my advice is to work small. Don't worry about adding a bunch of flashy features just cover the basics. This is probably going to be limited to:

Register / Authenticate (login)
Logout (seriously, it irritates me to no end as a user when this is not implemented)
Game Logic

Again, this is your first project, it doesn't need to be stellar. Get something out there and you'll find that you will learn a lot from it.

[Meep]

So, basically plan out what I want the sim to include, and demonstrate it on paper to get the idea? Thanks for your advice ^^

[dsheroh]

So, basically plan out what I want the sim to include, and demonstrate it on paper to get the idea?

Just to be sure it's clear, demonstrate how it works on paper/index cards/whatever.  You should be able to actually play the game (or at least a simplified version of it) before you start writing game code.  This will allow you to try out the mechanics and see whether they're actually fun or not and then easily tune them, since, at this stage, all you need to do is think of a change that might make it better and immediately try that change out.  Once it's in code, making changes is a much more involved and time-consuming process.

Knowing your rules and flow of play in advance also has the nice side benefit of keeping you focused when coding, since you don't have to figure out what your objectives as you go.

[Chris]

Download some open source BBG and study it. Avoid tutorials, these teach bad habits (performance).

Start with common features (like private messages/chat/shoutbox/ingame forum), these can be done without any design so you won't be wasting time while planning the game.

I don't think planning everything on paper would do any good (most likely it will be a waste of time), but writing a few words would help. I think one page is max, try to fit your core concept there. More will probably mean downfall (but it might depend on personality).
And don't fool yourself, you can not plan everything, some of it can be discovered during testing phase only and some of it will be proposed by players, not by you.

Name a similar game and list what you would change/remove/add. This one is best approach to my experience.

[JGadrow]

Start with common features (like private messages/chat/shoutbox/ingame forum), these can be done without any design so you won't be wasting time while planning the game.

Private messages, chat, shoutbox, forum = unnecessar complications for your first project. I think that you would agree with me Chris that the important thing is that they get a running game up and playable. Sure, it won't be great, but they can always add community support like what you've mentioned later.

I don't think planning everything on paper would do any good (most likely it will be a waste of time), but writing a few words would help.

It serves a completely necessary purpose: iteration! This gives you a chance to play the game before ever writing a line of code. This way you can fix the actual system defects that are present in the game before ever having to take the time to code stuff that's broken and needing to be fixed in the first place! Only with a good, working design should you begin actual development of anything greater than a framework! Unless, of course, your goal is to fail. Then by all means.

I think one page is max, try to fit your core concept there. More will probably mean downfall (but it might depend on personality).

See, this suggestion that you have made is the part of the paper process that I see as unnecessary at first. Plan your core mechanic first. Get that down and start playing with it! Is it fun? Why not? How can you make it fun? Etc., etc.

And don't fool yourself, you can not plan everything, some of it can be discovered during testing phase only and some of it will be proposed by players, not by you.

Now this quote is pure gold! Agreed. You will never find all of the issues yourself. Nor will you find all of the issues during alpha / beta testing. However, by iterating over a paper design first your design is much easier to adapt, add new information, and keep on playtesting! Only after you've got solid runs and everyone is enjoying themselves playing your game should you move to the implementation phase.

Name a similar game and list what you would change/remove/add. This one is best approach to my experience.

This is actually a game design exercise used in most classes. It really is even better if you design the game with your changes on paper and keep the games limited to something simple. For example:

I choose blackjack (sometimes called 21).

I'm going to change the core mechanic of blackjack so that you can, once per hand, choose a card and discard it. The dealer will then give you a new card to replace it. How does this change the game? Does it make it more fun? Does it remove too much of the random element?

The best part is... you don't need to write a single line of code. Just pick up a deck of cards and try it out! That way you can see if the change is fun or not without having to "waste" the time coding it up first!

I hope my little example helps you understand how prototyping before development can allow you to actually get your game to a stable, fun state much faster than by just coding it from the start and mucking with it later!

[Sunchaser]

See, this suggestion that you have made is the part of the paper process that I see as unnecessary at first. Plan your core mechanic first. Get that down and start playing with it! Is it fun? Why not? How can you make it fun? Etc., etc.

Although i can agree on designing on paper/simulating the core rules, how do you know if it's fun or not? The designer judgement can be biased. I would try to write a quick prototype with the basic rules/concepts online and get comments from people, then iterate...

[Meep]

Although i can agree on designing on paper/simulating the core rules, how do you know if it's fun or not? The designer judgement can be biased. I would try to write a quick prototype with the basic rules/concepts online and get comments from people, then iterate...

I think that's a good idea, and i'll try to look into all of yours too! (:

[JGadrow]

Well, one would hope that the designer would think the game is fun. Once it's fun for the designer, you perform testing with other people. Eventually, you should perform testing with people who aren't even remotely connected to you so that you can obtain unbiased feedback, can learn if you're accurately describing the rules of the game well enough to be followed, etc.

Again, this is all Game Design 101.

[jannesiera]

Wow, JGadrow is giving game design advice and  disagrees with Chris? Never expected to see that when I opened this topic...

Anyway, I'll throw in my 2 cents. I agree with JGadrow that prototyping on paper is an absolute game design necessity. If you have never designed a game before I wouldn't suggest it though.

Adeline, my suggestions:

1. It's suuuuuper important that your game design isn't overcomplicated for your first game. I don't know what a fox sim is... is it like a pet game with foxes? Well, if it is just focus on user profiles, pet creation and feeding the pet for example (very basic features).

2. Try to do it properly. Like chris said, check out other resources but don't copy-paste.

[Nox]

I think it should be equal.... paper is important, on the other hand what may seem interesting/entertaining/... on paper may not seem so when implemented (if implemented in a right way, though paper should give enough of guideline to reduce this chance of failure), plus imho on paper the game will look much more complex than how player will percieve it (depends on amount of uncovered mechanics, accessibily of features etc., much mostly it stands anyway)

[Chris]

We do not disagree on the meritum, but rather on proportions. My points is, you can not idolize one part of making the game, you need to take into account all of them. There is a balance needed, saying "design everything on paper first" and "start coding immediatelly and do not write down anything" are equally wrong.

- There are things that can be done on paper only.
- There are things that can be done during coding process only.
- There are things that can be done after the game is coded and is being tested only.
- There are things that can be proposed/noticed by players only.

The golden rule of the Aristotle, you know

The best part is... you don't need to write a single line of code.

Are you really a coder? I though, part of the reason we make computer games is because we like coding

Start with common features (like private messages/chat/shoutbox/ingame forum), these can be done without any design so you won't be wasting time while planning the game.

Private messages, chat, shoutbox, forum = unnecessar complications for your first project. I think that you would agree with me Chris that the important thing is that they get a running game up and playable. Sure, it won't be great, but they can always add community support like what you've mentioned later.

Well, generally I would agree, but not in this case.
- Starting with communication feature can be done even if you are struggling with design (can be done in paralell), if you don't know what the game will be about, if you change your mind, etc. You can do these in one way only, no brainer here, no dilemmas how to do it. Completing it will also give you a moral boost.
- I consider MMOG without any communication feature unplayable. Communicating with other people is the core of this type of game. If your game is playable without communication system then probably it is singleplayer game, not multiplayer game (exceptions exists).

[JGadrow]

Are you really a coder? I though, part of the reason we make computer games is because we like coding

lol I like writing useful code. I hate writing code and having to remove it later because it was a bad idea! lol The more testing you do before you code, the less useless code will be written.

Well, generally I would agree, but not in this case.
- Starting with communication feature can be done even if you are struggling with design (can be done in paralell), if you don't know what the game will be about, if you change your mind, etc. You can do these in one way only, no brainer here, no dilemmas how to do it. Completing it will also give you a moral boost.
- I consider MMOG without any communication feature unplayable. Communicating with other people is the core of this type of game. If your game is playable without communication system then probably it is singleplayer game, not multiplayer game (exceptions exists).

I agree that chat features could be worked on if they're still struggling with their game design. However, I'm betting they'd just want to get to coding the game by the time they get a reasonable framework put together. And there are some significantly advanced concepts that go into player-to-player communication that might actually demoralize them if they can't solve them easily. Or they'll suffer with lackluster communications.

For me, a game doesn't have to have a ton of bells and whistles, but the parts of the game that are there should show that they've been crafted with care and with the intent that I enjoy the game.