Hello, a friend and myself are planning on making for ouya. We are both in college and we both work as developers so we're not just beginning to program. That being said we have never made a game which is where my question comes from, where to begin? We have our game idea and concept but we're not sure where to start, do we start with the character and controlls making sure the animations are correct or do we start building our game world? How do you guys start making a game? Is there a method you follow?

Thanks you for the advice

What current experience do you have? Developer experience is certainly a plus but games are a radically different from most developing roles (gross generalization, I know). If you're looking to roll your own, make some really basic games first like Pong and Breakout, that sort of thing. Otherwise, you might be more interested in using an off the shelf engine if you're looking to get things done so you can both get stuck in.

Hopefully I'm answering this correctly but between the two of us we have java, c#, c++, python and javascript for web and desktop development. We were thinking of pretty much getting into the bulk of game programing and skipping the simple pong type of games. Hopefully that doesn't cause to many problems.

Except that games like Pong teach you the basic mechanics of making anything. If you start deep into coding a massive game, you will be making mistakes that you would have made with Pong. This means every mistake you made will have to be fixed later, taking up more time since the code will all be dependent on what you base it off of. If you want to start making a game, you should start simple or at least make your code modular so that if you need to fix any major mistakes, it will take less time to fix the rest of the game.

In my experience, of course. I dove right into it and always had to rewrite what I wrote before, which took more time than if I started simple.

For the ouya part, I know that monogame(c#) is compatible with the ouya.

Whoa, you're getting way ahead of yourselves. You're talking about game subsystems and you haven't even decided on an engine yet. First decide HOW you are going to build your game, then you can decide on the parts after that.

Once you have decided on your language, and platform, you should decide if you are going to be building your own engine or leveraging a 3rd party engine. If you don't use a 3rd party engine, you will have to build abstractions around many things yourselves, namely: audio, networking, rendering, user input, GUI, utilities, as well as a few other things I've surely forgotten. Not to mention, there is a fairly large middle ground. You can use certain software packages called "middleware", so that you can implement your own engine, which customizes the game engine in ways that suit your specific game, but implement generalized functionality for certain parts. As an example, I am building my own engine, but I use FMOD to manage the audio, as that is a particular area that I have no interest in interacting with. However, when it comes to the networking, I have decided to manage this myself, as I don't feel like handing control over to a 3rd party library would make sense for my particular game.

Once you have decided whether you are going to use a prebuilt engine, build a frankenstein (some middleware and some of your own stuff patched together) , or totally from scratch, THEN you can decide how to build your game.

Overall, I would say the first thing you need to decide is how you are going to drive your game's data. Every game is data driven. You have levels, enemies, objects, players, NPCs, ect. You need to decide how you will load these different types of entites into your game. How you will serve them up to the player. And of course, how you will store them so they can be accessed the next time the game is loaded.

Once you have a good architecture for the data driven section of your game, you must then decide how your players will enter the game. Will there be a login screen? Will they start a new game from a selection screen? Will there be options?

Here's all I'm going to say from here: if you've gotten this far and you still want to make a game, come back here. We will help you. But until you have got this far, you aren't ready to make a game.

I tend to agree with 'metsan' but intend to suggest something completely different. Instead of all the "figure out what to build steps" I'd actually suggest a very simple solution: Unity. Given your knowledge level using the free Unity system can give you a better understanding of what is required to make a game. All those nice things you might call in Unity have to be replaced. The amount of work required is pretty huge. The idea behind using Unity is to give you a better idea of how games are made (while making a game) and all the details behind them. If you stick to Unity, that's up to you, but at least you have a starting point and you know what bits and pieces you have to port over to other languages.

C#/Boo/JavaScript can easily be moved to other solutions. So this is a low risk starting point for you.

You know I was thinking about starting with with Unity but didn't - and honestly I'm glad I didn't. It really depends what kind of person you are though - you want to get the game up and running as fast as possible or do you want knowledge and something of your own.

If you and your friend really want to skip all the basic games and stuff and go for it - certain things will take much longer and you will probably have a lot of redesigns as you learn more - but you can do it.

In this case I would suggest a first step is get a window to pop up with a moveable object on the screen. Do this with whatever API (Direct3D or OpenGL probably most common) or engine or library.

I agree with pretty much everything that has been said thus far... and feel that one thing that will help keep you from being overwhelmed is diagramming out what you have planned thus far, even if just a simple UML with what you think you will need.

Then you can start figuring out what parts to research, which parts you will do with what software, ect.

As you research, you can fix the UML with new information if need be.

Having a basic starting diagram always helps me, even if it is only mental... of course, working with a friend I feel that it is extremely important.

Then you can test each piece of the puzzle as you are putting it together, as you know what each item should have.

Just have a few test cases in mind, and write a test script for them. If you are programming in Java and Android, an alternative to what has already been mentioned is libgdx, which I have been finding fairly simple to use and nice to work with.

But, in my opinion, it is best to set up a plan then do the research to see what will be best for what you are attempting to do, as well as a good fit for your programming styles.