The issue is how the development team, in general, always seems to broadcast an air of uncertainty.
They do. And the reason they do is because that's inherent to their particular brand of game development.
Very rudimentary, there are two ways of game development: standard based or resource based. The former implies that developers work on a game until it has reached a quality standard they deem sufficient, at which point they will release the product. The latter implies that developers work on a game until they have spent as much resources (time, money) on it as they can, or are willing to, afford. Now, time and money are easy to quantify: time can be quantified in day, weeks, months and years, or simply by setting deadlines. Money is just as easy: we can express quantities of money, you can quantify how much money you have, how much money you're spending each period of (quantifiable!) time, and when you will have run out. So if Pipeworks was working resource based, i.e. working a set amount of time or until a set amount of money had been spent, we'd know the deadline. What we
wouldn't know is how good (or even
if it would be good) the update would be.
Standard based development is an entirely different beast altogether. Instead of working with perfectly objective, mathematical guidelines, we're nose diving into realms of subjectivity that would give Socrates a field day. Is the game good?
When is a game good? When is
our game good? Is our game good
enough?
When is our game good enough? Do
our end users think the game is good enough?
When will our end users think the game is good enough? How many bugs do we have? How many bugs is
many? How many bugs can we afford to have to not to have
too many bugs? Is it
worth our while to squash all these bugs? Is it worth our while to squash
this specific bug? Can we support future updates with this code base? How
important is it that we can support future updates with this code base? How important is it that we can support future updates with this code base
right now? Should we spend time
now to save time
later?
How much time can we afford to spend now to save later? Can we cut corners?
Should we cut corners? Can we
afford to cut corners?
Which corners can we afford to cut? I could go on and on, but I hope you understand what I'm trying to get across. There's a massive array of subjective questioning that you simply can not quantify in (or like) time and money.
To be crystal clear, this does
not mean that standard based games are automatically good (standards can be very low) and that resource based games are automatically bad (a lot of work can be done with limited resources), absolutely not. It also does not mean that standard based development is better than resource based development: the former, while the ideal or preferred method to many game developers, simply isn't always feasible or possible, as no matter how hell-bent you are on standards, once your resources run out (especially money in this case), you can no longer work on your game and simply have to release (or delay indefinitely or cancel), whether you're ready or not (an old saying in the game industry is that "a game is finished when you run out of money"). Furthermore, for many companies working on a game until it's perfect would simply cost more resources than they have available, as well as being generally more expensive, and not necessarily profitable (and a profit is the prime directive for any company: without it, it can not exist). In an ideal world, all development would be standard based. This is not an ideal world.
Anyway, what Pipeworks has chosen to follow is the standard based path, at least partly because Re-Logic wants that, at least partly because
Pipeworks wants that, and at least partly because they
can. The benefit of that is that the 1.3 update will be up to Re-Logic's standards (i.e. as good as 1.3 on PC. Whether or not that is good at all is up to one's personal judgement). The drawback to that is that
any release estimate, short or (especially) long, is uncertain. That's not a flaw of Pipeworks, that is inherent to that method of game development.
down.
