Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

My question is quite broad and related to the 2D game code design/architecture/structure.

Usually the main game consists of the main loop where you update & render your world states. However, it's recommended for many purposes to separate rendering from the game-logic and so on.

I am kinda confused about the whole situation. Many game engines/libs/sdks don't follow separation schema. They propagate a way where you define some scenes/stages and they contain some objects and the scene/stage controls the user input and so on. For example, in cocos2d(-x) and libgdx (stage2d) the games are usually done the way that the update logic happens at the same time/place as rendering. Also, the propagated way is to have a structure where an object knows how to draw itself - which is not a separation of updating & rendering. The same with Flash based games, they are usually done the way when an object (class) contains a swf or a texture and some data and holds some update logic itself, or updated from main Scene. And again this object already knows how to draw itself via "addChild".

Also, some people recommend to use MVC pattern, which will require to completely obey the structure of those engines/libs/sdks.

Maybe I am overthinking everything, but I am totally confused.

I would be grateful if somebody could point me to a correct direction with the game code structures. What is your way of doing things in libgdx/cocos2d/flash?

share|improve this question

closed as not a real question by Byte56, michael.bartnett, Tetrad Nov 28 '12 at 19:44

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

5  
Sorry people are down voting and not commenting, they're rude. I would guess the reason they're down voting is because you're not really asking a real question here. This is a Q/A site. It's not a discussion site. You should ask your question at a more discussion oriented site like gamedev.net or reddit.com/r/gamedev. Read the FAQ to learn what types of questions to ask here. Thanks. –  Byte56 Nov 27 '12 at 23:23
    
Can you please clarify that you mean by 'separate rendering from the game-logic' because it's not clear how game object's knowledge of how to render itself violates this principle? And how this should be changed, even theoretically? –  Petr Abdulin Nov 28 '12 at 4:58

1 Answer 1

Sometimes, depending on the chosen tools (language, frameworks, etc.), your game code will get entangled to code that's not specific to it.

Fortunately, you should always be able to grasp the basic elements necessary to work properly with your chosen tools. They'll always be there - they might just have a different name/appearance on each case (i.e.: render callbacks, timer ticks, input event handlers, etc.). Once you recognize how the basic blocks of your game fit along your tools it will just be a matter of how you fill these blanks spaces with your code.

About MVC, I think it's a pattern applicable to only a few and very specific types of games. I'd dare to say that the guideline is to use it only when you want to have a clear separation of user interface, game logic and entity management code. A turn-based strategy browser game, in which you have a large list of game entities you have to persist on disk (FS, DBMS, etc.), a game logic that's constantly evolving and a UI system that targets multiple platforms (IOS, Android, HTML 4, etc.), is a good candidate for a MVC architecture. Again: you could try to apply this pattern to any sdk, engine, lib, etc. - the more flexible your chosen tools are, the easier should be for you to implements these concepts.

From the tools your mentioned, I only have worked with flash. I remember that, when I was using it, all I wanted was to desperately avoid Adobe's hibrid designer/developer environment. So I usually chose between Standard Flash API + FlashDevelop and Flex SDK + Flex Builder. It may not appear to, but the choice of IDE/SDK have tremendous influence on the way a flash game is developed.

Last but not least, I guess you need some experience before being able to decide what's the best way to structure a game. Some decisions will depend on structured knowledge, but others are matter of personal taste. Start some self-teaching projects - they're great to give you some insight on specific subjects. Also, try to download a few open source games that use the tools you like. Study their code carefully. When you feel stuck, read about a specific topic in specialized literature (i.e.: real-time rendering).

Well, I know my answer was quite abstract, but I hope it helped.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.