“It’s done, there is no way back. We tried, we failed”
kickstarter.com
kickstarter.com
When we made Crash Bandicoot (with a team of 7), it was already virtually impossible to make a AAA game with 6-10 people, and that was 20 years ago.
I tell inexperienced entrepreneurs to take their honest best estimate and multiply by 10. Or, as Mark Cerny (our producer on Crash) used to tell us, "add one and increase the unit: 1 week = 2 months; 2 months = 3 years; 3 years = you're doomed".
For a less anecdotal version, read The Mythical Man Month. (The factor he arrives at is 9.)
I feel like CTR was slightly easier, but still a great arcade racing game.
The combination of ahead-of-its-time graphics with really fun gameplay is rare, particularly after the 80s.
New problems mean unknown ways to fail === hard to estimate
I'm not an expert on the economics of the video game industry, but I can't believe that would pay a team of 6-10 people for very long.
[1] https://www.kickstarter.com/projects/45588301/woolfe-the-red...
With that said, I've been following Patreon and the financial models at Patreon just make more sense than Kickstarter.
Various game development groups have constantly slipped their schedule, and backers respond typically by keeping the donations steady. As long as the game developer releases a demo demonstrating progress, backers are more than eager to continue their $5/month or so funding.
The main issue is the slow pace of early Patreon funding. A lot of games have to bootstrap with $500 / month or $1000/month for two or three months. Even "successful" Patreons only get $3000/month to $5000/month, and those are few and far between. (Patreon doesn't seem to have the reach of Kickstarter or Indiegogo quite yet. Perhaps if Patreon expanded and grew it'd be better?).
The Patreon model is also better for "subscription" stuffs. Podcasts, youtube videos and the like are more popular there. I can't find too many games on Patreon by searching, but I've seen them advertized on various forums.
In any case, even with $5000/month, it'd be hard to run a team of 6 on such meager money. I've been following a team of 3 and they're barely making it on that.
But Patreon does strike me as more plausible than Kickstarter.
-----------
On the other hand, Kickstarter is extremely good at measuring "hype". So perhaps the Kickstarter model is better if you're trying to prove to outside funding groups that your team is worth investing into.
Patreon seems to work out for smaller-scale projects, like youtube videos or podcasts. Its a bit harder to map it to a video game, but I still think the Patreon model for video games is superior to Kickstarter.
Everything is crap though, some real innovation should happen in this space. Unfortunately, I'm out of ideas...
Where did you take this number from?
Try at least, the bare minimum, double that in Western Europe for anyone calling themselves a game developer
Let me say you can find better opportunities outside the field
For example I work in France and I keep approx $36k after all taxes (but still not taking VAT into account, which is 20% on most products). This salary costs around $78k for the company I work for. Approx breakdown: 25k in employer taxes, 12k in employee taxes (the distinction is rather arbitrary, but sometimes the government changes the rate of one or the other...) and then 5k in household income taxes (if you have some capital gains it also goes to income, but actual work is taxed over and over and over... :p )
Also I work full time: 218 days a year (with no fixed number of hours per week, but it is very reasonable). That's more than 6 weeks of paid vacation + a dozen of holiday here and there. And when I was sick for 3 weeks last year, it was not deduced from my vacations (but the sickness indemnity during those 3 weeks were less than my usual rate, maybe 60% but I'm not sure)
I also sometimes work on the side as an independent and on the monetary side the end result is roughly the same: if a client pays me X, at the end I keep approx X/2 and the other X/2 goes to various taxes (but it is better to be salaried, because those X/2 in tax provides you virtually no security as an independent, whereas they do when salaried)
Now to compare anything you'll also have to at least convert in PPP, and also consider what is provided to you (and even to others!) for "free" with your taxes. This is arguably not reducible to a single figure; I would rather make a "little" less if that lets other people have better health care and if that means that nobody will ever ask me a fucking ridiculous amount of money if I need a really expensive medical treatment (not that the French health care system is the best, but I guess it is not that bad compared to some other countries...). Also a lot of social and related services are provided for completely free to the users. And even in areas where housing is expensive you would find it insanely cheap compared to NYC or some places in the silicon valley.
And to finish remember that the value of the Euro has decreased a lot the last few months compared to the USD. That make all the amounts even more difficult to compare: one year ago I would have told you that I keep maybe $47k after all taxes (from an amount in € that was actually a little lower than what i have now...)
This sounds ideal for me, but I like low-level C/C++/assembly programming and wouldn't want to give that up for the web.
Compilers, JIT compilers
Maintenance of old software
The main difference on the downside is a plethora of frameworks that often constrain your design badly. Of course, on any large project there is always a way to do things, and it is not always pleasant ;-) So it's not really so different. I also had to learn quite a lot about databases, something that I shied away from in my earlier days. Again, many frameworks try to shield you from database details, but they bugger up the object modelling so badly that you are much better off being quite aware of what is happening under the hood.
On the plus side, code bases are generally very small. We're talking having to maintain small 10's of KLOC (and very often less than 10k code) as opposed to 100's of KLOC. I wouldn't say they are toy problems, but they are definitely on the small to medium size. You can pretty much understand all of how an app works. Frameworks often bring the total code size up to above 100 KLOC (yes, I have spent some time debugging Rails ;-)), but again, it's not something that would scare a seasoned dev.
My main pleasures are being able to work with 100% free software tools from back to front. It's truly awesome to be able to debug and tweak anything I want. For frameworks and libraries, no longer do I have to depend on marginal documentation to see how something works -- I can just read the code. This is a massive plus.
For me, the acceptance of unit testing as a normal development procedure has been wonderful. Not all web devs subscribe to it, and very few do it well, but it is at least a mainstream concept. Also the tools available for TDD are really great. Rspec style tools (including Jasmine) are worth their weight in gold.
I think the biggest surprise for me making the transition was that there is a huge amount of complexity in web development. Yes, there are lots of people who do web development as a kind of paint by numbers, but honestly I've seen those kind of devs everywhere I've gone.
If you are looking for a change, I wouldn't rule web development out.
72k USD will get you one senior developer for one year.
20k is far too low, you can make more than that waiting tables. Jesus 9.615/hr. I made about double that as a waiter in Oklahoma in the mid 1990s.
Update your resume sir/ma'am!
If you make $80k where I am, I would be expect the same person to make around $105k in Seattle. I'd wager the person you replied to is also somewhere in the Midwest.
I'm the tech lead for my team at a medium sized company that builds high demand, critical backend services. Customers include small businesses, some well known Silicon Valley companies and some established Fortune 500s. I like what I do and get to see just how well software I work on scales with customers that push it to the limit. I mostly use C# with a bit of C++ right now, but previous jobs I used Python, Java, JavaScript and PHP. VCSs have ranged from SVN, TFS to Git. The one used mostly depends on when the company was founded. Early 00s probably means SVN while the last 5 to 10 years probably means Git or TFS.
Does company culture differ here? I don't think so really. Like anywhere, it depends on where and whom you work for. I work 40 hours a week on average, have a workstation that rivals my own gaming PC at home (we also had the choice of a high end laptop, but I prefer a desktop) and wear jeans/shorts/t-shirts to work (assuming I'm not working at home that day). My brother works for a company with a similar culture to mine and they have their own personal chef that serves them lunch every day. My employer and his are only about 10 to 15 years old, so that probably contributes somewhat to the cultural similarities.
Feels like there's a real dearth of opportunity here in Seattle compared to the Bay Area. There's mainly Amazon and Microsoft, and nobody I personally know who work in either place like it much. Google and Facebook have some small offices here, but most of the interesting and exciting work they do appears to be done in the Bay Area.
Do you feel like you can find another job you'd enjoy in the city where you live pretty easily?
Columbus, OH. Around 800k-850k if you just include the city limits and well over a million with the metro area. Third largest city in the Midwest. Lots of job growth and probably more tech jobs here than anywhere else in state. Factor that with cost of living being pretty cheap, I don't have much of a reason to leave right now.
> Do you feel like you can find another job you'd enjoy in the city where you live pretty easily?
I'm sure I could. I didn't used to think so, until I actually started looking for work after doing mostly consulting and contract work. I think companies here have more trouble finding versatile developers that can wear "many hats" versus developers finding interesting work. Most only know one language well enough to use it (mostly Java or C#) and are either bound into knowing Linux or Windows Platform development and rarely both. That's just my opinion on it though. I'm comfortable with doing most types of development in most languages, so that helps with finding jobs I like.
No interest really in working for large companies. From my experience, that's generally the reason people move West (or East) that live here. I prefer companies where people actually know who I am.
Going out to lunch here at a decent sit-down restaurant is around 8-10 dollars with tip (assuming you're drinking water). Somewhere like SF or NYC will be much higher.
Out of my friends that graduated with me, in the set of {Google, Microsoft, Amazon, General Dynamics, AMD, Intel} employers, no-one, and I mean no one made above 90k starting. These people all graduated Suma Cum Laude (>3.96), with >3 years experience on average through internships.
No one should ever assume their counterparts are making anywhere close to them.
Clearly, the amount of work involved here was way too much.
But if 72k can keep you alive on ramen and a futon so that you can make millions on the back-end ...
Regardless, it's a gamble. But the up-front money isn't the only consideration. Especially if everyone has a real stake (which is not the case for startups in general).
And a single person just cannot turn out something close to a AAA title.
I feel like a lot of people underestimate the work/cost involved in physical rewards. I remember reading a game devs blog post about the subject.
Overwhelmed by rewards seems to be a common failure on KS. The list he rattles off in this case is quite extensive, and the postage cost is all that's preventing it from being sent. I wouldn't be surprised if they have 10k into rewards alone, especially when you account the time spent developing them.
I have friends who've launched XBLA games on much, much less working full time out of a basement. During development, they could barely pay rent. Afterwards, they buy new houses.
I feel like people don't take real risks any more, and seem to misunderstand what actual ownership of the outcome looks like.
Sign of the times?
And the issue of AAA ... well... Get a simple game or playable demo going and build off of that rather than shooting for the stars. Or did we lose site of what an MVP is, too? Sounds like the OP did.
*unless this was a legitimate case of being 1 month away from launch.
I see a lot of kickstarter project where a team of 5 is looking for 20K or somesuch. While some teams can and do pull it off, that just seems crazy low and too much risk (especially when you factor in KS' fee and cost of rewards).
EDIT: Removed the as a rule from the first sentence (was I, as a rule, won't back...). After reading andallas' reply, I realised that there are some very rare occasions where I do back projects I otherwise wouldn't, but they have to have really proven themselves.
$50,000 could have afforded them an artist for 6 months, or helped them to secure some essential software, or just supplemented the incomes of the existing team, while they continued doing 'side-jobs' to generally pay the bills.
Now ideally, they would get all their funding from one source (so we know what they received) and it would be enough to pay for everything. But I think a lot of people who pledge on Kickstarter have a gross misunderstanding of how much money a game takes, considering each team-member may have a salary ranging from $50k - $100k is not unreasonable at all.
Descent:Underground [0] and Starfighter Inc. [1] both had well-seasoned teams of industry veterans, including founders who had written popular space games (X-Wing, Wing Commander).
One of the big differences I identified between the two campaigns was that D:U asked for an amount of money that seemed like enough to run a small game studio for a year ($600,000) while SI asked for an amount of money that seemed like it wouldn't get them anywhere close to done ($250,000 for a bigger team). D:U was also really clear in their messaging -- if we don't raise the funds, that's a market signal that we shouldn't make this game. SI communicated several times that if they didn't reach their KS goal they'd just do it another way. What that indicated to me is that D:U had a realistic crowdfunding plan that could get them to release, while SI seemed not to know what they were trying to accomplish with kickstarter.
To be sure, there were a lot of other factors at play. With D:U, Eric Peterson pulled a lot of support from Star Citizen backers and they released an excellent trailer in the last 48 hours of the kickstarter. SI dodged questions about what engine they were using and had a number of other customer interaction problems. But I think one of the big issues was that they didn't ask for a realistic amount of money, which made it seem like they either didn't know what they were doing or were relying on additional funding which would increase the risk for kickstarter backers.
[0] https://www.kickstarter.com/projects/descendentstudios/desce...
[1] https://www.kickstarter.com/projects/impellerstudios/starfig...
I think they failed to earmark the funds for rewards (they did ship the game, the issue is they didn't ship the art books, wallpapers etc, and went bankrupt), and mostly just failed to build an awesome enough game. They probably expected strong sales as they'd been hyped quite a bit, greenlit in a few days, featured at the E3 etc. But when the sales didn't happen and the loans had to be paid back etc, they went bankrupt and couldn't ship the merchandise rewards.
It's so easy to underestimate the work to be done, graphics easily break when you change the underlying hardware and renderers, gameplay had to be adapted to touch controls, etc. It didn't help that our estimate multiplier was only 3.
All of this gave me a much greater appreciation of the work you guys did at Naughty Dog.
Given a particular problem of a similar sort to something he's worked on, an experienced engineer will be able to list 10 different issues that might crop up.
An inexperienced engineer won't know of those potential problems and will just see the most optimistic path possible.
When you're moving massively outside your familiar zone, many unexpected problems will crop up. Best solution is a phased approach. Pick the bits you judge as most risky (you should hopefully have some idea) and implement prototypes in those areas, in the hope that most of the scaries will crop up. You've then got a better idea as you move on.
I've written this in the context of doing engineering, but it's equally true in all fields - like trying to sell a product into a new an unfamiliar market.
The other aspect of this that I see, even in seasoned engineers, is the 'presumption of simplicity'. Some things look really simple, but inside they are actually quite complicated. A smart phone is just a screen, a computer, a battery and a radio right? Too many times people see something, think "that doesn't look too hard I bet I could do that in a weekend"[1] but don't actually follow through on that thought and spend a weekend building what ever it was that was so easy. Sometimes the more experience you have the more dangerous this is. I can recall times in my own life we're I've grossly underestimated the difficulty of stuff, its lead me to be a lot more conscious about things I know about and things I think I know something about, especially when predicting schedules and work effort.
[1] A very common theme on acquihire stories here.
In the parlance of Mr. Rumsfeld, you can learn from the known unknowns, but often you don't even discover the unknown unknowns (the "meta-ignorance") until it's too late.
This, like most engineering tasks, is more straight forward. You have to know what its going to take to build each piece and assemble them into the final product. So if you are making a AAA indie game, it helps if you can talk with the project manager at a company that made AAA games and go through their list of deliverables, and then think about how you're going to deliver the same thing. Sometimes you'll be tempted to say "we won't need to do that" but like Chesterton's fence, you need to understand why they did that so that you can really say you won't need to do that thing.
It is always ok to start with "how hard could it be?" but that starting point requires you educate yourself on exactly how hard it could be. For game development I think pretty much all the questions are knowable (except for consumer reception of course)
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."
I learned something new (and useful) today. Thanks!
Source: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
Yeah, it's descriptive. I think I re-purposed a term from an academic paper that referred to meta-stupidity: stupid people are too stupid to know that they're stupid.
They did an experiment where they got people taking an exam to guess what mark they were going to get. In general, the lower scoring people in the exam over-estimated their mark more than the smart people.
Part of why it's good to be cautious around self-proclaimed experts.
Its very easy to forget all the efforts invested in learning a skill when you've been using that skill for many years. When it becomes second nature, you assume its also that way for others.
For example, a singleton is easy to learn and easy to use, but since every function using it adds a hidden dependency it quickly grows in complexity to the point its impossible to reason about it without forgetting something.
On the other hand, a Promise is simple as it depends on nothing but a producer and a consumer, no matter how much you compose them. Yet I've seen many experienced developers struggle to learn how to use them as they're not easy to understand at first.
This is somewhat related to meta ignorance. From my own experience I've seen a tendency in novice programmers to stick with things which are both easy to learn and use. Their projects go well initially but they grow less and less productive over time as complexity creeps in from the composition of all these easy to use things.
I've always said experience in our industry is knowing what not to use in order to stay productive in the long run.
Here's a link to Rich Hickey explaining it in depth: http://www.infoq.com/presentations/Simple-Made-Easy
Also note that english isn't my first language (I'm french Canadian) and even here in french the distinction is seldom made.
The distinction between two main types of simplicity, those of parsimony and elegance, has been a long-standing philosophical topic [1].
In engineering, the so-called KISS principle (first coined as such in the early 20th century) has always had the implication of minimalism and implementation simplicity, in contrast to mere ease of use.
Fred Brooks wrote a famous paper in 1986 [2] perfectly describing the differences between accidental and essential complexity, and of the semantics of complexity management in software projects.
Hickey has said absolutely nothing spectacular, but his name comes up every time from the typing fingers of the historically illiterate whenever simplicity and ease of use are brought up.
[1] http://plato.stanford.edu/entries/simplicity/
[2] http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...
I knew about KISS, but almost every time I hear someone mention it they think about ease not simplicity. I will also definitely check out Brooks' paper.
While I understand your position, I believe a lot of this has been lost to the new generations of engineers and what Rich did is remind them of it.
Rich Hickey gained fame for this because he stated an idea very clearly and compellingly, this is non-trivial and should not be so flippantly dismissed as just recyling old ideas—all your ideas are recycled too.
+100 for this.
I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level.
This tends to affect future work rather than the current sprint.
Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced.
One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.
1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this.
Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
Once you have committed to doing something, experience usually wins out in doing it better.
I ask this sincerely, because I am trying to find a way to approach office politics as just part of my job and play it well. But as a developer, I'm also trying avoid the version of office politics where you just promise impossible things then find scapegoats later.
- I think there will be some challenges in that, can we take some time to think through the implications of ______ (or how we would deal with _____, etc)
- I think it's a great idea, but we're going to need to come up with a creative solution to solve _______
- I think we're probably under-estimating how much work that is. Maybe there's a smaller version we could start with and progress from there.
- We've looked into this before and got stuck at ________, do we think we've got a solution for that?
Want to do better or find an edge? Figure out a way to be part of a better reference class.
a. "things that would mean the project failed."
in contrast to:
b. "things that could lead the project to fail."
For "a" one could list. There is no money left. The team desintegrates. Etc...
And finally ask yourself, what could I do now so that, if we arrive to any of the listed sutations the damage is reduced.
Take this comment with a grain of salt. As every other comment on the internet.
After doing all the normal project management estimates, etc, the very first thing he does is sit down everyone who will actually be implementing the project (or a representative sample).
He then asks them a simple question: "Come up with one scenario where this project would fail."
The implication being that this is lateral to the train of thought people use to make initial estimates. Iow, in all possible estimation scenarios, the project is assumed to have been a success! It's not unreasonable to expect that implicit optimism to filter down through sub-estimates.
His point was that giving people permission to imagine scenarios for total and abject failure identified important risks that could be back-fed to improve the initial optimistic estimate.
I pulled in a sample of people from the development team and proposed the following scenario:
It's the Monday morning immediately after our implementation, and you come in to the office to find a bunch of senior managers discussing a big issue with the system.
What went wrong?
That brought up a huge number of potential issues that were sitting in the back of the engineers minds that have never been written on any risk register, etc.
We talked them through, got comfortable that some of them weren't really likely/possible, and then worked on mitigations for the others (mostly via test plans)
In the end, the implementation was a success.
"Hofstadter's Law" at work: any unfamiliar task will take longer than planned, no matter how much extra time there is the plan. You can't account for your ignorance with padding, you need some kind of actual knowledge.
The result, then, is that there are only a few ways to actual make an AAA game. One is to hire some quorum of people who've already made one, so that they can bring you up to speed. The other is to do enough proofs of concept that you can see the problems coming.
It looks like Woolfe went from some mobile, educational games to a AAA PC title. That, it seems, was too big a gap to predict and prepare for the hurdles they would face.
I've always known this as Cheops's Law: No project is ever completed on time or under budget.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Whenever I'm about to build something big, I first start thinking about things that would be hard to do, or perhaps that I even don't know how to do yet. Then I build prototypes of those to make sure I can to it and do it efficiently.
Once all pieces are ready, it's just a matter of putting them together which is straightforward and you have some chance to actually estimate the time.
In his biography, Elon Musk acknowledges that his original estimates for SpaceX were completely ridiculous and based on his experience with writing software and ignorance of the realities of building spacecraft.
Some studio have made success with flash-compatible renderers, and we even thought for NHL2K2 to use one, but first it was only compatible with the Windows version of the Dreamcast (okay, I barely remember now, as we didn't used it, but there was a choice whether you can ship your game with some barebones NT system on the Dreamcast - but you had to lose 2mb to the oS). So that middleware (I think) required it, and it wanted somewhere from 2-4mb more on top.
One big problem, back in the days, with the UI is that you can have tons of memory in your main menu, but you barely have anything while the game is playing. So your "PAUSE" menu might use completely different code path, and look quite differently. The alternative is to reload things after PAUSE, but this decreases the quality of the product, also much harder to test, and you would hear the DISC "screaming" soo much :)
Nonetheless Dreamcast was fun to work on, spare the compiler, and the debugger :)
> In the video game industry, AAA (pronounced "triple A") is a classification term used for games with the highest development budgets and levels of promotion. A title considered to be AAA is therefore expected to be a high quality game and to be among the year's bestsellers.
By definition, a budget of $75k + 6-10 people wont make an AAA game.
> When we made Crash Bandicoot (with a team of 7), it was already virtually impossible to make a AAA game with 6-10 people, and that was 20 years ago.
I'm biased/invested in this area, but I think nowadays tools are really helping strip away the technical challenges of making a game. Increasingly game development is less about technical challenges but more about the creative challenge. Individuals are willing to pour thousands of hours of work into artistic and creative projects, and I am seeing far less resistance and challenges going forwards for these sorts of people to produce AAA quality games, when previously game creation was extremely inaccessible to them.
Also, thank you for Crash Bandicoot. Amazing game :) One I loved playing growing up!
However, in my opinion AAA doesn't apply to scope or budget but quality of experience. Super Meat Boy is one of the best games I've played in years and it doesn't come anywhere near the scope of say GTA 5 (which is also awesome).
I don't think anyone calls SMB a triple-a title though... so I'd say wikipedia's definition is correct.
So then, I think the real issue here is aiming to make a game that compete with major studios who have budgets of $50m and employ hundreds of specialized team members.
These devs claim it was a passion project, but then they throw in the towel on the entire concept of running an indie studio after the negative reviews come in. I understand the bankruptcy move, but if I were the founder's shoes, I would move somewhere cheap, take a side job and keep making games on the side. If I still loved the Wolfie project, I would fix it for free and I would find a way to send my KS backers whatever I owe them. I would read every negative review of my game, try to bucket the feed back (something like: legit, semi-legit, ignore) and then fix the game. I would also print my favorite positive reviews and hang them up around the house for motivation. If I no longer believed in the game, I would build something new but smaller. 13 years is a long time to wash down the drain due to one failure.
Currently I'm trying to make indie games along with my gilfriend. She has no formal 3d art training but has been teaching herself via the internet. I learned Unity and have been teaching myself c# / cg and all the other shit that goes with 3d game development (I come from a python / js background). We will most likely fail hard but I don't understand the concept of quitting when you got into something for fun in the first place.
edit: it also sounds like these guys tried to build their own engine... or something. If they did, that was a bad idea. If they didn't, I don't understand why they had so many issues with collision detection. Haven't played the game though... its just odd to hear that they had major collision detection issues.
Suffice to say, it is entirely powerful and possible to create incredible games. Ori and the blind forest, Hearthstone, and plenty of AA and indie games use unity, lots of kickstarter projects.
To the chagrin of gamers, Steam has greenlit several terrible unity based games, that only use free/cheap unity store assets, namely Airplane (?) and DayZ (sic) , which are quite infamously reviewed by Jim sterling on YouTube. Enough to cloud the market for games created by any future indie dev.
Advice is plentiful, though you do have a lack of great sources to ask questions.
IMO, devs starting with unity are almost drowned in advanced features to get started from concept to prototype. Easy to learn, hard to master, easier to edit store bought prefabs than to DIY. They can become a crutch very quickly.
The unity store can be a boon and a roadblock to progress, because it doesn't always help. Starting out, it won't give you the best direction or how to code, but it will take you forward to developing a playable prototype. Sometimes within hours of starting a new project.
If you have a team, unity is going to be the source of frequent anguish, but it is still more flexible than it ever was.
the biggest hassle will more likely to be assets, and far down the road, dealing with rigid bodies, collision, raycasthit, and the PhysX implementation of mesh and mass collision.
For most devs, the initial unity workload will be around 70-80% asset creation to 20% game coding, and about 290% of the budgeted time, debugging.
A good idea is to build a prototype, get the mechanics working while the art is being developed. Once the code is in place, debug/playtesting is critical to developing assets that then can be designed, built as mesh, and imported within the prototype in a few seconds.
Character controllers are generally easy, more dynamic mechanim is able to avoid some pitfalls of the capsule collision system, and there are ways to add crouch/jump use cases with pathfinding and AI,(which is a good bit of work.)
Unity does excel at getting a walking mesh going, using mechanim to blend animation and mesh collision, and 3d art assets designed in Maya or 3dsmax, etc.
When I started with unity in 2012, it took forever to even think about how to build a menu system, until NGUI. It's improved drastically since the store was added.
This is both good and bad news for indie developers. Bad in the sense they'll never reach that scale and level of graphics without serious investments. Good in the sense the triple-A giants are anything but flexible and indie developers can therefore differentiate themselves through innovative gameplay and storytelling, which is very much lacking in the AAA scene nowadays.
Minecraft does this, in a way. Instead of a villiage-sized Barbie / GI Joe playset (with everything perfectly designed), you get a giant bucket of lego bricks.
Not that Minecraft / df style games have done much better on Kickstarter.
Yes, it's a hugely popular game, but it is the archetype of "indie game done good".
I agree, it's not AAA, in terms of assets, but I'm saying a "box of lego bricks" (or something like that - copying Minecraft won't work now) is the only way to compete with AAA on assets. PCG looks like a holy grail, but I doubt it (unless you can get it good enough to sell to AAA, then why wouldn't you just license the tool?).
Minecraft is AAA success. Your big-box retailer probably has Minecraft guide-books for sale. There's nothing that touches it. Papers, Please is an "indie game done good", and it sold maybe 5% of Minecraft.
For what it's worth, "semantic" means "related to definition of words". The argument we're having is still semantic. And semantic arguments are usually pointless. Just in case you didn't know.
[1] https://www.quora.com/Who-makes-more-money-Hollywood-or-the-...
AAA game (typical example: Skyrim):
* Sells for $50-$60
* Has cutting-edge graphics and (generally) runs on the newest generation of hardware
* Is available on most/all gaming platforms
* (Nowadays) Usually has some celebrity involvement (Skyrim had Max von Sydow, Christopher Plummer, Michael Hogan. Oblivion had Patrick Stewart.)
* 20+ hours of gameplay
AA game (typical example: Far Cry: Blood Dragon, Call of Juarez: Gunslinger):
* Sells for about $25-$40
* Made with last year's AAA engine
* Runs on last year's hardware
* Typically available on fewer or only one platform
* 8 - 20 hours of gameplay
Anything below that is either a classic game remastered (for example, the recent Homeworld remaster), or an indie title.
Frequently a AAA game (like Diablo III) will have a AA game come out at the same time to compete with it (Torchlight II.) In a lot of cases, like Torchlight II and Call of Juarez: Gunslinger, the AA game is actually a far superior game to the AAA games its competing with. ;)
Sometimes the sequel to a AAA game is a AA game, I'd say that's the case with Wolfenstein: The Old Blood.
Some games, like Portal and Portal 2, straddle the line. But I'd slot the Portal games as AA.
What I like about these games is that they're immersive, without being overly long or tedious. You can play through Portal in a few evenings, without feeling like you're missing out on hundreds of side quests. The gameplay is tight, fun and innovative.
However, if you have a friend who likes first person shooters, you could play through one or more of the Gears of War games in cooperative split-screen mode. I hate, HATE, HATE playing FPSs on consoles, but I had a blast playing Gears in coop. It was the first console FPS I'd ever played where
* the gunplay felt good
and
* I didn't find myself longing for a keyboard and mouse after two minutes of play.
Indeed, the combat works really, really well with a controller.
I don't know how the game has held up over the years, but it was lots of fun back in the day.
If you like, change FPS to "shooter" everywhere it appeared in that comment.
Minecraft was also a great achievement in terms of game design and gameplay, yet had simple graphics, and consequently was easily moddable, which greatly contributed to its popularity and success. But is was considered "AAA" when it was released, and is it considered "AAA" now that Microsoft bought it (even though it's essentially the same game)?
So how important do you think fancy graphics are to the definition of an "AAA" title, versus accessibility (in terms of how many people can play it because of its lower hardware requirements, and how many people can mod it because of its graphical simplicity)? And how important are game design, gameplay, popularity, making money and other issues like moddability to the definition of an "AAA" title?
Another way for a game to achieve easy (but more limited) moddability without limiting its graphical complexity is to support advanced built-in tools for user created content (like Spore for example, which has advanced built-in specialized tools as opposed to supporting simple generic third party tools).
Subsequent versions of The Sims had much fancier graphics, and much more advanced built-in content creation tools (like create-a-sim), but that made it harder to create content outside of the game (because objects were 3D meshes instead of 2.5D sprites, and texture maps for character meshes were not nearly as simple).
The original Sims 1 team (which I worked on) only had four core programmers, but it was developed over many years before the point that EA bought Maxis and put more people on shipping it. So The Sims 2, 3 and 4 were much more typically AAA-ish, and had vastly larger teams working on them. (The Sims Studio became one of four major sub-divisions of EA.)
I think small indie teams would be better off focusing on game design and gameplay instead of fancy graphics.
(Fun anecdote: I'm from Russia and I didn't know English when I was a child. I had no idea what "save game" means so I started Crash Bandicoot 3 from scratch every time. Imagine my surprise when I realized how saving works.)
Reading this made my day, it's the exact same rule I try to apply to my own effort estimate, to the letter. I was 100% convinced I came up with it myself, but now I'm starting to think I may have (unconsciously) picked it up from someone else at some point ;-)
congrats!
[1] - https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
[2] - http://all-things-andy-gavin.com/2011/03/12/making-crash-ban...
Reminds me of these rules:
- Multiply by π for small, known teams, doing a new job,
- by π^2 for unknown teams,
- and √π for known teams who have already started, know their work and have a good track record.
From http://alistair.cockburn.us/The+magic+of+pi+for+project+mana...
The biggest problem with making games is the fact that there's no end goal of "Done." It's just a vague point in time, really. Is it done when you've made 10 levels or 11? Is it done when you've added 10 power-ups or 11, or 15? In a movie, you can't make the thing 50 hours long, no one would watch it all. But for a game, 50 hours is now considered medium sized, compared to MMO's and MOBAs that offer hundreds of hours of time to play.
Scope creep is the biggest danger in the games industry. Reading this update, where they talk about going from 2D to 3D, my heart broke. That's such a major change, and as he writes, such a major uptick in difficulty, it was the beginning of the end.
Terry Cavanaugh [http://distractionware.com/blog/ ] gets scope right. Valve gets scope right. You can tell when it's done right because the pacing of the game feels damn near perfect, like Half-Life 2: there's little down time, and you're always moving forward, even if yer not always shooting.
I feel bad for the Woolfe team, but they clearly had rose colored glasses on. There's a very good reason modern console games cost at least 8 figures. Hell, even with 8 figures of budget, many big name titles aren't even that good. The games industry is a harsh mistress. Like judging what's funny for a comedian, judging what's fun for a game developer is the toughest task they have.
What is your definition of AAA game? I believe Minecraft was created by 1 person (or at least started). I consider Terraria to be a AAA game and that was made by 3-4 people.
http://www.quora.com/Engineering-Management/Why-are-software...
http://www.quora.com/How-did-game-developers-pack-entire-gam...
There are a lot of $10 games that will entertain for 4-5 or more hours (even excluding the outliers like Terraria). I'm surprised that the developer was surprised at the perceived value of their product.
That said, he's right that the market for indie games is ridiculously saturated right now.
For example something like Ori and the Blind Forest, not exactly indie but a $20 title with amazing graphics and sound and around 6-8 hours of bug free gameplay.
Why can't you do something like "Game on Rails", where you set up a basic framework that has all the stuff a game normally needs, and then you only have to layer your assets and logic on top of it?
Do game devs already use something like that and still have these delays?
With that said, a lot of great (albeit typically somewhat simple) games are made with frameworks. When I when to a few game jams back in college, we typically started with something so that we could have a "complete" game by the end.
No one of those features stops you, but you get a "death by paper cuts" effect, because you eventually hit a mine that requires original technology to be written - most commonly, something to do with collision code. A good team led by a competent producer is able to figure out how to get the right effect within the budget, but it's never an easy process, and game productions have a habit of "pitching the moon and shipping with swiss cheese".
I think if you are making a 3d game you haven't thought things through.
Also there is a parallel between your "add one and increase the unit" and the estimation of what kind of manpower you need to take an defended objective. The wisdom here is basically the same: If you are facing an objective defended by a squad, you will need a platoon to take it. If you are looking at a platoon dug in to the objective, you will need a company to take it. An entrenched company needs to be uprooted by a battalion, et cetera.
It's from this (The Mythical Man Month as you mention, and the estimations the infantry taught me) that I have built a kind of mental model for estimating things, that ends up being sort of universal like the 80-20 rule.
For AAA games, modern, high-end systems increase the difficulty of providing a product. Modern development tools help, but graphics demands and expectations are inexorably growing. In a world where animating reflections might be a full-time task, 6-10 people can't even count on developing a trailer for a AAA product.
In response, then, indie games. Why the rebirth of pixel art and simple, geometric visuals? Not because it's 'retro' or 'clean', but because it's easy. Procedural generation, low-poly graphics, and user generated content aren't popular because they produce the best products, they're popular because they're all decisions that slash the number of employees you need.
Woolfe's mistake was setting out to make their game as good as it could possibly be. For an indie team today that's simply not possible.
To paraphrase your producer, "3 years = Duke Nukem Forever".
But game programming is like architecture. There's so much more to do.
I didn't know CB had such a small team! Props!
1. I know this, I have done it before in this codebase. Estimate is accurate, multiply by 2 to account for watercooler talk, documentation, and other non coding work. 2. I know this codebase, I have a pretty good idea of what to do, how, and where. I have walked trough the code and can't identify any major roadblocks. Multiply by 5 3. I don't have an honest idea. Multiply by 20, and make it clear that it's a guesstimate at best. Usually a better estimate can be given after working on it some time.
It's still off more than I like.
People often don't believe me, some reason being that some developers really deliver on time and sell it as finished but then having the rest of the team fixing bugs and working around strange APIs for months. Often it's just that they also haven't experienced the pain of developing something of reasonable scale and stability.
No man, these are not tears, I just got something in the eye.
It reassures me that kickstarter is actually being used to fund new things, rather than just as a marketplace for existing products, where you don't even have to have found any capital up front.
I hope that backers take it the same way. New stuff is risky by definition - and KS has funded some pretty major successes on risky projects too (Oculus).
It may not sound like much, but it is a benefit. I for one got a real kick out of seeing my name in Broken Age's credit roll.
I've backed quite a few Kickstarter projects and so far, none that were successfully funded have failed. Some still might and that would be disappointing, but I wouldn't regret backing them in the least. I have "bought" the fun of being a small part of something and watching things develop.
Not to pile on, but this was very surprising to me... how could you not know that this would have a major impact?
The author explained more or less. Inexperience.
That message is a LOT harder to get through than it seems.
Or, put another way, "Security is not a feature the business needs at this time in this PII-heavy project."
I don't think I could explain it as well as Dave Thomas says it, so here's a link to his fantastic keynote: https://www.youtube.com/watch?v=a-BOSpxYJ9M
As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.
The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.
However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).
In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.
That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).
Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.
What I don't like about velocity is that it encourages the gamification of the process. Developers start caring more about their velocity than the quality of their code and before long nobody has any clue of the big picture and the project starts going down the drain.
Working in the video game industry, I see the striking difference between playing games and developing games first hand, every day :)
It's kind of like when some of the first 3D games came out, modelers would model a brick then build a wall out of them, instead of just modeling a brick wall other ways, like putting a brick texture on a regular wall. They probably just couldn't come up with a good way to 'cheat' 3D collision detection that worked for them. Approximating is a huge part of game algorithms even with the power of today's hardware.
Jumping over fences, AIs chasing over 3d terrains, making sure people don't get stuck in random stuff. Everything needs weird edge-case stuff that's not in a generic physics engine.
Perhaps they should've first made a 3d game with 2d physics, those games look great and the overhead is much more manageable. But hindsight is 20/20 and from what I've gathered they actually got really close to a great game.
Exactly this... Pareto principle (applied to time) is really relevant in this case.
Proper simulation, or any kind of complex machinery working behind the scene rarely adds a lot of value to the resulting game (sadly). And moreover, I'm certain that relying of cheap tricks is the greatest virtue in game development. And there is nothing derogative or ignoble about that. Knowing where to cut corners is an extremely valuable skill, and it requires a lot of intelligence, experience, and careful planning.
Computer games are a lot like real-life magic. The best results are achieved if you do cheap tricks, but you do them well..
This is harder that our case because it involves gameplay, so there were some naiveté from their part but I can see how from an abstract perspective it can be understimated.
Anybody starting a major project will be ignorant about some important things. It's impossible to do anything interesting and know everything up front; if you could know everything, then that would mean it had been done a zillion times before and therefore not be interesting.
There's also a strong selection bias. The kinds of people who don't take chances? They don't become entrepreneurs. They don't bet years of their lives on projects in hit-driven industries. Those who do take chances already know that so many of the things that previously seemed impossible or dangerous to them worked out to be fine.
So nobody should ever, ever, ever not start something because they don't know everything. The trick to successful entrepreneurship is to test your big risks early, so that your failures are small and recoverable, rather than late and fatal. Here their mistake wasn't underestimating the impact of 3D. It was in not testing their assumption before the public launch of the Kickstarter.
There are a lot of people who spend lots of money doing something in a stupid way (look at big software companies), but even they have an underlying reason: it's difficult to pick good programmers and value them accordingly unless all your managers are also programmers (and who picked them?).
When you say, "The normal approach to X is stupid; we're going to do things differently," you have to understand how the normal approach came about so that you can avoid ending up there yourself regardless, and also so that you can avoid whatever problems it adapted to avoid.
There are situations when assuming by default that other people are reasonably intelligent is a bad or dangerous idea--while driving, for instance, or during basically anything involving casinos or Black Friday. But when a market governs a motivation as powerful as money and is sufficiently discerning, you'd better start really questioning whether those people are actually stupid or you just don't understand what they're doing.
There might have been a problem with expectations. 2D Games sell level design and platforming. 2.5D games however are often done with excellent combat.
No one complains that Super Mario 3 has horrible combat. Of course not, its a 2D Platformer. By changing from 2D to 2.5D, everything about the game changed. From customer expectations, to platforming, to collision detection.
2D to 2.5D looks like a simple switch. It's not full 3D and it is a natural extension to 2D games. But really, so much changes that it was definitely a mistake for them to attempt to make that switch mid-development.
You and every other developer making the transition from SNES to PS1 in the mid 90's.
"At first we could not believe that our “baby” was not more successful, in our emotions we started looking for explanations not related to the game. Maybe gamers are just spoilt brats, bashing on everything, maybe there is an oversaturation of indie market, maybe all the free-to-play games by big studios are giving players a false sense of value. How could less than $10 be to expensive for a beautiful game like Woolfe? How could this be our fault? "
"Of course none of the emotional excuses above are the reason of our mixed steam rating. We can only blame ourselves… "
It's good to see someone excepting the fact that their game just wasn't good enough. Also nice to hear someone admit what a cop out blaming customers or the market is.
If anyone is motivated enough, it would take just 500-1000 people who would chip in some spare change to make this open source (I'm not interested in any of this, before anyone suggests it - just hinting to those mentioning 'open source').
How did this happen? Shouldn't that money have been allocated earlier? Did they spend every dollar thinking that this is the dollar that turns everything around.
Maybe I just don't get the mentality of those looking to fund projects on Kickstarter.
And as the previous poster mentioned, how do you not put this money aside to reward people who gave you money?
It sounds like they are living through a train-wreck moving in slow motion that will last a few months - and perhaps much longer.
But there's a lot of 'artbook' and 'wallpaper' and 'soundtrack' stuff. i.e. 100% of things that they already have. This project on its kickstarter already displayed lots of art and wallpaper material, and they launched the game obviously with a soundtrack.
In short, shipping that is going to a local printer and asking to make a booklet or a wallpaper, in color. They give you a price and you inflate it by 10x. Wallpaper and booklet costs $3 to print, add a soundtrack and $3 in shipping (average, some will be 50c, some $5), and turn it into a +$25 reward. Get 1000 backers like that and you're netting close to $20k for relatively little effort. Even some ridiculous overhead and you still net $10k for stuff you can pay a highschooler a few hundred bucks to create. That $20k can pay a 3man passionate noodle eating team that's working on this parttime for months, and that's with a thousand backers, this team had a few thousand, actually I took a look and it seems that rewards are about half their campaign. It's really scrappy but it happens and it sometimes really works out.
Definitely not something that works for every project, in fact I see it fail more often than not. But it's not a priori a bad idea, I just don't think everyone thinks it through. Some devs create games and then have a mini comic booklet as a reward that increases the price by $5, or hell just include it for free because hey, kickstarter. That requires writing, printing and shipping, the costs don't make sense at all.
The OP generalised by saying they wished game devs would simply never do merchandise all together, even though it looks like this project raised half its budget from rewards, and I think we both can guess they spent more than half of their time developing the game, and even though one can find examples where merchandise was successful.
I also think you missed the point which is that they actually shipped the game, and made the merchandise. They just didn't end up selling enough and went bankrupt, preventing them from shipping the merchandise. If they'd earmarked the funds or actually sold as expected, none of this would be a problem. i.e. merchandise wasn't the source of their problems.
I mean let's be clear here, they had a bunch of artwork laying around already (we know this), artwork that ended up in a wallpaper, and they had rewards of $30 - $50 for the game + some digital stuff (e.g. an mp3 of the soundtrack) + getting this artwork mailed to them. Oh and the game was just $10.
So in effect they have a PDF on their computer, and they're charging $20 print and send it to you. (this isn't even the booklet, just the wallpaper, the booklet+wallpaper costs $40 extra ontop of the game).
Now you find me a scrappy indie game dev that doesn't want that, or can't handle it, or can't make that profitable. Don't act like that is rocket science. You telling me if you're running a small shop of 5 people and you're so scrappy you'll risk bankruptcy 6 months later, that printing and shipping a PDF for $20 to 1000 people isn't workable? That generating this $20k revenue (1/3rd of what they pulled in) from a wallpaper, can't be done for less than $10k everything included (printing, labor, shipping).
I mean hell I can print 1.000 A3s for less than $1k without much effort, already found a quote for that, and it'd be printed within a day. Again, they said they had everything printed and ready, that's not the issue here. Then I reward myself $3k for an entire month of effort of shipping pieces of paper (big deal, could do it in a week), and I spend $3 to mail 1 piece of paper each. I still make $13k, enough to pay a developer in Belgium for 3 months. And considering I spent $3k on the labor, I might as well outsource it to some highschool intern who gets a ridiculously royal salary of $3k for barely a week's worth of work. And I'm being pretty generous with the margins here, even if you nitpick here and there, and add some other factors, it's still a good deal. In fact I doubt they regretted their decision, merchandise was half their campaign revenue.
Now I KNOW there are companies that offer ridiculous stuff. 1) offer things they haven't made yet (like a mini comic to go along with the game, which requires a lot of time spent) and 2) things that make no economic sense (a $20 reward for a 3d printed game thingy, which costs $15 to make and $10 to ship, and time spent). And that this makes no economic sense and often fails.
My point is that while merchandise isn't always a good idea, it definitely can be, and that it probably was for this company.
As for a 'book order', it's just a booklet made out of a bit of paper, at a quantity of 1000 of them they cost about $1 each or so. Remember they're part of a $40 reward which has a booklet, wallpaper (combined <$2) and digital rewards like a soundtrack. Hardly unfeasible, this is on top of the $10 of the game's price.
1000 boxes / envelopes stuffed, addressed shipped, through customs and to clients - OMG so much pain, so much time.
Lots of it was "ready for printing", but not actually printed yet.
The purpose of the campaign was to develop and ship a game.
They have succeeded, and in the process went bankrupt. Which means they won't be able to even pay creditors, lest investors.
In that regard they succeeded. The game is finished, it's for sale, and the backers got their game.
But the sales were also disappointing, and so they declared bankruptcy.
The issue here is that they created stickers, dvd crap, soundtracks etc... Kickstarter backer rewards. And they can't ship them as they're bankrupt. The problem obviously is that they didn't earmark funds ahead. I think that's disrespectful towards the backers and it's a genuine complaint, but I don't feel it's very significant in the scheme of things. Kickstarters know the risks. And the creators of the game put their heart and soul into it and ended up bankrupt, yet did deliver the game. I think that's a fair compromise for the backers of the game, even if they don't end up getting their rewards, like an artbook or wallpaper which can be pretty sweet but I doubt anyone will lose sleep over it, while the creators must've lost a lot of sleep going through a bankruptcy.
So this notion they raised $50k for 7 people to build a game in two months isn't really the case at all. Beyond that, your point on merchandise rings true but it depends on context. A soundtrack, artbook and wallpaper usually isn't a big deal. After all, the game has a soundtrack regardless, and they'd already produced tons of artwork in the process of modelling, you can see it on the kickstarter. The effort is printing and shipping it. But if someone is giving you a $20 premium to ship him a PDF you already have on your computer, would you say that's bad business? Not really, any smart indie will pay some highschooler $250 to take care of it, a small price to increase your budget by $10k or something to that effect. The issue is that some kickstarters go way overboard, and the reward/effort ratio plummets to below their IRR or even below 1. So it really depends, in this case I think it wasn't a bad decision as they promised rewards for things they already had laying around, they simply should've earmarked the funds.
I suppose that $20 for a PDF could be good business. I'm not convinced it's necessarily good business. It depends on the goal. If the business is shipping PDF's then it's obviously good. On the other hand, I suspect the minimum cost of fundraising is non-linear: that raising $10,000 requires more than 1.0% of the effort required to raise $1,000,000. But even if it's easier to raise $20.00 500 times than $10,000 all at once, if $10,000 ain't enough it ain't enough.
For everyone interested, check out gameplay footage from the beginning of the game: https://www.youtube.com/watch?v=PGadziSy_kM I hope my failures are as beautiful as this.
"What about our Kickstarter backers?
The people that believed in us from the beginning? People we made promises too. People we have let down. Even worse… people we will not be able to give the full rewards they invested in.
The crazy thing is, that we have most of the rewards ready for postage. All the backer stickers and letters of enlistment just need a stamp. All the poster sets printed, signed and ready. The artbook is ready to be printed, the soundtrack is ready for distribution, the DVD case is ready for production. But we have literally no money whatsoever to pay for stamps, let alone print the artbooks and dvd-cases."
This could be a good closure. From comments:
"Fredrik Waage: Please honor your backers who believed in your game by releasing the DRM-free version like you promised so linux backers (hopefully via WINE) and ppl who don't like steam can enjoy your game."
Or maybe even go open source?
While that is the ideal way to close up a failed start-up (in my opinion anyway) I don't believe they would entertain that considering they're trying to sell the IP.
I hope they try again and apply whatever lessons they learned
http://store.steampowered.com/app/281940/
Remind me of Alice, which had some beautiful levels.
I suppose I should count myself fortunate that I didn't Kickstart Woolfe.
Seeing these failed projects is grim reminder that just because you back something doesn't mean it will be delivered.
With the bankruptcy, it's questionable where purchases of this will go to, so you might want to keep an eye on the game's Steam forum.
(There was another game, the name of which escapes me, that had a similar issue, with it getting sold cheap, and the money wasn't going to the creators. I think it was this year's Steam sales, if anyone else recalls the game.)
Really? That's what you're posting when a group of talented artists see their dream shattered?
Sarcastic quote marks should be reserved to make fun of something someone actually did ... the person you're responding to said in fact that he didn't kick in on this project.
How, exactly, was their "dream shattered"?
They raised money that (they thought) was sufficient, and got to work independently on a game they loved. That's more than a lot of people get. Apparently the game wasn't very good. No one is entitled to financial success.
It doesn't help the perception that there are a lot of companies out there that seem to be using Kickstarter as a service for basically taking pre-orders though. Often I've thought "Why the heck is that big company with lots of money doing a Kickstarter? Isn't Kickstarter for people that wouldn't have the money to fund the project at all?".
A whole other debate, I know.
I mean, I know Alice didn't sell well, but surely someone pointed that out to them?
While I can personally understand this reaction to having trouble, it's not healthy nor is it fair to cease communication in this way. A lot of promising projects announce difficulties by falling silent, including Limit Theory, which I was looking forward to seeing realized some day. Maybe crowdfunded projects need to shift to a mindset where it's expected to be upfront about problems.
> So with a heavy heart I have to communicate that as of now the IP of Woolfe, all of the assets and source code is now for sale
I said it before, but I'll gladly say it again: backing a Kickstarter project is a bet, not a pre-order. When I back a project, I calculate the odds and place my money accordingly, full well knowing it could be gone. As long as makers honestly tried to achieve something, I'm fine with failure.
Not everybody sees it that way, though. It would be nice if new games on Kickstarter would include a pledge for their IP to enter public domain in case the project as a whole fails. Because the alternative being played out here is most likely not very helpful to anyone, including the defunct studio.
I wonder if more experienced game developers could have recognized the failure much further down the track and pulled the plug (or taken on a lot more funding?) before it took the company under. I also wonder, if this undertaking had been made in the US, would the outcome have been any different due to different... I dunno, funding laws or more available funding from traditional investors?
Was the completeness of the failure of GRIN down to the fact they spent way more money than they had trying to prove a point (don't need to do pixel or highly stylized art) ?
The game industry is interesting to me because of the nature of the problems they have to solve, but it is so damn brutal I don't want any part of it.
They could not push out Vol 2 nor the Kickstarter rewards as they pretty much ran out of money.
I actually wonder if in such cases Kickstarter shouldn't back the shipping or demand getting the a hold of the rewards and try to some how compensate the backers.
Heck with the amount of projects which fail they can pretty much have a monthly loot crate going on with the crap received from failed kickstartups...
Tho if they file for bankruptcy i wonder if giving the rewards away will not count against them as they devalued their fixed assets value just before or after filing for bankruptcy.
I think the lesson here (and this one really is probably important for entrepreneur types), is getting funded really should not be viewed as an achievement. It just means the stakes got higher.
The people that believed in us from the beginning? People we made promises too. People we have let down. Even worse… people we will not be able to give the full rewards they invested in.
The crazy thing is, that we have most of the rewards ready for postage. All the backer stickers and letters of enlistment just need a stamp. All the poster sets printed, signed and ready. The artbook is ready to be printed, the soundtrack is ready for distribution, the DVD case is ready for production. But we have literally no money whatsoever to pay for stamps, let alone print the artbooks and dvd-cases. "
I understand you failed. Find money for postage though? These were Kickstarter investors? You have money for a bankruptcy attorney? Just shopping around for a bankruptcy attorney can save thousands? (Maybe you are doing the legal in house?). My point is the Kickstarter Backers will appreciate a small gift of gratitude, and just might fund you in the future?
I think most small companies know they are going under weeks--months in advance? I knew months for myself. There's nothing illegial about keeping a small fund for the last days of a business.
Good luck, and with Capitalism, and all its risk-thank goodness for Bankruptcy. When I was younger, I didn't quite appreciate bankruptcy laws. I now keep a close ear out for any changes to bankruptcy laws.(There are entities that want to change the federal statutes. I knew the Obama administration wouldn't let lobbiests touch them. I worry about the next administration?)
If I was to do it over again, I would have incorporated every business I ever started? I might have even incorporated my legal name right out of college--if legal?
(As to why they upvote them, I'm guessing it's because often we learn more from failures than from successes, and usually you don't hear about the failures as much as the successes).
Think about when you first started learning to program: write code, attempt to compile, FAIL, make some adjustments, FAIL again, make more adjustments, successful compile. Execute, FAIL, make more adjustments, etc. This rapid failure/remediation cycle is somewhat unique, as it opens us to try new and innovative things without fear of failure: failing is just part of the learning process. Since failure is "cheap", we tend to gravitate to sucking up all information about failures, in the hopes of learning from it.
Now think about most other trades: cooking/carpentry/plumbing/etc. When you fail, there are material losses. So that learning curve is expensive, and you often apprentice and learn from someone doing it correct, rather than trial and error (though you get a bit of both for sure).
I suspect this is the same reason when really interesting Post-Mortems are posted, they shoot up, and lots of positive commentary around them. We all consume it, in hopes they prevent us from writing the same one in the future.
Success stories usually won't include any dirty details, any shabby deals or the full naked truth of the events that underwent. No A-list actor will talk about the producer dick he sucked. You have a reputation to maintain after a success.
In a failure on the other hand, you probably are at the rock bottom, have nothing to lose, no one to be afraid of.
Game development is so incredibly hard. It feels like a winner-takes-all game where the very top 1% have everything, and the rest have almost nothing.
It's a shame that this studio has to fold. The game looks pretty good. You don't get to that point without having incredibly talented artists, programmers and managers, without having a team that's working pretty well together. And yeah, their reviews on steam aren't perfect -- but to me that doesn't seem that terrible. Everyone stumbles before they really catch their stride.
It sounds like they just ran out of money, really. They ran out of time. They weren't given a real shot. What a shame. I see startups pop up all over the valley here that don't even have a tiny fraction of the ingenuity and talent of this company.
It's a shame that our economy doesn't value art like this more. A real shame.
Now even if you end up making the 10% that isn't crap, you have to fight hard to get any attention. There is a huge amount of hustling involved.
Even when you are an unprecedented genius, you will suffer immensely for lack of business and marketing skill. Where would Einstein be without Adler? Where would Newton be without Halley?
That's just the way the world is (and has been, since time immemorial).
Could we Kickstart a project to drop it all in the Public Domain?
PG has actually written on this subject: http://www.paulgraham.com/die.html
Basically, if a company stops communicating, it's almost a sure sign that it's in its death throes, and if a company is doing well, it's going to try to reach out as much as possible so they can show off how well they're doing.
Long answer: depends on their circumstances in bankruptcy court. The company could potentially reemerge from bankruptcy with the creditors owning it. Or the court might rip the company apart and sell off assets to pay back creditors. The money Steam owes the company is just another asset.
"In the video game industry, AAA (pronounced "triple A") is a classification term used for games with the highest development budgets and levels of promotion.[1][2][3][4]" https://en.wikipedia.org/wiki/AAA_(video_game_industry)
It should be obvious from this definition of an AAA game that 6-10 people in a small indie game studio can't make a game with 'the highest development budgets and levels of promotion'. It requires lots of $$$ and other resources, which an indie game company almost never has.
"Wisdom begins with the definition of terms." - attributed to Socrates
I think game development must rank way up there with restaurants in terms of business failure rates. It might even be worst than restaurants but the data could be impossible to collect.
Why?
Because restaurant failures are a matter of public record while game developers more often fail privately. The data simply evaporates. It's a really tough business, even with money.
For the most part lack of business experience and idealism or hubris can play a big role in this. The good old "the market is <insert big number> billions, if we only grab 0.1%" fallacy.
To be sure, hubris and doing something because you love it has it's place and fortunes have been made because of this. That said, the cold hard reality is that the gaming industry is paved with the corpses of probably millions of entrepreneurial efforts who have tried and failed.
Generally speaking, for most developers, I think there's far more money in developing games for those who have cash to burn (whether successfully or not) than to try to create the next blockbuster.
As a small data point, years ago we were approached by a company to develop an iOS children's game for them. Lots of animation, sound, graphics creation, etc. They had no experience in software development at all. They wanted to convert this low budget cartoon character into a game because they convinced themselves they'd make millions with an app.
We told them it would cost $50K to $250K (or more) and months of development depending on specs. Of course, they had no specifications. It would be impossible to understand costs without a solid spec.
We also recommended they DO NOT develop this game and stick to their core business. In fact we pushed back hard on this point. I sat down with the CEO for a couple of hours to explain failure rates, challenges, issues, etc. They needed to fundamentally transform their company and were not equipped to do so at the time.
I got an angry email from the CEO telling me we were crooks and how they found a company in India that could build them the entire game for just $15K in three months. What the hell did I know? Right?
A year later, almost to the day, I got an email from the same CEO asking if we could meet. We did. He revealed they burned the $15K and got nothing more than a slideshow made with templates. They then found a larger company (also in India) and burned an additional $50K and got something that was buggy and wasn't even playable. By the time he asked me for a meeting they had burned through over $150K trying to have their game made and had nothing. They couldn't even submit it to the app store. They were nearly out of money.
You could probably guess what happened next. He asked if we could fix it for $20K. I explained I'd be surprised if anyone would have any interest in touching that code-base for any amount of money. And, no, $20K couldn't even touch building the app they envisioned a year earlier. I repeated my recommendation to stick to their core business. Which they did. After learning an expensive lesson.
Anyhow, long story to relate one type of scenario behind game development where ignorance and hubris meet a pile-o-cash and a bonfire follows.
Sorry to see the Woolfe team fail. I don't think I am being a pessimist when I say this is far more likely to be the outcome with games. Kudos for trying. Move on. Quickly.
Your point regarding putting your efforts into building a piece of software for someone else rather than trying to do it yourself is sound advice, but people will still disregard it even if it defies common sense. A tiny part of those will end up becoming very successful, and those are usually the people we hear of later.
It would be interesting to see numbers on failed startups (within both the gaming industry and otherwise).
The angle I forgot to add is that Apple has, in my opinion, destroyed the ecosystem. The race-to-the-bottom they promoted created a situation where a game development team could very well spend a million or more developing and game and have to give it away on a hope and a prayer.
And "hope and prayer" it is because you have to dump even more money into marketing and hope it catches on so that your freemium or in-app-purchases model generates enough cash to recoup your investment and make money.
Not everyone is going to get a hit at the level of "Clash of Clans", yet everyone is now expected to produce stunning graphics, animations and game-play, give it away, create a back-end infrastructure to support hordes of free players and hope the game engages enough to generate revenue thorough IAP or ads.
My guess is one could do better gambling with a million dollars in Vegas than creating a game with that money.
My take is that a large proportion of game developers are actually game addicts or view it as their artistic calling.
So reason doesn't really enter into the make game / don't make game and scope-creep decisions.
1. I'm shooting from the hip, because I have zero game dev experience, and I know even know if this is possible, let alone whether it even makes sense (are 8-bit, etc. games more simple to build than those with modern graphics?).
Hell, to say the truth although I'm a developer, when I paid something on Kickstarter I also feel that way...
You've misunderstood what actually happened, the game had a different budget and timeframe.
I wonder if the developers could possibly not have heard of them?
There seemed to be quite some money in funding for artsy games in Belgium. Personally, I love games and I think both that and Kickstarter funding are needed to suppor more experimenting off the beaten path.
Really? Did anyone not think that would be huge?