Bulk update vs Update as finished

[Glenugie]

Okay, so I've found myself at a point in my game where I'm re-writing all the code, content and database structures. I've been doing this for quite some time now, but recently realised that my way of doing it might be flawed. I'm basically pondering the advantages and disadvantages of:
a) Doing all the work offline and then uploading everything all at once when I'm finished
b) Taking the game offline for an extended period of time and uploading parts of it as I finish with them.

My original plan, that I'm currently following is method a), but I'm starting to question it, because I realise that come the end there are going to be a lot of fixes to make, and I can't see how the project is going as I work, which reduces my motivation to work. It should be noted that the extended period of time could be upwards of two months, as I have to wait for artwork to come in as well.

The pros and cons I can think of are:
a) Pros: Game is online until the point where I'm finished
    Cons: A long period of bugfixing come the end, low work motivation levels
b) Pros: I can watch everything come together, bugs can be fixed as they arise
    Cons: Game is down for an extended period of time which may cost me the current set of players

If I think of any more, I'll add them to the list. Basically, I want to know if anyone has any advice/opinions on this matter.

Thanks in Advance,

Glenugie

[Chris]

Why can't you do everything offline and then upload it at the end of day with mere 5 minutes of game being unavailable till your FTP finish upload?

[Glenugie]

Mostly due to my method of coding tending to leave large gaps that would mean only once everything is there would it be safe for players to play the game. Also partly due to me wanting to let players only see the finished product, rather than a half finished one (Half finished being, whole chunks of the game not available).

[Harkins]

a) Doing all the work offline and then uploading everything all at once when I'm finished
b) Taking the game offline for an extended period of time and uploading parts of it as I finish with them.

A, unquestionably.

Your plans and designs may change, in which case you spend longer in silence with B. Actually, you want your plans and designs to change, because you know that you cannot perfectly predict what the best version of this game will be. A gives you more input from more people more frequently. Do you want to spend weeks coding in your attic only to find out from the few remaining players that it's terrible, or do you want to hear back regularly on your successes from players who are increasingly committed because they are being listened to?

[Chris]

Mostly due to my method of coding tending to leave large gaps that would mean only once everything is there

Change your habits

Also partly due to me wanting to let players only see the finished product

Change the media then, MMO dev is not for you

Honestly, I think the best solution would be to change your habits/expectations. Yes, probably you could make MMO with such mindset but it would be a nightmare for you...

You sound as if you were making a retail game. It is not retail, it is online. You code these different way. The product cycle there is reversed (the older the more popular), some obstacles not present (like the need for a player to download a patch), players expectations are different (frequent updates), additional opportunities are available (players feedback during production phase, as Harkins mentioned).

You could try to make 2 versions online (stable and in progress) or make a beta/test server with updates being tested first. These should help relieve some of your worries. But ultimately change of mindset is better, I mean a good online game has bugs, it has them because it is improved constantly, and has unfinished parts because you develop it and you need to gather players feedback on half finished things before you proceed.

[JGadrow]

<deep voice>The browser gods have spoken!

lol Seriously, everyone here is in agreement. Keep it online. If people are playing it that's a good thing. I think what you really need is to write down your development and deployment strategy and have the community critique that instead.

You're going about it the right way, but I think that you're trying to take on tasks that are too large all at once. Break your updates / changes into small, incremental changes and give yourself a goal.

ie:
1) Add new quest line for high-level players.
2) Balance changes for character classes.
3) Add the Foo feature.

You could do each task as part of a separate update instead of lumping them all into one. Or, if you have a development cycle that is long enough to accommodate them all, then you need to prioritize them and break them up into their component steps and make milestones for yourself. If you start missing milestones, start cutting back what's included in the update and make it a high priority for the next one.

I think one of the hardest things to do is to estimate how long a given piece of functionality will take to complete. I feel like it's akin to a game show (forget the name) that I saw every now and again where the contestants would bid against one another each claiming they could name a song in X number of notes. Except in our case, the bidding goes like:

1: I can code that function in 1 hour!
2: Alex, I can code that function in 30 mintues!
1: I can code that function in 12 minutes!
2: I can code it in 2 minutes!
1: Let's see you do it!

*#2 tries and fails*

As an aside, I believe this is part of the reason why many professional software projects are doomed to failure. They go between developers always getting the lowest estimate and then the developer realizes that they can't code it in that time frame and just hammers out some piece of crap instead.

[bbgames]

If your game is up and attracting players, you absolutely should not ever turn it off unless you're forced to. Your game should only ever be offline before it's launched.

[Glenugie]

Alright, it seems that you're all in agreement, I'll take note of this and try to do uploads every so often (as Chris says, perhaps at the end of every day). That'll cut downtime to however long it takes to upload, plus about 2 hours at the start (for making the changes to the database.)

If I've misunderstood what you were saying, go ahead and correct me

Thanks for all the help.

[Nox]

I'll speak now as a player and not developer, since I don't have a game running yet

I don't believe taking game offline once in a longer time for a day of few is such unthinkable deed, however taking it down for developement seems far far to long
thus I would agree with the rest

As for (truly valid) points JGadrow mentioned, related thread here: http://community.bbgamezone.net/index.php/topic,2872.msg20416.html#msg20416


As for offlining
e.g. soccerproject is down several times a day for 10-20min periods to calculate matches, yet it has 22000 active users

most games with resets are played are down for a few days before new round, still people play it

of course it's better not to take it offline... except that players get a few moments to rest

[Chris]

2 hours for making the changes to the database??? Don't tell me you manually change database on a live server...
Make a PHP function which contains all ALTER TABLE calls. After upload you just click "update database" in your admin panel and that's it. Fast and everything is 100% identical to your development version. Never make any database changes (both development and production environment) that do not go through that function.

As for milestones I make versions. I take the last version, add some stuff, change some stuff, fix some bugs. Then I test it. If no problems I upload it to the live server. Then I wait 1-2 days to catch critical bugs and rest. Next I start working on a new version (changing the version number ).

[JGadrow]

Make a PHP function which contains all ALTER TABLE calls. After upload you just click "update database" in your admin panel and that's it. Fast and everything is 100% identical to your development version. Never make any database changes (both development and production environment) that do not go through that function.

As for milestones I make versions. I take the last version, add some stuff, change some stuff, fix some bugs. Then I test it. If no problems I upload it to the live server. Then I wait 1-2 days to catch critical bugs and rest. Next I start working on a new version (changing the version number ).

Good advice, all of it.

Milestones are used in the development process. They are the key points in order to get to version 2.0 or 2.1, 2.2, etc..

"A significant event in the project, usually completion of a major deliverable.

Usually a milestone is used as a project checkpoint to validate how a project is progressing and revalidate the work."

[Glenugie]

100% identical to your development version.

Regretably I was, and I noticed this myself, manual changes weren't always saving, I'll probalby run from a PHP function now to try and repair the damage that was done, I took a backup before hand, so I can restore to that and redo

[bbgames]

2 hours for making the changes to the database??? Don't tell me you manually change database on a live server...
Make a PHP function which contains all ALTER TABLE calls. After upload you just click "update database" in your admin panel and that's it. Fast and everything is 100% identical to your development version. Never make any database changes (both development and production environment) that do not go through that function.

This is a good suggestion, but I'll do you one better: start automating your deployments. Here's an article to get you started - but when it comes to me rolling out an update for something I'm working on, it's as simple as "cap deploy" in my development version, and everything gets uploaded and updated for me. If something goes wrong, capistrano will let me rollback just as easily using "cap rollback".

Manual ALTER TABLE statements work, sure - but automating my deployments has saved me so many headaches I don't think I'd ever go back.