What Order To Code In?

I'm not familiar with CoronaSDK, but usually my dev cycle is something like:

1. Barebones world (just some land)
   
2. Console output, relevant debug text
   
3. Simple collision/Input
   
4. More complex UI
   
5. Refine World
   
6. Refine UI
   
7. Repeat 5-6 until gold
   

'World' refers to general features like rendering or audio.
In a production environment normally you have a set of features you're responsible for, so knowing what to work on is rarely an issue (esp. with publishers )

The advantage of working indie is that once things are working on a very basic level, you can decide what you want to do when you want to do it.
If I could offer some advice though, try not to be too jumpy between systems. Lots of bugs happen that way.

I'm not familiar with CoronaSDK, but usually my dev cycle is something like:
Barebones world (just some land)
Console output, relevant debug text
Simple collision/Input
More complex UI

Could you explain these 4 parts of the cycle a little more in depth. Like would you make the menu first, or the level.

Thanks!

A good rule of thumb is this: The next thing you should do should be the thing that will have the largest effect or outcome. The reasoning behind this rule of thumb is psychological: it is easier to remain motivated if the changes that are occurring are large and exciting. There is nothing exciting (imo) about a menu. At the start of a project, the biggest thing you can do is to start getting the gameplay in place; ie, SeiryuEnder's "barebones world". It won't be the final world/level; it will be a sandbox where your gameplay resides while you implement and flesh out the gameplay. This first world is what they call a "vertical slice"; eventually, all gameplay features will be operational there, it will be a sort of focused level, with every feature distilled down and easily accessible for easy testing. As the project gets more progressed, you can start fleshing out the actual real world; be warned, however, that if you begin this process too early, you will end up revisiting all of your content heavily in order to modify it as the game evolves and features change. Many people will wait until the vertical slice is feature-complete before they start on the real world. That is my own personal method.

I couldn't agree more with JTippetts. Game programming is going to really challenge your self discipline; there's an uncountable number of projects scrapped because of lost interest. If you're not constrained by milestones and deadlines, do whatever motivates you at the time. Don't leave unfinished code - wrap up whatever you're working on - but generally it's a bad idea to keep working on something if you're deadlocked or just really disinterested.

The biggest thing to keep in mind about the UI is that it is purely about FEEDBACK. It is 100% INFORMATIVE.
I typically open a console (will add some code for that below) and make that last until many of the core systems are in place/functional.

As for the UI, the most critical thing you can do is sit down and DRAW OUT YOUR UI ON PAPER!!
Seriously, don't skip this step. Draw it a few times. Make changes on paper. It will save you so much time.
You will almost certainly go through several revisions, but you want to be as prepared as possible.

Generally speaking, for every hour you spend designing you will spend 10 fewer hours implementing.


-edit

Almost forgot to add the console code.
There's a couple ways of doing this. The easiest (if you're using visual studio) is to go to:
Project Properties -> Linker -> System and set your subsystem to console. In the older version of MSVC that would allow you to open a console window while running an application.

If you have trouble with that or it's not an option for you, you can also add this code to your WinMain:


#if defined(_DEBUG)
// Open a debug console window
HANDLE handle_out = GetStdHandle(STD_OUTPUT_HANDLE);
int hCrt = _open_osfhandle((long) handle_out, _O_TEXT);
FILE* hf_out = _fdopen(hCrt, "w");
setvbuf(hf_out, NULL, _IONBF, 1);
*stdout = *hf_out;

HANDLE handle_in = GetStdHandle(STD_INPUT_HANDLE);
hCrt = _open_osfhandle((long) handle_in, _O_TEXT);
FILE* hf_in = _fdopen(hCrt, "r");
setvbuf(hf_in, NULL, _IONBF, 128);
*stdin = *hf_in;
#endif



From there, you should be able to use std::cout to print to the console

Thanks so much guys! This will really help me in the long run! You guys are very informative on what you say and how you describe it and now i completely understand what you are saying. Again thanks!

~Landon

I don't use C++ SeiryuEnder, I use LUA. Thanks though!