I would argue that Infinity:The Quest For Earth should never be mentioned. Nor should the acronym MMO. Keep people’s heads firmly wrapped around the idea that this is an arena shooter, with a stretch goal of being moddable. People should be getting behind it because of the awesome visuals and because of the inventive gameplay that results from the scale and seamlessness of the environment.
Morgan Freeman: “What do you do when you’ve created the technology to form a planetary system?”
Visual: fade in from black to a classic image of a star system with planets
Audio: simple tones suggesting emptiness of space
Morgan Freeman: “You create spaceships capable of exploring its magnificent vastness.”
Visual: spaceship gracefully enters the frame and maneuvers serenely and calmly. 10 seconds
Audio: orchestral music
Enthusiastic gamer: “And give 'em guns!”
Visual: flash, closeup on the empty mount points on the ship, guns pop into place and start firing, then transition to 3-second vignettes of wild melees of combat in space, spiraling towards planets, and racing across the surface of planets. 60 seconds.
Audio: techno music
I just noticed @Lomsor’s post about Bloodstained: Ritual of the Night. If INS wants to make a fortune, make one faction for the shooter based on Firefly Reavers.
I trust you to have built a realistic budget for the Kickstarter - alas, this article points out how other, less rigorous(/scrupulous) campaign made that a disadvantage.
Which means transparency and pedagogy will be even more important about the planned budget.
Now that I know that QFE is nothing more than a concept,I agree with everybody : don’t speak about it at all. It could unfocus people from BS and Kickstarter
The amount asked for initially has nothing to do with the real cost of making the game.
This is not how we are approaching our budget (it is not planned to be transparent with the public however), we plan to ask for what we actually need to build the game. However, this might result in a higher min funding goal than what people might be used to on Kickstarter lately. I look at some of the funding goals on KS and I wonder how they actually plan to pull it off sometimes…
While that may be true for Kickstarter games that are being developed from scratch, this may not be the case for a halfway developed IP like Battlescape. The tech for Battlescape has many years of (unpaid/self-financed) development behind it already, which means those costs won’t have to be taken account in Battlescape’s development. Also, it is very difficult to explain to backers what exactly is being funded with their money because game development is a fragmented endeavor (Some of it will fund art assets, some of it will fund server technology, and some of it will fund the developer’s latte machiatto on lunch break). All in all this means it will be very difficult to be completely transparant on which money will go where.
Personally, I don’t mind, as long as it gains me acces to updates and (hopefully) a finished product. Even if Battlescape won’t fulfill it’s promises, I will be glad to know I have contributed to Flavien’s (and the rest of the devs) livelihood. They have dedicated many years of their lives to this game, something I hope to repay sooner than later.
There’s nothing inherent to game development that makes it difficult to explain. It’s difficult to explain because the developers haven’t taken a hard enough look at their own project to understand what they’re promising to people. That is, if you want to understand something, explain it to someone else. If you can’t explain it, you don’t understand it.
Very few developers and artists are trained to have proper project skills so that they can understand their project properly. I didn’t get them until I was around 35, which is a sign of a real tragic situation for the software industry.
The essential lesson to learn about understanding your project? Break it down into actual work tasks that last between 0.5 and 3.0 days. If you can do that and can convince yourself that you’ve covered everything that you need to do, you should have a good understanding of your responsibilities on the project. When scheduling, allow for 4 days of productive work a week. One day is going to be burned in hallway bull sessions, bathroom breaks, meetings, illnesses, power outages, earthquakes and so forth. Different work environments may demand more down time.
Then the “pedagogy” part will be even more important
I don’t think you need to disclose to the public the kind of plan JB is talking about (that would be a pretty bad idea, actually). So explaining that, yes, it looks like a big sum, but making games is actually expensive, because X, Y, Z… (But with actual pedagogy skills)
That’s why when I hear figures with 6 digits, it feels that yes, they can make it with only that little money. If they were developing it from scratch, I would expect at least millions in budget - and as they know the subject and the tech pretty well, in addition to that, the chance of I-Novae to actually pull it off is higher. Which is why I trust them for I:B.
Of course, the fact that I want the I-Novae Engine to commercially exist, that I want to play I:B and I:TQFE later, and that I-Novae seems to be a bunch of great folks on a long, arduous passion project and that I want to see them succeed - that makes me less than objective. But that won’t stop me from backing the project and tell people around me to do so.
I was observing that it’s not difficult to understand product development, and that it’s critical for the development team itself to understand. No product development team gives a schedule or cost breakdown to prospective customers unless those customers are a collective nightmare of micromanagers and the development team cannot live without them.
If I understood correctly, you talked about a plan the dev team should make for themselves, to be able to get a realistic assessment of the needed funds. As a general idea it seems pretty mandatory, and I’ll trust you on the details (I don’t have the managing experience you are talking about yet).
What I meant is that it’s a very different thing to make plans for PR, which is indeed why we don’t see them used as such. And as total transparency is not an option, you have to be even better at explaining things the right way to counter the wrong ideas people developed based on all those underestimated campaigns. Sorry if I phrased it poorly.
Whether I-Novae has the management skills to build a correct plan, I can’t actually tell (it’s not as if you could make screenshots of that!) But both Flavien and Keith are experienced engineers, and they clearly showed more concern (and realistic figures) than most crowdfundings campaign I’ve seen.
So they didn’t show anything so far that they don’t have those skills, which is the point: there is no reason not to trust them.
Oh, everyone does it, but they do it to varying degrees of rigor. I’ve met precious few engineers who like to plan software. Software Engineers like writing software, and if they’re afforded the chance to say “Oh, call it 6 months of work,” then that’s exactly what they’ll say. Six months is a very long time. Surely anyone could crank out a game in six months.
In fact, Josh Parnell used that very number. He’s about 30 months into his project, approaching beta. But perhaps the scope of the six month project and the current vision of Limit Theory are different and I misunderstood.
Quite the contrary. The team is notorious for missing deadlines.
I have no doubt that they are sincere in their efforts to deliver a quality product in a timely fashion. If I believed otherwise, I’d never have gotten on the bandwagon. The question in my mind is whether or not they can start hitting their dates. I’d love to back a serious development effort, but I’m not going to send my hard-earned $2* down a black hole trimmed with good intentions. More than one software project has burned through available funds and needed to go for another round of funding. And then another.
I can relate to this a bit. My day job (mechanical engineer), we mechanical ilk interface with software engineers, not only in the machine design realm, but the budgeting of said machines. They seem unwilling/unable to plan any kind of design roadmap, we usually hear something like: “It’s impossible to give you a number now, I need ~200 hours just to start then once I get into it I’ll know how much work it is”. As a mechanical guys, we can have a vision in our heads of what it will take to design the machines, the draftsman and lower level engineers who will be working on the machine, allowing us to budget quite accurately during the kickoff/early design meetings. I’m not a programmer, but it seems quite difficult to ever get a realistic timeframe out of them In my professional experience, in the engineering world, the software engineers are the more “sensitive” types, the mechanical and electrical guys generally don’t create as much drama lol. Being involved with I-Novae-Studios, I am on the art side of things, so I guess it is my turn to be a dramatic!
To be fair, though, as a mechanical engineer you’re probably asked to do something that’s not only been done before, but been done so long ago that the patent/copyright claims have expired, on a fairly regular basis. Or, failing that, most people will be able to quite accurately describe what a machine should do (“metal goes in, nails come out”).
In the software realm, tasks like that are so rare that even the formal educations don’t really bother spending time on them (well, they spend a great deal of time telling you to redo tasks that were done the year before, but not research those tasks or learn from last year’s experiences). Never mind that the vast majority of the people working with it are either self taught and/or have completely unrelated degrees.
That drama comes from the dynamic environment. If mechanical and electrical engineers didn’t have time-tested and stable data to work from, their lives would be just as drama-laden (and the people who currently populate the field would be off doing something else). If there’s a disagreement between engineers, somebody will cite the hard data to support their case. If there’s a disagreement between programmers, well, it’s common enough that nobody really knows who is correct. Or if either is correct.
Ultimately, software engineers could absolutely be trained to schedule software. As I described above, it’s not difficult. But software shops don’t like to do something as ponderous as scheduling. They want to keep dynamic and active and aggressive. Let’s get some coding going and show the world who we are!
Not really for me, I tend to get a lot of the science projects… But yes, a fair bit of it is known tech. However, the software engineers should not be re-inventing the wheel for each machine either.
You don’t reinvent the machine, the stuff that is known in software engineering is like words a few idioms and maybe even some well known paragraphs, with some general logical approaches to problem solving as compared to literature writing.
Software engineering is akin to some sort of Logical Art, you have to be creative and you have to be logical, not even worth mentioning is that you need to know how to code, syntax and all that. If you are not doing something that you have done before and in development that is around 90% of the time, you are always at the frontier of your knowledge, always in uncharted territory and always learning.
You do get better, yet not so much at writing the actual code, you get better at structuring your logic and code, with experience you can tackle larger and more difficult problems with less code and less implications.
As for the timescales, you can estimate time needed for the thing that you have already done, pretty accurately. As for the unknown and uncharted, a single task can vary from 1 hour to 1 week, depending on what you run into.
Boy, I don’t know, I still think programmers get a pass due to managers not being able to understand code, like they think they can understand mechanical drawings or electrical schematics and tell us mech/elec engineers how long our stuff should take.
In my professional experience, in the engineering world, the software engineers are the more “sensitive” types, the mechanical and electrical guys generally don’t create as much drama lol. Being involved with I-Novae-Studios, I am on the art side of things, so I guess it is my turn to be a dramatic!