Wiki's info is really good for those who'd like to have some info on how it's done. Here's the link to make it easy for everyone:
http://en.wikipedia.org/wiki/Game_developmentI'd like to quote one small section which I think may help others understand why a game can sit at 99% for longer than most people would expect:
Nearing completion
The weeks leading to completion of a game are intense, with most team members putting in a great deal of—mostly unpaid—overtime. Unsurprisingly, this may lead to short tempers and a great deal of exhaustion. The extra effort is required for most games as unforeseen problems regularly arise and last-minute features are hastily added.
When I ran my own small business of writing applications for small businesses, I learned to always quote the time at least 3 times more than I ever dreamed it would time. You can never believe how the very simplest of things can put everything into a screeching halt.
For example, I ran into a problem on one application in which the results were not correct, but only part of the time. They were correct the rest of the time. As Spock would say, that's illogical. I went through every tiny shred of code. Scrutinized every loop, every branch, everything!
It turned out to be a _bug_ in the software I was using to write the code. Whenever it ran directly after another code, it would not work correctly. But when another command was issued, it would reset the first one back to working correctly. Very strange. The solution was simple enough once I figured it out. I just had to write a patch routine and call it every time I was needing to use the flawed command. That way, regardless of what combination of selections the user made, the patch would always reset that commend just before it was used.
Can you imagine what it took just to find that one simple thing? And it wasn't even the fault of my own coding. It was an anomaly in the language itself that no one had found yet (I reported it so it was fixed later).
You never know when one tiny thing can throw you way off. All you can do is use your best judgement based on your own previous experience and hope you don't run into something like that last minute. But sometimes it happens, and you have no choice but to delay the project. It's not what you want or what your customers want, but it's what must be done or else you'd deliver a defective product which really messes everything up for everyone.
That's why I'm so patient, I guess. I don't want to see people who are working to give us a product in which we will receive great pleasure to be under great pressure. Sure, they get paid for it. They have to eat, after all. But there is absolutely no reason why any human being should be pressured to rush anything as unimportant as a game (it's not life or death). They'll rush themselves enough as they can't wait to deliver the product (and put food on the table). I just think work must be balanced with actual life. So if they do run across some unforeseen _bug_, then that's what happens, and we'll just wait a bit longer.
When VV3 finally ships, I very much hope it is as joyful an event for those who developed the game as it is for us who play it.
When I use Photoshop, the skins are painted in Photoshop, then the textures are imported into a 3d modelling program, then they're applied to the 3d model. Then the 3d model frames are rendered out and organized into strips, which then go to Carla, so that she can go insane trying to align them all. (just ask her!) The source Villager files are 3d models, and the clothes are essentially part of the 3d model, so it's hard to separate the two without going back to the source files. I suppose it's possible to render out the outfit minus the extremities, but it'd take a loooooot of time, and then there'd be all sorts of other issues with masking, deleting geometry, etc, lots of technical boring 3d rendering stuff. ;-)
Previous Topic
Index
