Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5291901 Display jpeg on a form with SharpDX

Posted by on 16 May 2016 - 11:48 AM

It could be because it sounds like you're just asking people to write code for you. What have you tried already? Can you draw a blank quad already? Can you draw a blank triangle? Anything? There are plenty of tutorials and indeed probably even some samples that come with SharpDX on setting up basic rendering and trying a colored triangle, which you can adapt to drawing a texture triangle and thus a quad eventually.

#5291874 Game servers?

Posted by on 16 May 2016 - 10:40 AM

I could search this on google but I prefer automated multiple answers hehe.



This is, for reference, quite rude.

#5291871 Best gaming platform in the future with marketing perspective.

Posted by on 16 May 2016 - 10:33 AM

To change my question a bit, well, which are the platforms which earn most revenue, today?


It doesn't matter. The revenue earned by the platform is the revenue earned by the platform vendor (e.g., Sony, Microsoft, Nintendo). You are not thinking about making a platform, you're thinking about making a game for a platform. 
The platform you pick will not determine how much revenue you'll bring in; the quality and success of the game you make is the key factor there. And unfortunately, there's no mathematical formula or flowchart to arrive at how to make a quality, successful game or we'd all be rich already. The only real factor the platform choice will have are market share and demographic related, and those aren't likely to matter to you because the ceiling of even the lowest-market-share platform is several orders of magnitude beyond what you're likely to attract as a customer base right now. Even if, by some miracle, you hit that saturation point, at that point you'd have the money and popularity to easily get your game ported to other platforms and continue your runaway success.
You're thinking about the wrong things; think instead about the kind of game you are excited to make on the platforms you have available to you and know how to develop for right now. If you just want to make money, go get a job writing financial software.

#5291864 Difference Between 2D Images And Textures?

Posted by on 16 May 2016 - 10:14 AM

Generally they are the same thing.


In some contexts, such as that of a specific API, a "2D image" may be a different thing (as in, a different language type or for a different purpose) than a "texture," but in general both are just picture data. The most common difference will likely be that that things called "textures" generally may have multiple mip levels (which are, effectively, successfully lower-detail smaller versions of the picture) associated with them, whereas a "2d image" is usually just the one image.

#5290968 Browser strategy game server architecture (with pics)

Posted by on 10 May 2016 - 08:47 AM

Moving to the multiplayer/networking forum, which probably has a better audience to address your needs.

#5290429 wall/contact point detection

Posted by on 06 May 2016 - 09:39 AM



You can edit your original post to clarify what you want. Don't re-post essentially the same question, rewritten.

#5290326 Time - the most important factor.

Posted by on 05 May 2016 - 03:15 PM

Blender 3D feels like it was made by aliens. From the UI to the key bindings, it all is quite hard to get into.



Have you actually used MODO? Blender's UI is obtuse sometimes, but so is the UI of almost every modelling software I have ever used in my entire career. Unless you have a compelling reason to drop that kind of cash on it, one based ideally on actually having used it somewhere else and being familiar with it, I'd say it's not a great investment. Blender or some other free tool will be sufficient to start with. More than sufficient.


You don't need to spend a lot of money on tutorials either. Or any, really. You can learn all this stuff with freely available resources and I'd caution you to be very thrifty about your purchases at this phase.

#5290089 Is it real?

Posted by on 04 May 2016 - 10:55 AM

Does it still take years to code everything?


Yes, especially if you have to ask how long it takes. Further, there is more left to do than just "coding." Just because you think you have all the art assets doesn't mean you actually do, that they will actually work correctly or be 100% drop-in-able or not require tweaks to adjust for gameplay or design issues that come up as you build the game.

#5290084 Is it real?

Posted by 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 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.





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