G̤͙͖̩͖̓̾ͫa̭̥ͥ̑̅m͙͙ͮ̂̊ͪ̓͑e̠̪ͣ̍ͭ̇ͮ̓

[Bad At Gravity]

Guys, I am ready to start my first game/project, but I don't know where to begin. I have good ideas and mechanics floating about in my noggin' but I need to start an actual project. Many of you guys have made games before and I was wondering if you could help.

I'll gladly answer any questions you throw at me. (Unless I don't want to.)

[Anuke]

Is it 3D? 2D? Multiplayer?

[Bad At Gravity]

It would be either in 3 or 2 dimension rendering, but it would be played like a 2d platformer. I intend for it to be an app with only one button.

[ZeroSwordsMaster]

What programming experience do you have, first of all? I would recommend worrying about programming first (as far as the mechanic ideas, maybe just make a brain-dump file so you doing forget it when you begin the project)

As far as actual programming languages to learn should you have no experience, you have a few options

1. Using a pre-existing engine, such as Unreal or Unity.

[ZeroSwordsMaster]

What programming experience do you have, first of all? I would recommend worrying about programming first (as far as the mechanic ideas, maybe just make a brain-dump file so you doing forget it when you begin the project)

As far as actual programming languages to learn should you have no experience, you have a few options

1. Using a pre-existing engine, such as Unreal or Unity. (as far as Unity is concerned, I'd suggest learning C# for scripting purposes. I believe Unreal uses either Lua, C++, or a combo of both). These are easily portable between multiple systems and for simple projects, very little coding is actually required.
2. Use Java with a library. Java runs on a Virtual Machine (VM), and is very portable. The process involves much more code, but can be much more rewarding/educational in the longterm. This also allows precise control over what tools are available, since some engines can be...overwhelming to say the least
3. C++ with SDL2 or a similar library. Probably the least portable, although this is eased by using SDL or similar. I'd also recommend learning Lua and the C Lua API for scripting's sake. This is also the hardest route, as C++'s syntax is much more involved and the language itself is lower level (less abstracted, to say), meaning that many things are much more long-winded. Although it appears it may be on the way out, many legacy engines and software still are in C++, meaning that many companies still want people with reasonable knowledge in C++ or C-like languages.

There's also C# with libraries, although I know nothing about it's portability and ease of use. I've never even worked with the language, frankly. If someone on here uses it frequently (not in Unity, but with libraries), it may be useful to provide your insight on portability and ease of use.
Before you make your first "big" (read: public) product, I'd recommend almost making small tech demos/proofs of concept for more simple concepts to practice them all isolated, and then putting them together into your first project. It's hard to work on your first project with all these interconnected systems without isolating each one first, of course.
Also, I'd be willing to add you to the OneMoreBlock skype group if you want more active discussion about it. In fact, I've been considering reviving this one older OneMoreDev chat to use it as a chat for programming talk without being backlogged by other discussion for easy reference to previous discussion.
A few of the people in the community (including me) formed a dev team and... well, to say the least, both of our projects died off. If you want, when you get to the phase of planning out mechanics, we'd be willing to tell you some of the traps and pitfalls we fell into for our first project.
Good luck!

[Sebastian Lawe]

What programming experience do you have, first of all? I would recommend worrying about programming first (as far as the mechanic ideas, maybe just make a brain-dump file so you doing forget it when you begin the project)

As far as actual programming languages to learn should you have no experience, you have a few options

1. Using a pre-existing engine, such as Unreal or Unity.

Should also note.
Unreal uses C++ or Visual Diagrams
Unity uses C# or UnityScript. Although getting playmaker in the Unity asset store will let you program with Diagrams too.

[Bad At Gravity]

Thank you. I know enough programming to make some proof-of-concepts in Unity, but first I'd probably need Unity. I'll save up and get it.

[Anuke]

I'll save up and get it.

By this, do you mean that you're going to buy unity pro? Don't. You can do plenty without it.

[ZeroSwordsMaster]

Thank you. I know enough programming to make some proof-of-concepts in Unity, but first I'd probably need Unity. I'll save up and get it.

For your first project the free/personal version is probably enough; most things in the paid versions aren't really essential things. Unity 5 is free with most features you would need. Most other stuff isn't necessary, and some of the features they include in paid may complicate things for your first big(ger) project. Not to mention it's a $75 USD/mo subscription. Not the most personal-project friendly thing, lol.

https://unity3d.com/get-unity/download?ref=personal

EDIT:

TL;DR:

By this, do you mean that you're going to buy unity pro? Don't. You can do plenty without it.

[ThatOneFox]

Moved to creative corner since this is more of a creative topic over a technical one.

[Entity]

Zero bb gave you some (great) advice on the technical side, so here's a little bit of general advice from my experience.

• Writing a game start to finish is not easy. Yeah there's some fun parts, but the last 10% of your game (the final polish and bug fixing) is going to be 90% of the ugly work. That's not an exaggeration. You've gotta really believe in your game to get it finished.
• Start small. I know you probably have a ton of super awesome ideas for games that people would actually pay money for, but start small. Even if you have a medium sized project that you think you can do, write it down for later, and start even smaller. Seriously. For your first game, remake pong. Then breakout. Then add powerups. Just build your way up. It really feels lame, but work your way up. Nothing burns you out more than getting halfway through a huge project and realizing there's still a ton of stuff to do.
• You will fail more than you succeed. A lot more. I bet I have over a hundred games that I started and never finished. As an indie developer you aren't getting paid before you release your game, so you have to get motivation to finish from somewhere. If your game is smaller, that will help. Every game you work on will teach you something and you'll get better and better at it. The first time I made a deathworm clone, it took two months. Now I could easily do it in an afternoon (maybe a few afternoons if you want to include polish and stuff).

If I could list two qualities that would make a successful game developer it would be 1) The ability to take criticism and not get offended, and use it to enhance your game 2) The ability to stick with a project even when you're bored with it.

[Bad At Gravity]

Thank you guys so much for all of your help, and I meant unity Personal, in case you couldn't tell.

[ZeroSwordsMaster]

*snip*

basically some of the big issues that we had with OMD haha

Something else I would recommend:
Do some coding every day! It doesn't even have to be for your game. Just code something functional in some language every day, and eventually things start adding together. Heck, half the stuff in the small C++/SDL/Lua library I'm making are inspired by design decisions I made coding PHP website backend and Minecraft bukkit plugins. It may be hard to fit into your schedule, but even getting one function done can provide you with lots of insight on how to do something in larger projects better. I guess this could be considered a part of the "start small" advice. No matter how unrelated different languages and projects may seem, they inevitably contribute to a central mental library of sorts of code organization patterns, security methods, and best practice.

Also, be organized. Organize and document/comment your code! I know some people that can read through code with non-descriptive names and no comments and understand everything, whether it be through memory or through just being able to look and know, but it's very important, especially when starting off, to comment everything and have it organized well so you can come back after a break or post-mortem and be able to read the code. It's also a useful habit to get into because when/if you go into comp sci/software eng. as a career, you'll have to share your code with others, and not everyone will be able to read it fluently. Not only that, I've sometimes seen projects fall apart or take forever to update when the developers go back to make the code more efficient and end up having to sift through monstrous spaghetti code. Minecraft is a good(?) example of this, as the devs have pointed out on more than a few occasions.

On the topic of organization, keep ideas down in a Google Doc or some form of document that you won't lose; I usually have two files or two sections a file for every project MINIMUM: a "braindump" with random ideas that are unorganized and may not be final, along with possible solutions to problems, and a faux-Game Design Document, where everything is organized, (almost, but not quite) finalized, and has a solution. You can't keep everything in your head!

Also, a bit of nice music helps get the technical and creative juices flowing.

[ZeroSwordsMaster]

*snip*

basically some of the big issues that we had with OMD haha

Something else I would recommend:
Do some coding every day! It doesn't even have to be for your game. Just code something functional in some language every day, and eventually things start adding together. Heck, half the stuff in the small C++/SDL/Lua library I'm making are inspired by design decisions I made coding PHP website backend and Minecraft bukkit plugins. It may be hard to fit into your schedule, but even getting one function done can provide you with lots of insight on how to do something in larger projects better. I guess this could be considered a part of the "start small" advice. No matter how unrelated different languages and projects may seem, they inevitably contribute to a central mental library of sorts of code organization patterns, security methods, and best practice.

Also, be organized. Organize and document/comment your code! I know some people that can read through code with non-descriptive names and no comments and understand everything, whether it be through memory or through just being able to look and know, but it's very important, especially when starting off, to comment everything and have it organized well so you can come back after a break or post-mortem and be able to read the code. It's also a useful habit to get into because when/if you go into comp sci/software eng. as a career, you'll have to share your code with others, and not everyone will be able to read it fluently. Not only that, I've sometimes seen projects fall apart or take forever to update when the developers go back to make the code more efficient and end up having to sift through monstrous spaghetti code. Minecraft is a good(?) example of this, as the devs have pointed out on more than a few occasions.

On the topic of organization, keep ideas down in a Google Doc or some form of document that you won't lose; I usually have two files or two sections a file for every project MINIMUM: a "braindump" with random ideas that are unorganized and may not be final, along with possible solutions to problems, and a faux-Game Design Document, where everything is organized, (almost, but not quite) finalized, and has a solution. You can't keep everything in your head!

Also, a bit of nice music helps get the technical and creative juices flowing.

[papaya]

Guys, I am ready to start my first game/project, but I don't know where to begin. I have good ideas and mechanics floating about in my noggin' but I need to start an actual project. Many of you guys have made games before and I was wondering if you could help.

I'll gladly answer any questions you throw at me. (Unless I don't want to.)

i feel like i should point this out because itll bother me otherwise, but noggin isnt a contracted form of a word and so doesnt need an apostrophe

also for real if you're gonna go down the I WANNA WORK FOR VIDEOGAMES route understand that just being the ideas guy isnt good enough. you cant make a game from cool ideas alone. If your programming skill is incredibly minimal you probably wont be able to turn any of your ideas into reality... yet. break a few eggs to make an omelette etc.

[Miniike]

Extra Credits.
[media=youtube]z06QR-tz1_o[/media]
[media=youtube]dHMNeNapL1E[/media]
[media=youtube]UvCri1tqIxQ[/media]
These videos gave me the motivation to recreate Asteriods (sort of). I never did anything else, and I doubt I will, but it was still a great exercise.

Also don't put it on Steam Greenlight. Just no.

[bionicnacho]

As being another guy that has developed multiple games before and just lost motivation (wow, there seems to be a ton of us here), I couldn't agree more about what has been said. Really listen to these guys about what they're saying.

Also, a tip I can give you is to make things a bit easier for yourself and make a git repository through GitHub or Bitbucket. I personally like GitHub a little more but you need to pay to get private repositories, you don't on BitBucket.

If you don't know what git is, it's a revision control system. It helps you keep track of all the changes you've made and you can actually see code you've deleted on previous versions and such, but the most important thing is that you always keep a backup of whatever you're working on.

My first project (along with some now inactive members of the community) (OMB Thread) mostly died because of this reason. All our files got lost or corrupted MULTIPLE times because we were using a less than optimal solution to work together. We didn't really know about Git from the start, so it's an advantage to know about it and use it from the get-go, even if you're not making a project with a team.

Something else I can tell you about why that game failed, is we were incredibly ambicious and always thought of the next thing we could do, instead of focusing on what was already built that needed tweaking. I mean, we even created a "game company" of sorts without even being 50% finished with the game. So, another advice is to take it step by step, and as Entity said: start small.

I'm pretty sure we're all here to help so if you have any question at all, feel free! And if you really want to do this and you set your mind to it, go ahead. Just know that it won't be an easy ride.

[Bad At Gravity]

Sir, you have a very serious medical condition. Your fingers randomly switch between 4 digits and 5 digits. Also, you have no neck and wrists.

[Entity]

My goodness yes, Extra Credits is amazing.