• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Landon Patmore

What Order To Code In?

6 posts in this topic

[font=times new roman,times,serif][b]Hi Everyone,[/b][/font]
[font=times new roman,times,serif][b]I need a little help...i'm new to CoronaSDK and Lua language...I understand the basics. But i need help in the order in which i'm suppose to code in. I don't know if i should make the menu first, the pictures, or levels. I'm just confused with this. I would really appreciate if someone can help me with this. :)[/b][/font]
[font=times new roman,times,serif][b]Thanks!![/b][/font]
[font=times new roman,times,serif][b]Landon[/b][/font]

Share this post

Link to post
Share on other sites
I'm not familiar with CoronaSDK, but usually my dev cycle is something like:[list=1]
[*]Barebones world (just some land)
[*]Console output, relevant debug text
[*]Simple collision/Input
[*]More complex UI
[*]Refine World
[*]Refine UI
[*]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 [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img])

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. Edited by SeiryuEnder

Share this post

Link to post
Share on other sites
[left][quote name='SeiryuEnder' timestamp='1338684850' post='4945696']
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

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


Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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.


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;


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

Share this post

Link to post
Share on other sites
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!


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0