Hi guys, I have written little java framework and now a space invaders clone based on the framework. However I am in need of good design for resource loading. I have some ideas on my own how to do it, but I wonder if there is some standard way of doing it. Problem is like this: another person is working on gameart and I want him to be able to define & load resources without compilation. As it is now, he can ofcourse write over old pictures & sounds with new ones since there are some hardcoded strings for player, alien etc. But hardcoded strings means for example that he can't change number of frames of animations without recompiling. What I plan to do is to make a simple text file, which will be read when game starts and it will contain all data for various classes with attributes & file references. Question is how to implement creation of classes with least overhead in both size & time? Factory pattern - one class to read file and other classes will request objects when needed? Or using factory to create all other game objects and pass them around to pieces that needs them in constructors or alike? I would also like to make factory class rather part of framework then particular game. What is standard way to do such things in games? Problem is that framework should not have to know what classes are needed in particular game, and I still don't want to rewrite factory class for every game. So is there a good way to dynamicly find objects in game without hardcoding class names in some if-else statement? Or maybe it's not the way to go? Help is highly appreciated. cheers :-) ______________________________________ edit: oki I think I'm looking for something like Spring, but simpler and much less in size. Any good pointer? [Edited by - smiley_horse on June 28, 2005 12:20:31 PM]

About caching - yes of course, I have already implemented caching with hashmap for sound and image files. Those are only resources used actually (beside 1 text file to init game with).

Problem here is to init classes from a text file, but without writing file parsing code in every constructor or such nor even once for every game. I don't want to init all classes at once neither. Even better, classes outside of framework woulnd't have to deal with any form of file parsing, while classes inside framework would not have to know class names in particular game in advance.

I have solved this with help of generic "GameClass" - It turned to be much easier then I thaught it would be. I have one class in framework to read text file which name I pass in constructor to that class. Game can then ask for particular class name like "getClass("Player") for ex. File reader will then attempt to find given name in textfile and read in all associated attributes & values in a "GameClass" object (with hashmap for attributes). Then "GameClass" object is passed to constructor of class that needed it so it can read data specific to only that one object (like number of lifes for player or such). "GameClass" also has some common code for all classes to get attributes (like getSpeed() or such which returns number instead of String for parsing).

So only code that really do file parsing is in framework in FileReader object, once and for all. Only thing a new game object has to do is to ask for GameClass with it's name and then read in data it needs from returned GameClass object. Some minor parsing of strings is still neccessary since hashmap stores all attributes as strings, but that's really minor thing to do.

I don't know how good is this approach, however it works. It would be nice to see some other solution.

By the way. I thaught about XML myself. I am using 1.5 version and I know there are xerces and xalan (or what are names) that cames in jdk, but I never used them. I was looking at few books, but I didn't want to spend a week or two on reading a book and experimenting when I can generally parse text file in 5 lines of code with BufferedReader. However if there is some good tutorial (fast to read) I would be glad to read it and implement xml instead of custom text syntax.