Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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 11261 times)
0 Members and 1 Guest are viewing this topic.
Offline 65K
« Reply #60 - Posted 2012-05-11 09:06:13 »

@Gjallar
The loader is also responsible for two different things:
1. loading images
2. storing & supplying images

The latter should rather be extracted into a separate class. Restricting responsibilities is a good thing.

Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


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

Thanks a ton guys.

As I said, I'm quite new to Java. I started learning it at the same time as i started with my diploma. So yeah... when I look at the code now all I can do is shake my head an giggle. At the very beginning every single one of my button-objects loaded the spritesheet, seperated it into the single sprites and finally picked the one the button uses.. and all of that happened in the constructor.
I've developed "perfectionism" in the last months which lead to the fact that I haven't finished a single project yet (excluding the diploma). I always felt the urge to rewrite everything. So now I pretty much HATE the code I wrote for my diploma, I couldn't start all over because there is a deadline (today in fact) and I can finally call it done and NEVER EVER touch this code again  Tongue

Last question... If i should write the loader in a private way, wouldn't that mean that every class that uses an image would have to create it's own object of the loader? Since I'm doing the loading in the constructor, wouldn't that mean that it would load all the images again, for every object I create from it? :/

Offline 65K
« Reply #62 - Posted 2012-05-11 09:26:24 »

Image loading probably happens once at startup or for level changing maybe. So you only have one place. And there shouldn't be that many places where you actually need the images. Split your class.
Do not load in the constructor. Do not hardcode images names inside the loader.

Keep on doing.  Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #63 - Posted 2012-05-11 09:48:27 »

Practical programming means getting shit done.
check.

Quote
If you save a week in the long run by scrapping your large object-oriented entity system ...
I'd say that "a large OO entity system" is bad even from a theoretical stand-point.
Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #64 - Posted 2012-05-11 11:26:56 »

What we really need is an image of a bunch of really old men sat on a park bench waving their sticks at passing youth. "When I were a lad, all this were static!"

For the OP:

I've been using, for the last 10 years or so, a system of resources that is basically a Map<String, Resource>. Everything that is anything in my games is a Resource with a unique name. Every sprite image, every alien definition, every tile definition, everything - all go into the Map. They can then all reference each other by name. I have the notion of "unnamed" resources but these are actually just given an autogenerated name instead at the point they are shoved into the map.

Cas Smiley

Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #65 - Posted 2012-05-11 11:29:38 »

Having loading the map right at app start up from a simple ObjectInputStream, I then iterate through each entry, telling each Resource to "create" itself. This is where it goes through its internal data referencing other Resources by name and resolves them into other Resources, and also the point at which I "upload" things like textures to OpenGL and sounds to OpenAL.

The act of simply attempting to retrieve a Resource from the map by its name automatically causes it to be "created"; thus you can get any Resource at any time and all its dependent Resources will be automatically "created" ensuring that you've always got a completely consistent set of objects. Circular dependencies are managed simply by preventing a Resource from being "created" twice at the same time.

Cas Smiley

Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #66 - Posted 2012-05-11 11:31:56 »

In my own games, the original data is all stored in (horrors) XML, in multiple files which "include" each other. So I've got all my sprite data, animations, particle emitters, alien definitions, all in XML, and I have a little build tool that reads in all the xml and spits out the resulting Map of Resources as a Java object stream. (Interesting factoid: object output streams produced on the desktop are binary compatible with Android - so I've been able to use the very same code to do builds on the desktop and then just use the data file on Android - nice).

Cas Smiley

Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #67 - Posted 2012-05-11 11:34:25 »

One extremely nifty trick I've used to facilitate saved games is a writeReplace() mechanism on the Resource base class which replaces actual instances of the Resource - which can be quite big, and certainly aren't serializable a lot of the time because they contain OpenGL state - with a placeholder simply containing their name.

This means when I save a game, all the sprites and so on are serialized but simply store the reference in the Map to their animation; not the actual "animation" itself. When a saved game is deserialized, all of these references are then resolved using readResolve() on Resource to replace the names back with whatever comes out of the Resource map with that name.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #68 - Posted 2012-05-11 11:43:47 »

In my own games, the original data is all stored in (horrors) XML, in multiple files which "include" each other. So I've got all my sprite data, animations, particle emitters, alien definitions, all in XML, and I have a little build tool that reads in all the xml and spits out the resulting Map of Resources as a Java object stream. (Interesting factoid: object output streams produced on the desktop are binary compatible with Android - so I've been able to use the very same code to do builds on the desktop and then just use the data file on Android - nice).

Cas Smiley

Do you still do the serialisation thing for new games? Because when I ripped off / rewrote things and turned it into Rebirth I skipped all of that and haven't really missed it. In fact it's much nicer not to have the extra build step.

Even doing the sprite sheet generation at runtime it's still near instantaneous to load.

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

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #69 - Posted 2012-05-11 11:59:31 »

Yes, I still do - it loads the map instantaneously (versus several seconds for parsing XML). The latest code I have, which is only for Android at the moment, uses annotations and a slightly better way of doing things which is faster, cleaner, and simpler.

How does Rebirth do it?

Cas Smiley

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

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #70 - Posted 2012-05-11 12:27:56 »

It uses annotations and a slightly better way of doing things.  Wink

It's basically the same - parse and xml file and create resource classes by reflection / attribute mapping. The big differences are multithreading things and holding onto resources via handles rather than directly so things can be hot-reloaded while the game is running.

I'm not deploying to android though, so my xml parse time is probably a whole lot less.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline SkyAphid
« Reply #71 - Posted 2012-05-11 14:18:53 »

Quick question,

Generally when I make my games, the entities in the massive list of entities have a method called tick() that is called in a loop from the list every step. Inside this tick method, I have the two methods that check logic and the other draws itself.

Is this okay, or should I completely separate the logic and drawing?

“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 #72 - Posted 2012-05-11 15:09:32 »

Still on Gjallar's problem, this tutorial may helps you to figure it out. Take a look on Kev's SpriteFactory.

@SkyAphid: better separate them, easier to debug.

Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #73 - Posted 2012-05-11 15:11:05 »

I have a tick() method, which is game logic, and an update() method, which updates sprite positions and special effects. tick() may be called several times between an update() if rendering is going slowly.
Neither method does any drawing. I do all drawing after everything has been ticked and updated by telling the sprite engine to go render itself. In other words, a typical game loop looks something like:

1  
2  
3  
4  
5  
while (running) {
tickEverything();
updateEverything();
render();
}


Cas Smiley

Offline SkyAphid
« Reply #74 - Posted 2012-05-13 02:22:41 »

I have a tick() method, which is game logic, and an update() method, which updates sprite positions and special effects. tick() may be called several times between an update() if rendering is going slowly.
Neither method does any drawing. I do all drawing after everything has been ticked and updated by telling the sprite engine to go render itself. In other words, a typical game loop looks something like:

1  
2  
3  
4  
5  
while (running) {
tickEverything();
updateEverything();
render();
}


Cas Smiley

So for example, your entity would probably have a getSprite() type deal where it checks the actions and what not and returns it based on those?

“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
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.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (26 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!