I am new to this site and I am not sure if this is where I should post this.
I have an amazing game idea and I would like to meet with game developers here. I plan to make my game available on all platforms( mobile, online, PlayStation, Wii, Nintendo, XBOX) etc.
Is Unity 3D the best way to go ?
Any ideas on which language would be optimal for this endeavor ?
For getting people to work on your project, use the Classifieds section.
Be prepared to pay people -- especially if all you bring to the table is an idea. It doesn't really matter how good it is, most people will not just dedicate massive amount of time without any compensation.
As for which language and editors, etc. Most likely, it doesn't matter at all. Most games could be made in most languages.
If you're getting developers to do this for you, let them decide on their own. After all, they know what languages and editors they are fluent in using.
I don't agree with anyone who says my plan is any more complex or simple than a game of pong etc
Then you are wrong.
Multiplayer is a lot more difficult than you think it is. You came here asking for advice, so I suggest you take the advice you've been given. People here know a lot about making all kinds of different games, and I can tell you without a doubt that if your game has multiplayer in it, it is thousands of times more complex than a simple Pong game.
But if you still think it's so easy, and that we all don't know what we're talking about, feel free to ignore us all.
You'll still need to program in the powerful engines.
Some of the lower level things are taken care of for you, but basically everything related to gameplay and logic, etc, will need to be made.
Even if using various visual programming solutions, what you're doing is still programming (telling the computer what to do).
You'll still benefit from knowing what's going on at a more fundamental level, and learning about the various algorithms and approaches to problems.
If you want to make games, then focus on making games, with the best tools available to you. Depending on the type of game you want to make, the best tool available might be an already existing engine or framework.
If you want to learn how to create lower level stuff (e.g. game engines), or if the tools available aren't what you need, then you'll probably want to look into creating your own tools.
Most importantly, I think, is do what you enjoy doing. If you enjoy programming low level stuff, there's no reason to swap to Unity/Unreal. On the flip side, if you enjoy being able to have something up and running quickly, without focusing on the lower level details, then focus on that.
To me, that is the most important factor when choosing between something, and is applicable to most things in life, really.
It seems this was mainly directed at me due to the quotes/paraphrasing, so I'll reply in some detail.
Hopefully the forum formatting won't destroy this too badly.
EDIT: I see now that some of this wasn't directed at me. I'll leave the post as-is, since trying to edit the quotes more is a recipe for disaster.
I've taken the liberty of reordering your quotes a bit (marked with ... in the cases there's been other text between the quotes inside a single quote block).
notice that i posted my opinion instead of rating your post down. the mistake so many people make that is the REASON I POST OPINION CONTRARY TO POPULAR is that many people seem to feel that there is only ONE envaluation in productivity, the "apparent commercial standard".
YES it is necessary to standardise when working on a team, but this is not everyone's objective. if someone wants to get hired straight out of school, then kowtow.
if on the other hand someone engages in a rich and varied set of activities during their adult/professional life, more "localised" methods are more appropriate, with a lower need for standardisation and readability.
if i'm writing a game, it's likely to be under 2000 lines total. for the scope of such a project, there is absolutely no need for it.
I didn't rate your post negatively. I don't think I've ever rated one of your posts negatively, even if I've disagreed with points you've made earlier.
Opinions contrary to the popular one are (of course) both valid and valuable. However, when going against the grain I would personally appreciate some reasons as to why -- especially when recommending it to someone looking for best practices and advice.
In your case, I see the following reasons for why you advocate using single-character (or up to 2-3 in larger programs) variable names:
1. Less typing.
2. You generally work on your code alone, not in larger groups.
3.Your games are usually within a scope where you don't feel the non-descriptive variable names hinder you.
4. It's what you're used to.
For 1, I presented a counter-point -- modern tools help alleviate this (making it nearly moot), while still offering the benefits of more descriptive variable names.
For 2, you seem to acknowledge that if you were to work in larger teams would mean a shift in coding style/conventions. Again, personally, I would consider best practices to strive for something more universally understood when the cost of doing it is comparatively cheap (due to my point against 1).
For 3, I would still maintain that more descriptive variable names would offer a quicker at-a-glance understanding of any chosen piece of code snippet. Basically, I don't see how more descriptive variable names could ever be of non-negative value. Again, given the 'cost' of making the variables names more descriptive (partly due to my counter-point for 1), I consider this a non-argument.
For 4, I don't find that a compelling argument for why beginners should do the same. It might be a reason for why you don't want to change it, but that's not something a beginner can relate to.
the point you should understand is that short variable names are not a function of skill or duration of experience, it is a function of not being part of a standardised procedure.
if you think someone who is used to conventions established with c is a bad or inexperienced programmer, you're "self-inflated" and "other depreciating". the reason why you find it "ironic" is because you need to feel as if you have outwirtted me, instead of simply acknowledging that the methods of others may also be entirely valid.
I've never insinuated that you're lacking skill or experience, or that you are a bad programmer.
The reason why I found it ironic was not because of what you assume in your post, but because I consider typing to be typing. You seemed to want to type as little as possible when you code, but you seem to not care how much you type in other cases. Paradoxical might have been a better word.
and, so you know, i don't have time to type out superfluous appellations,but i have all the time in the world to explain myself and encourage you to be less depreciative toward others. i am not bad, nor am i new. it's that simple.
Again, I've never claimed you are bad or new.
But this is puzzling me -- do you feel I don't appreciate your opinion just because I don't agree with it?
Should the only replies (to any opinion in this thread) be simply "Yes, that's some good best practices there, go with that"?
If you had more compelling points behind your opinion, it would definitely challenge my own opinions on the matter. I listed what I see as your points above, and after reading them I simply do not find them compelling or persuasive. Hence my reply.
i am not bad, nor am i new.
and, i do not use long variable names.
and that is really all that needs to be said, or considered.
This is where I disagree with you the most.
If someone asks for best practices and advice, and someone else posts their opinions, they should be prepared to have those opinions challenged.
If someone said they wrote all code on a single line, without any line breaks, I would question why and propose other ways of doing it. Ways I found superior.
That doesn't mean I'm attacking the poster, but it does mean that I don't find that style good advice.
Whether you want to engage in discussion or attempt to shut it down without any further replies is up to you.
That does not, however, mean that others shouldn't be allowed to ask or challenge what you've written, which is the vibe I'm getting from this quoted text.
now go ahead and nuke me for asserting that you shouldn't depreciate this expression.
Have you considered that some of your negative replies/votes might be caused by your way of writing more-so than your post content?
i much prefer single character variables whenever possible, usually make it to 2 and 3 character variable names after a few thousand lines.
i consider my code to be concise and readable. other people hate it.
These two goals are, in my opinion, completely contradictory.
Readable to me means that I can look at a variable, function, class or whatever, and not have to guess at what it means.
GIven context, I'll probably be able to figure out whether at means animationTime or angryTeddy, but that's an unneeded mental burden. However light that burden might be, it will add up and cause confusion at some point.
That doesn't mean I'm advocating naming things long just for the sake of being descriptive -- especially when it related to math and math formulae, short or even single-character variable names can make a lot of sense. If you're doing wave math, c would be valid instead of speedOfLight, in my eyes.
That said, typing out long names all the time can be annoying. But that's also why newer IDE's and editors have various features for alleviating that concern. IntelliSense, code completion, etc. Typing in a couple of characters should be enough to reduce the number of possible names to a just a couple, easily selected.
I also slightly disagree with the "never let anyone rate you" paragraph. I think I see where you're coming from; that optimal workflow is an individual thing, and one shouldn't be "forced" to conform for the sake of conforming.
That said, especially for a beginner, asking as many questions as possible can be a very positive thing. Getting answers and learning good habits before bad ones are too deeply ingrained, get critique on something that's recently completed and is fresh in the mind, etc.