It really depends on the people doing the work and tons of specific details about the game that you haven't provided, but it's a fairly safe bet that the units will be "years."
Josh PetrieMember Since 11 Jun 2003
Online Last Active Today, 02:03 PM
- Group Moderators
- Active Posts 7,847
- Profile Views 27,075
- Submitted Links 0
- Member Title Moderator - For Beginners
- Age Age Unknown
- Birthday Birthday Unknown
Expert Community Member
Outstanding Forum Member
Blog post contributor
- Website URL http://joshpetrie.net
Posted by Josh Petrie on 30 April 2016 - 12:12 PM
Website / forum development. Maintaining, posting, moderating, everything.
You don't need to do this on day one.
Marketing / Press Releases / Setting up for Funding Push
You can do some of this early, such a preparation of all this, but don't actually start doing it on day one, because that's way too early.
I thought you had no money. Finance what?
1. Going out to draw customers into the forum to start discussions about what the game should be like.
2. Polling those customers over, and over, and over until we've boiled down exactly what they're looking for.
You've mentioned this a few times, actually. I think this is a bad idea in general, and certainly not something you should be focused on doing so early in the project. There are, frankly, millions of people who have opinions about what a game "should be like" and most of them have no idea how terrible or impractical their ideas might be. You're going to waste a ton of time sorting through that feedback (as well as open yourself up to potential legal hot water; this is why most game studios trash unsolicited "game idea submission" mail without reading it or opening it -- I've seen this done in person several times). Besides, it's too early for that kind of polling even as a method of gauging the wind direction. You need to spend some time alone with your initial partners and develop a concrete game idea and some practical implementations. You shouldn't just go out there and announce you're making a game and ask what people want it in. That way lies madness.
I have anti-cheat system in mind that will pair with any of the major AAA anti-cheat engines and AAA games.
But you're not a programmer and have no technical background as far as I can see, so your ideas about anti-cheat systems are probably useless. Keep in mind that anti-cheat is a pretty trivial problem. The problem is not protecting against cheating, the problem is protecting against cheating while still having a game that is fun and feels good to play. These two are odds and often making a game feel fun and responsive involves making tradeoffs in security (for example, not validating every single client movement input, because the resulting latency is unacceptable; this is reasonably common in many MMOs).
If I can get the game going, the existing developers would get a profit share in the new business that would dwarf the initial game sales of the Survival game by several orders of magnitude. Example, in any FPS AAA game, the cheating is usually pretty rampant. Anywhere from 5-20% of the player base either has cheated, is cheating, or will cheat at some point. With this system I can get it down by ninety percent to 0.05% to 2% of the player base. The best part is, you can integrate it into any game that uses AAA anti-cheat. So this system could be in COD, BF, The Division, etc, etc, to provide customers an almost "cheat free" experience. It does require players to pay for the program and pay a monthly fee though.
There's a lot of pie-in-the-sky handwaving here that I think hurts your pitch more than it helps. I strongly advise you abandon this aspect of your pitch until you acquire yourself an engineering lead with the technical chops to reign this in to the realm of practical reality, if you actually try to recruit engineering talent with this you'll only be weakening your position.
Once it is released, it's literally so simple of a concept, you'll slap your head and say "jeez why didn't I think of that". Because of this secondary business I'll be 100% committed to the first one succeeding because without a "proof of concept" of this anti-cheat working in OUR game, there's no way any other AAA development team would even consider it. But if we can prove it works in OUR game, the sky is the limit. Every AAA anti-cheat and AAA developer can use our new anti-cheat.
If it's literally that simple, than people have already thought of it and already determined it's not practical for games. But good luck regardless. I think this is far more insane of a business plan than your initial game pitch, under the circumstances.
Posted by Josh Petrie on 29 April 2016 - 10:15 PM
I haven't shipped any games yet. And I understand that might be a deterrent to some. But if they understand the vision, they'll get why what I'm saying is crucial to the development of the game.
Failure is a big initial sales release, only to have the game crater into the ground as a failure at the end.
But they lost their customer base for future titles
You don't build successful companies by making your customers so angry they won't come back for more.
I really don't know how many people I need
The team on Day 1 will probably not be the same as the team on Release Day. Figuring out how to compensate those who "helped" but didn't "stick with it" is going to be a huge part of how much or how little legal trouble we will have
Unreal, Cry, and Lumberyard would do just fine as the data can just be loaded from outside. But going on with others, I'd still make my own engine. The code base won't be nearly as massive, and the engine would be designed specifically for the game. Which means that the Client is just a viewer that sends command buffers. And the Server handles all the logic. The server handles all the logic and sanity checks, which means that updating the game and bug tracing won't be such a bastard. You can log everything that happens, restart the server to apply updates, or dynamically change the world at run time
Posted by Josh Petrie on 29 April 2016 - 06:52 PM
What I bring to the table is industry and customer base knowledge
Okay, so how do you demonstrate that (or the value it brings) to a potential business partner? What games you have leveraged this knowledge to ship, and how can you show you did so? That's going to be one of the first questions anybody you approach is going to ask.
Before you say that's not worth much......WarZ Devs (failed)....DayZ Standalone Devs (failed)....H1Z1 Devs (failed). So you've got the gambit from CCC to AAA development companies, full of devs, full of marketing people, full of various other support people, that all failed. They didn't fail because they were bad coders, artists, and level design.
I'd be very curious to know what your definition for "failure" is, here. And why you think that (at least some of) those cited examples didn't have people with "industry and customer base knowledge."
What about this:
Posted by Josh Petrie on 29 April 2016 - 03:32 PM
What would you think of this? With no future equity changes allowed.Me - 51% equity, 10% profit sharing3 Programming Leads = 29% equity, 10% profit sharing each7 Programmers = 20% equity, 8.5% profit sharing each
Posted by Josh Petrie on 29 April 2016 - 02:18 PM
The structure of the company won't be "salaried" positions. It'll be based on profit sharing.
What you're asking people to do here is commit some non-trivial amount of their time and effort into building this game, purely on the hope that they recoup a significant amount of that investment once the game is finished and has generated some amount of profit (two things that very well might never happen). That's a huge risk on their part. Generally the kind of people who shoulder that category of are called entrepreneurs, not employees, and are working for equity, not profit sharing.
Of course it's still possible for that equity to be worthless at the end, but an unfinished game generates no profit. By contrast an unfinished game does still consist of IP and work that holds some to the owning company, and thus some value through equity to a partner. So the equity bet is the better one, generally (I still wouldn't do it, personally, but that's me).
The smart, safe developer will probably want the salary, because the smart, safe developer probably has a family, or hobbies, or rent that he or she needs to pay for and recognizes how frequently game projects fail to produce watershed profits. The smart, lives-on-the-edge developer will probably want the equity (or at least accept it) if they can be convinced that you have solid, workable plan and that the project is a good investment of their time.
The developer who is suckered in by the vague promise of "profit sharing" without really understanding the massive risks that involves taking on, without the ability to translate that investment of their time into ownership of results? That's not the developer you want picking out the rest of your developers.
My biggest fear is keeping them working on it, getting it accomplished in a reasonable timeframe, and what to do with the "this guy worked 5000 hours on the game" but "this other guy worked 50 hours on the game". When it launches, we can't bring everyone on board. 5000 hour guy is obviously in. But what do you do about 50 hour guy?
Talk to a laywer. If you go into this without establishing agreements pertaining to that for people to sign, you've already failed. Hereis a good place to start.
(If you don't have such agreements, which generally including assigning the rights to an individuals work over to a company or whatever, then when that 50-hour person leaves, if he wants -- such as if he's unhappy that you have decided 51 hours was the cut-off for profit sharing after-the-fact -- he takes all his work and work derived from it with him. All of it. Because he still owns the copyright, since you didn't have him sign an agreement that assigned you or your company the rights. Then you go down in a legal firestorm and that's the end of the that.)
Posted by Josh Petrie on 29 April 2016 - 01:29 PM
And if I randomly assemble a team without choosing the engine first..........I'll get 3 unity guys, 4 unreal engine guys, 2 cryengine guys, and 1 guy who works on some smaller indie engine.
Can 3 unity guys, 3 unreal guys, 2 cryengine guys, and 1 random engine guy all code on any engine?
Posted by Josh Petrie on 29 April 2016 - 12:59 PM
I was fired from the last position because I think
It doesn't really matter why you think you were fired, it matters why you were actually fired. Why was that? Were you told? How was your termination communicated to you?
I have no other career opportunity
This seems unlikely.
Should I quit software development ? am I that bad ?
This is not a question we can answer for you. If it doesn't make you happy, maybe stop doing it. If it does make you happy, keep trying.
Posted by Josh Petrie on 29 April 2016 - 10:52 AM
...you know this has been deprecated for years, right? So the fact that it misbehaves on modern systems should not be that surprising.
Posted by Josh Petrie on 28 April 2016 - 07:12 PM
Let's not necro posts from 2007, okay?
Posted by Josh Petrie on 28 April 2016 - 09:35 AM
In many games there are VC-Runtime executables
Most applications dynamically link to the VC++ runtime. Yours should too. This does not mean they are C++/CLI executables; they're usually plain C++ executables, but (functionally) all C++ executables require linking (dynamically or statically) to a C++ runtime.
"Visual C++" is a slightly inaccurate name for Microsoft's Visual Studio IDE. It's a tool not a language. C++/CLI is a language that was mainly useful for writing libraries to interoperate between C# and C++. You should definitely not use it to write your game.
Posted by Josh Petrie on 26 April 2016 - 12:13 PM
Also, any function returning a reference should almost always guarantee that reference is safe to hold without requiring the reference return be immediately copied (otherwise, just return by value).
With your example, one cannot write: result_type & a = SomeFunction(); and expect it to work reliably. Any subsequent call to SomeFunction, including one on another thread, will overwrite the static variable named by a.
Posted by Josh Petrie on 26 April 2016 - 12:04 PM
Many thanks for your advise. On my resume, could I still mention a team of 2 developers? or would it be best not to mention how many people, given how small the team is?
Posted by Josh Petrie on 26 April 2016 - 11:28 AM
Would an employer ridicule the idea of 2 people as a legitimate team work?
Nobody is likely to care that much one way or another, really, I wouldn't worry about it. Certainly don't add another person just because you think it would demonstrate some team management or interaction skill better (the only thing it demonstrates to me is that you don't know how to run a team at all, because you're adding people for the sake of adding people).
Posted by Josh Petrie on 22 April 2016 - 05:15 PM
For small games I'd recommend embedding it into the executable because it allows a smaller package.