Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Game Internal Organization?  (Read 12376 times)
0 Members and 1 Guest are viewing this topic.
Offline SkyAphid
« Posted 2012-05-09 02:32:08 »

So, I'm rebuilding my game engine for a slightly fresh start; I'm going to use all of my resources and what-not so that the game will be back to where it was in a week or two, but this time I want it to be pleasing to open up.

So, how do you organize your games? This is going to be a bigger RPG project, so I really do need a way of keeping everything together, but altogether organized.

Like, for example, how do organize different environments, the objects, and the logic related to that?

“Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is the doing something else.” ~Leonardo da Vinci
Offline ReBirth
« Reply #1 - Posted 2012-05-09 03:08:53 »

First you need to understand completely each class's behaviour. Try to pull out common things that they can share, and make a class to resemble it. If you're unsure with some method, make them abstract.

Offline StumpyStrust
« Reply #2 - Posted 2012-05-09 04:29:13 »

It helps me to actually write things out. Not necessarily text but to draw the different classes I need as boxes and write inside them the things they need and then links things together. This helps me so when i code I am not writing stuff that will change almost right after I write it.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline divxdede

Junior Devvie





« Reply #3 - Posted 2012-05-09 06:03:23 »

My trick would be to use inheritance only for main behaviours and natural things and use composition / injection dependances to glue others functionnalities.
It let you more flexibility after to construct more variants of behaviour than inheritance that may block you in an inheritance tree for a specified functionnality.

Offline Damocles
« Reply #4 - Posted 2012-05-09 06:24:10 »

An UML will help a lot.
You dont need to actually make it fully propper, but having a simple Graph with classes, methods and dependencies makes
you organize your code before coding it.
Already by designing the UML (or a simplified version of it)
And you can later look it up to not get lost in how your many classes interact.

I always start by writing a Prototype first wich runs quite well, and lets me play around with features.
But it gets messi and hacked.

At a certain point I completetly rewrite the project, using the prototype as reference (and copying some parts, but not all of it, mostly only the novel tech)
Since you have the prototype you can concentrate on propperly planning and implementing your architecture, as you have a concrete reference of
how it should look like in action.

Offline gouessej
« Reply #5 - Posted 2012-05-09 06:35:48 »

Hi

Of course, I try to avoid circular dependencies between packages. I combine a scenegraph with several state machines and some schedulers. I have a class per type of state machine, I use state machines for the main step in the game (PEGI, intro, main menu, etc...) and for the player(s). The schedulers are used to postpone operations in state machines until conditions get satisfied. Moreover, I try to separate the Model, the View and the Controller but I admit that the separation between the Model and the Controller is sometimes not clear. I separate the concerns, I avoid creating too big classes. I agree with advises suggested by divxdede. I use Fettle API for state machines, it is simple, small and it just does what I expect. The whole architecture is organized in several layers so that high level objects never have to use raw OpenGL. I try to avoid using anonymous and/or internal classes. I try to allow to override almost everything because I cannot imagine what people will do with my source code, it would be better that they can use the JARs as is without modifying it because an extra useless final declaration. I agree with Damocles too about UML but I use it differently, I iterate, I modify the design, I don't try to have a "perfect" design at the beginning but I try to keep something nice at each iteration.

Offline ReBirth
« Reply #6 - Posted 2012-05-09 06:44:22 »

An UML will help a lot.
You dont need to actually make it fully propper, but having a simple Graph with classes, methods and dependencies makes
you organize your code before coding it.
Already by designing the UML (or a simplified version of it)

I always start by writing a Prototype first wich runs quite well, and lets me play around with features.
But it gets messi and hacked.
Still wonder why that's my fav way.

Offline Damocles
« Reply #7 - Posted 2012-05-09 06:52:19 »

There are 2 times

A time to prototype, and quickly realize a vision, test a new mechanic and throw together stuff to get an impression.

And

A time to sit back and thinker about how badly hacked this prototype is. Then to raise and craft a nice and propper architecture
of how to let the project look like the prototype, but please the inner propper Computerclass teacher.

-> rewriting  (its not a waste of time, but a smart way to combine testing new ideas with planning a clean implementation)

Offline 65K
« Reply #8 - Posted 2012-05-09 06:52:46 »

A vague question.
First, define your requirements. Don't try to be a visonary, but know what you want, can do, and very important, can not do. A "bigger RPG" is, hmm, somewhat alarming.
Start with modules or layers. Clearly assign responsibilities, like e.g. for rendering, actors, logic/AI, network. Don't mix things up. For example, the whole game should be runnable without an attached view. No imports of graphics classes in your logic packages.
Stay clear of package cyclic dependencies. Use a tool like JDepend to help you.
Like mentioned, use inheritance with caution.
Read, no, buy the design pattern book, if you haven't so far.
Drawing diagrams is good, doesn't have to be official UML. The best UML tool is the cheapest as well: paper & pencil.
Concentrate on one task at a time. Use JUnit tests for fast developing and verifying of functionality. Don't waste time on tasks with minor priorities in the beginning.
Keep your public interfaces (meaning interface and class methods) as small as possible. No public member variables. Stay away from statics.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2012-05-09 08:59:34 »

The whole game should be runnable without an attached view. No imports of graphics classes in your logic packages.

I've always found this to be a tedious waste of time IMHO. If I can borrow a phrase from Cas "object orientated wank".

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2012-05-09 09:06:53 »

Agreed; you want stuff on screen, as soon as possible.

Pro tip: do all the title screen, menus, and options first, before you start the game. Because you won't want to do them afterwards.

Cas Smiley

Offline 65K
« Reply #11 - Posted 2012-05-09 09:19:04 »

The whole game should be runnable without an attached view. No imports of graphics classes in your logic packages.

I've always found this to be a tedious waste of time IMHO. If I can borrow a phrase from Cas "object orientated wank".
I'm not into overengineering either to which the whole Java world is prone. And I have seen enough bad examples in the domain of business applications.
Primarily, this is not about object orientation, but about separation of concerns and modules.
I would even suggest the opposite: it saves time in the long run

Offline gouessej
« Reply #12 - Posted 2012-05-09 09:19:39 »

The whole game should be runnable without an attached view. No imports of graphics classes in your logic packages.

I've always found this to be a tedious waste of time IMHO. If I can borrow a phrase from Cas "object orientated wank".
It goes very far but if you succeed in following his advice, it means that no rendering code is mixed with the logic code which is fine in term of separation of concerns. For a turn-based RPG, it is quite doable, isn't it? Moreover, if this "bigger RPG" has to work in a client-server architecture (not P2P) with an headless server, this last one should not run rendering code.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #13 - Posted 2012-05-09 09:42:57 »

Primarily, this is not about object orientation, but about separation of concerns and modules.

It goes very far but if you succeed in following his advice, it means that no rendering code is mixed with the logic code

Both of which are utterly irrelevant to getting a game done. It might produce nice 'architecture', but it's additional complexity for zero actual practical gain. Not all abstractions are born equal, and separating logic from rendering for any non-trivial game is a massive net loss.

For client/server it's more viable, but I've always found it more practical to have a 'null' renderer / render backend that hands out dummy Model / Mesh etc. instances. (I believe Unreal does this as well btw).

Note that I'm not saying that you game logic should be scattered with GL or Java2D calls, but there's nothing wrong with it dealing with higher level visual objects like Sprites or Models.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2012-05-09 10:13:23 »

Indeed. If you've got completely separate "Sprite", "Effect", "Emitter", "Particle" and "Game entity" classes you're well on your way to achieving everything you need to achieve.

Funny factoid: all my games are basically the same. Yes, even Revenge of the Titans compared to Ultratron. They're so similar that the way we actually start a new game is literally to copy and paste the entire project in Eclipse and then rename the packages. I always end up with the same general structure: Entity class with a bunch of subclasses such as Player, Bullet, Building, etc. Game screen. Game state. Then a few bits and bobs like Weapons, etc.

It helps that the whole lot is sat largely atop a fairly stable set of libraries that handle sprites, particles, special effects, GUIs, etc. However these libraries didn't grow in a vacuum. They were developed without great thought placed into reuse of neat API design as part of other games; gradually when I realise I want to pinch a bit of code for another game I have a think about whether it's worth dragging it out of the original game and trying to make it work with another game. A lot of extreme refactoring goes on to achieve this, but then, I've now got 4 games to manage simultaneously with it all and making sure stuff doesn't break is increasingly complex.

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #15 - Posted 2012-05-09 11:11:04 »

I am going back up princec  and Orangy Tang. Working game first. Playable faster is better. Working code is better that well designed code that is not working.

UML? what? UML is so some MBA can give a talk about your work and show a picture to pretend that he/she even knows what it is that you do. I have never found such things useful. Simpler class diagrams perhaps, but only auto generated ones that use the live code. Not some version of the code from 2 years ago. 

Fact is that no matter how much you design ahead of time. It will be wrong by the time you write up even 20% of it and you will know it. So good enough is good enough, and that means some idea of a design and direction, but then write code. Code code code. There is no substitute for writing code.

And writing "good" code for the future. You don't know what that is so you can't design for it. Write code to do the job in front of you now well. Chances are that that is the best future proof code. It has nothing more in it than it needs.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline jonjava
« Reply #16 - Posted 2012-05-09 11:44:20 »

There was a time when I would make the "tools" my game would need in a way that I could use them in other projects. This soon became a complete mess to work with all these shitty "tools" I've made, most of which needed updating anyway because I'd have found better ways of doing things.

So I quickly scrapped that methodology and now I always rewrite everything and make things specific to the game and add things as I go along without worrying about making the class super flexible for other "future" projects.

I just rigorously sort similar things into folders/packages and I even use a few static classes (singletons actually).

A UML may help. I find myself tweaking/rewriting the UML constantly. UML are of much more help (imo) in group projects and coding things designed by others.. or when you know what you're doing (like in your case).

Offline jonjava
« Reply #17 - Posted 2012-05-09 11:45:30 »

I am going back up princec  and Orangy Tang. Working game first. Playable faster is better. Working code is better that well designed code that is not working.

UML? what? UML is so some MBA can give a talk about your work and show a picture to pretend that he/she even knows what it is that you do. I have never found such things useful. Simpler class diagrams perhaps, but only auto generated ones that use the live code. Not some version of the code from 2 years ago. 

Fact is that no matter how much you design ahead of time. It will be wrong by the time you write up even 20% of it and you will know it. So good enough is good enough, and that means some idea of a design and direction, but then write code. Code code code. There is no substitute for writing code.

And writing "good" code for the future. You don't know what that is so you can't design for it. Write code to do the job in front of you now well. Chances are that that is the best future proof code. It has nothing more in it than it needs.

Offline gouessej
« Reply #18 - Posted 2012-05-09 12:15:02 »

It might produce nice 'architecture', but it's additional complexity for zero actual practical gain. Not all abstractions are born equal, and separating logic from rendering for any non-trivial game is a massive net loss.
The practical gain is that you spend less time in fixing bugs with such a nice architecture. When you don't separate enough things that could be separated, you have to do this separation in your mind anyway when you have to fix a bug (and to do it each time you think about the code), that's why I agree with 65K. Separating logic from rendering is a bit difficult when you're not accustomed to do it but as time goes by, when you take good habits, it is no more an effort, it becomes natural. I do that both in business applications and in games.


Working code is better that well designed code that is not working.
If the source code becomes too much ugly, you won't probably even want to improve it at a certain step. If fixing bugs requires too big an effort, it may discourage the developer(s). Imagine that your girlfriend or your boyfriend becomes extremely ugly, I assume you won't want to spend any time with him/her. That's the same thing for the source code. Personally I can spend some time in dirty code but I have my own limits; if I can't improve it, it becomes really discouraging.

Offline Roquen
« Reply #19 - Posted 2012-05-09 12:52:22 »

For a big RPG I'd think about writing the world building tool first.
Offline dishmoth
« Reply #20 - Posted 2012-05-09 13:48:37 »

Imagine that your girlfriend or your boyfriend becomes extremely ugly, I assume you won't want to spend any time with him/her.

Shocked

Offline sproingie

JGO Kernel


Medals: 202



« Reply #21 - Posted 2012-05-09 16:00:53 »

In an RPG, you're going to want to run automated simulations to test play balance.  Hardwiring dependencies on graphics classes in your game logic is going to make that sort of thing that much harder.  You don't have to be an Architecture Astronaut to follow some basic sanity guidelines.

Still, the lesson Cas is teaching is that you shouldn't start with heavy abstraction -- his libraries were factored out of existing code, so they'd already proven themselves useful.
Offline matheus23

JGO Kernel


Medals: 113
Projects: 3


You think about my Avatar right now!


« Reply #22 - Posted 2012-05-09 17:03:43 »

There was a time when I would make the "tools" my game would need in a way that I could use them in other projects. This soon became a complete mess to work with all these shitty "tools" I've made, most of which needed updating anyway because I'd have found better ways of doing things.

So I quickly scrapped that methodology and now I always rewrite everything and make things specific to the game and add things as I go along without worrying about making the class super flexible for other "future" projects.

I just rigorously sort similar things into folders/packages and I even use a few static classes (singletons actually).

A UML may help. I find myself tweaking/rewriting the UML constantly. UML are of much more help (imo) in group projects and coding things designed by others.. or when you know what you're doing (like in your case).

Acctually fun topic... I think there are 2 "types" of game programmers: one, who acctually just want to create a game, and some, who really want to create something, they can create games for 10 years with. Just have to say: CodyBunny's Rabbit engine? Cheesy

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline divxdede

Junior Devvie





« Reply #23 - Posted 2012-05-09 17:10:40 »

By example, when i wrote a game (always little games because i havent' sufficient commitment alone) i wrote because i love to develop.
It's a game because all the days i work on business application and want to add more fun when it's at home. But i don't do a game for the game itself.

I really think that this spirit is the ** bad way **, because i lost often some objectives and disgress often quickly and for too long time.
The functionnal end-result should be always the main objective but i can't work like it.

Offline davedes
« Reply #24 - Posted 2012-05-09 22:35:15 »

Acctually fun topic... I think there are 2 "types" of game programmers: one, who acctually just want to create a game, and some, who really want to create something, they can create games for 10 years with. Just have to say: CodyBunny's Rabbit engine? Cheesy
I think I enjoy programming toolsets/libraries/engines more than the games themselves...

Recently I've started making mini-games and demos alongside library/toolset development -- it helps me focus on productivity/practicality rather than thinking too much about "abstraction" and "OO wank," as Cas calls it.

Quote
Pro tip: do all the title screen, menus, and options first, before you start the game.
Heh, that's my favourite part, and generally after spending way too much time polishing a menu, I have no more motivation left to program the game itself.. Stare


For a big RPG, IMO one of the most important aspects is having a lot of game content. This means quests, items, areas, entity types, and more quests and items. A world editor would be pretty essential.

Offline SkyAphid
« Reply #25 - Posted 2012-05-09 22:56:42 »

Someone said "big RPG" is a bit vague, and I agree; so here's some details.

First of all, I'm not one of those idiots who go, "I'm gonna make the BIGGEST, BADDEST MMORPG EVAR!!1!", this is just a project I'm doing for STLP next year. I want to show all of those idiots who use Game Maker what a real programming language can do. lol.

Anyway, the game is essentially revolving around dungeon exploration that is randomly generated, in which take place in the players mind. (Imagine orthographic LSD dream emulator).

When he's not dreaming, he's going about his normal life and facing psychological problems.

So really, the game goes from:

Apartment Room
City
Dreams

and every one excluding the dreams need to have quick ways to add different events to each without making the engine ugly.

How should I organize it? Especially the game loop itself. I was thinking: Input, Logic, Draw for the loop, but I want your opinions. Also, should I make different classes for each game state, or have one core game state that loads different maps?

Thanks for the input guys, it's really helpful.

I may also be considering adding multiplayer co-op, seeing as I can just send the Seed for the dungeons to each player and just have an entity list sync. Which shouldn't be too hard in theory, but please feel free to enlighten me.

“Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is the doing something else.” ~Leonardo da Vinci
Offline jonjava
« Reply #26 - Posted 2012-05-09 23:57:39 »

Well, if you design it before you code it, you'll probably end up changing the design when you're coding..

Keep rendering and logic separate. Generally stay away from the Static key word. Your Game loop is just like any other game loop ever superb. You'll be fine.

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 835
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #27 - Posted 2012-05-10 00:29:53 »

This is by no means an advice, but this is how I code:

  • ensure enough sleep (mandatory)
  • make a short term plan
  • make a mess
  • make it work, GOTO 2 or 5
  • refactor until OK code quality, GOTO 2
  • make it public (optional) GOTO 2
  • call it beta & redirect stdout, stderr to your server
  • make it faster to the point where players stop complaining (optional)
  • make money (unlikely, unless dayjob)

Like Cas said, patterns and structure will emerge, don't force them in your code. Common sense helps, a design pattern here and there, sure, so point #3 should a temporary state, 1 day tops, or it will rot and emit unpleasant fumes. I can't stress enough how important a proper amount of sleep is: developing is 80% debugging*, and with enough sleep, you write fewer bugs, find the remaining ones faster, etc.




* a guesstimate, it might as well be over 90%.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ra4king

JGO Kernel


Medals: 355
Projects: 3
Exp: 5 years


I'm the King!


« Reply #28 - Posted 2012-05-10 02:44:04 »

I can't stress enough how important a proper amount of sleep is: developing is 80% debugging*, and with enough sleep, you write fewer bugs, find the remaining ones faster, etc.
I completely agree. There have been numerous instances where I've rage quit and gone to bed because I couldn't fix a problem....only to have a EUREKA!! moment as soon as I woke up Smiley

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 835
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #29 - Posted 2012-05-10 05:02:35 »

Rage quiting is only tolerable in PHP. Cranky

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (27 views)
2014-11-22 12:13:56

xFryIx (69 views)
2014-11-13 12:34:49

digdugdiggy (48 views)
2014-11-12 21:11:50

digdugdiggy (42 views)
2014-11-12 21:10:15

digdugdiggy (36 views)
2014-11-12 21:09:33

kovacsa (60 views)
2014-11-07 19:57:14

TehJavaDev (64 views)
2014-11-03 22:04:50

BurntPizza (62 views)
2014-11-03 18:54:52

moogie (77 views)
2014-11-03 06:22:04

CopyableCougar4 (77 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!