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.
Josh PetrieMember Since 11 Jun 2003
Offline Last Active Private
- Group Moderators
- Active Posts 7,944
- Profile Views 28,229
- 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 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.
Posted by Josh Petrie on 16 May 2016 - 10:33 AM
To change my question a bit, well, which are the platforms which earn most revenue, today?
Posted by Josh Petrie 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.
Posted by Josh Petrie on 10 May 2016 - 08:47 AM
Posted by Josh Petrie 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.
Posted by Josh Petrie 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.
Posted by Josh Petrie on 04 May 2016 - 10:55 AM
Does it still take years to code everything?
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."
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?