Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Online Last Active Today, 02:03 PM

#5290084 Is it real?

Posted by Josh Petrie on 04 May 2016 - 10:38 AM

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."




#5289444 Question about Open World Survival Game Engines

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.

 

Business Transactions

 

 

Such as?

 

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.

 

Finance

 

 

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.




#5289375 Question about Open World Survival Game Engines

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.

 

 
Perhaps, but if they've shipped some games, what you're saying might also be precisely the reason they won't work with you. Since you don't have the requisite experience, you don't really know where the line is between good and bad ideas with respect to making games. It's very different to be in it, or have been in it, yourself versus seeing other games "fail" (accordingly to some arbitrary metrics you designed) yourself. It will be a significant risk factor for you.
 

Failure is a big initial sales release, only to have the game crater into the ground as a failure at the end.
 

 

This is a circular definition and thus not very convincing.
 
 
But they lost their customer base for future titles

 

 
Citation needed. Once customer is not a "customer base" unless you're making something insanely expensive and can be profitable selling it only once.
 

You don't build successful companies by making your customers so angry they won't come back for more.
 

 

True, but you cannot please everybody so every decision you make about the game will have detractors, no matter what (unless, again, your total customer base is so small that it doesn't matter). I've worked on large MMOs that, several years after release, still had large vocal communities of detractors and yet were somehow still very profitable. The people who complain and "quit" aren't all there is to the story. Remember that infamous screenshot of the "Boycott Modern Call of Warduty 4" (or whatever it was) Steam group where all it's user were "Currently playing Modern Call of Warduty 4."
 
 
I really don't know how many people I need

 

 
You need no more than four (you, a programming lead, and art lead, and a design lead). That's probably stretching it, too, you could definitely do it with three and maybe, maybe with just two people total. More than four would be biting off more than you can chew right now.
 
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

 

 
You won't have any legal trouble so long as you involve a lawyer. The issue is more that you will have trouble convincing anybody to work with you if the terms aren't favorable enough for them, not unlike any sort of compensation negotiation. They may love the idea, feel you're a trustworthy potential partner, and all that but there's always a price associated with that feeling.
 
You may find Undead Labs' breakdown of their profit sharing agreement worth reading; one of the reasons Jeff released it under a CC license was precisely so other companies would consider adopting it.
 
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
 

 

I'd say this is a bad idea (rolling your own technology stack), especially initially when what one really needs to build is a prototype. Any of the major commercial, off-the-shelf engines will be more than capable of executing that and for a fraction of the cost of rolling one's own. They will probably be more than capable of executing the intended final game as well, perhaps with some custom modifications to support specific edge cases warranted by the design. Cost in this context is measured in time, since nobody's getting a salary: turnaround time to profit generation is important. The longer it takes to get there, the less your time is worth because there isn't a linear relationship between time (and effort!) put into the product from an engineering perspective and dollars you get back out.
 
​I also think this is an oversimplification of what actually needs to technically happen.
 
In any event this isn't the decision the OP should be making, since it's far outside of his wheelhouse. It's a decision the fellow he brings on as his technical lead should make.



#5289353 Question about Open World Survival Game Engines

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:

 
I don't think you need that many people. I think you need a very small core team of partners who between them cover the abilities required to make some kind of functional prototype or proof of concept and you need to use that to leverage a funding source so you can pay the rest of the team (which consists of a makeup to be determined later, once you have a solid prototype and a better idea of what the hell is going on).



#5289327 Question about Open World Survival Game Engines

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 sharing
3 Programming Leads = 29% equity, 10% profit sharing each
7 Programmers = 20% equity, 8.5% profit sharing each

 

 

First, it's reasonable enough to classify equity as a percentage, since equity is ownership (of the company, in this case). It's not so reasonable to classify profit sharing as a percentage, because "profit" can be computed in many different ways. Your 10% profit and my 10% profit can be exceedingly different numbers in practice. Define what profit is, accounting-wise, how profit accrues, when it is paid out, and so on.
 
Second, 51 + (3 x 29) + (7 * 20) is 278%, so I don't understand your equity numbers. Similarly, 10 + (3 x 10) + (7 x 8.5) is 99.5%, so I don't understand your profit sharing numbers.
 
(And no, the point I was trying to make is that profit-sharing alone is a bad base compensation plan. I think it's a brilliant additional compensation plan, when clearly spelled out, but in the context of the project your describing I think you're only hope is to get people with salary (alone) or equity (alone), depending on the kind of people you need. Profit sharing (alone) is a fool's errand.)



#5289316 Question about Open World Survival Game Engines

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.

 

You may want to read this thread and this thread for related discussion.

 

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.)




#5289296 Question about Open World Survival Game Engines

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.

 
 

 

 
Well then you've failed at putting together a team. Recruit two or three highly skilled technical people for your lead types. You will need somebody to handle art, somebody to handle game design, and somebody to handle code and engineering. You can usually find people who are highly skilled at two out of three of these, thus two to three people (although sometimes you can get away with not having one of those three areas well-covered). With that core team, decide on the direction to go technology-wise based on your game concepts. This may involve evaluating and prototyping in several engines.
 
Then decide. Then recruit the rest of the team as needed.

Can 3 unity guys, 3 unreal guys, 2 cryengine guys, and 1 random engine guy all code on any engine? 
 

 

If they are any good, yes, they can learn the other tools.



#5289288 getting fired in software industry

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.




#5289264 Lol, IDirectDrawSurface7::Blt changes Aero scheme to Windows 7 Basic

Posted by Josh Petrie on 29 April 2016 - 10:52 AM

DirectDraw 7.0

 

 

...you know this has been deprecated for years, right? So the fact that it misbehaves on modern systems should not be that surprising.




#5289174 (flower blooming) done...code inside

Posted by Josh Petrie on 28 April 2016 - 07:12 PM

Let's not necro posts from 2007, okay?




#5289096 C++ CLI or native for game engine

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.




#5288786 Returning by value is inevitable?

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.




#5288782 Is two people enough for a team?

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?

 

 

 
Sure, it won't hurt to mention the team size. Generally you should focus on listing things that are interesting, cool or exciting about a project on your resume, but it's pretty easy to mention team size or at least the fact that it was more than just you in there.



#5288776 Is two people enough for a team?

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).




#5288212 Should you load assets/resources at runtime or compiletime?

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.

 

 

 
A resource doesn't magically shrink because you embed it into an executable.





PARTNERS