Game Internal Organization?

[princec]

As soon as a static becomes a problem, the Refactoring Fairy waves her magic wand and the problem magically disappears.

Cas

[jonjava]

Refactoring fairy?? o.O

[Damocles]

Theoretically static data is bad.
But theoretically a bumble-bee can not fly too.

Somehow it works, and is obviously practical.

And gamedevopment is not the same a business-process imlpementation.
The designpatterns try to cover the more corporate oriented approaches (wich is needed)

A game has other qualities, and other types of teams and development cycles (and payment $$ vs $$$$$$$)

[gouessej]

@dishmoth

@gouessej

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

:o

Ok I was a bit rude but that was a kind of joke, this remark should not be taken as a face value. Anyway I don’t want to spend any time in unpleasant code except with a compensation (money). Actually, that’s what I often already do at work :persecutioncomplex:

[loom_weaver]

@SkyAphid

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.

Just avoid second system syndrome. I did that once with an online registration system for karate tournaments. The first attempt took me about two weeks using servlets and a little JSP and I had something working.

The second time I used JSF (even wrote a custom component), put in localization (that I didn’t need), and 2 months later the database schema and codebase turned into an unholy design-pattern tower of Babel.

I’ve learned my lesson. Now whenever I code:

1. Add something new
2. Get it working while disregarding all design patterns
3. Refactor until you can stand the code-smell
4. Goto 1

If you ever find yourself blocked, then get lots of sleep and go for a walk while mulling it over.

[davedes]

[quote]A multiplayer architecture should definitely planned from the very beginning.
[/quote]
Yep, multiplayer should definitely not be an afterthought.

Other than multiplayer, these should also be considered:

• Who is your target audience?
• What is your target platform? i.e. Android support should also not be an afterthought.
• What’s the art style and how it will affect development?

[SwampChicken]

Carry around a notebook to scribble down ideas.
(I always get the best game ideas at worst possible times, like sitting in a dentists chair)

[ReBirth]

That Static thing again? static is good.

[Roquen]

The Refactoring Fairy doesn’t get enough love. “Hey! Let’s spend a bagillion man-hours writing abstractions to deal with extremely hypothetical future problems!” Screw-that. Love the fairy.

[65K]

Refactoring… yep, one of my favorite activities. One point why modern IDEs are such an important part of the whole development process. And one of the few advantages when you’re on your own cause you don’t bother no one with constant renaming, moving and the like.

Static… well, use it when it makes sense, naturally. Only that more often it doesn’t. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

[Gjallar]

@65K

Static… well, use it when it makes sense, naturally. Only that more often it doesn’t. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

So far in my cough “games” cough I’ve been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images[x].
Is this a bad way of going about this?

[davedes]

[quote]Static… well, use it when it makes sense, naturally. Only that more often it doesn’t. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.
[/quote]

[quote]So far in my cough “games” cough I’ve been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images

Is this a bad way of going about this?
[/quote]
In my opinion, we’re talking about two types of programming here: practical and theoretical.

Practical programming means getting shit done. If you save a week in the long run by scrapping your large object-oriented entity system and replacing it with tons of static references, then by all means have a field day.

Theoretical programming means doing it the way you would, say, if 100 professional Olympian game programmers were all assigned to create a video game on a 10 billion dollar budget over the course of seven years. Object-orient the shit out of that.

Both ways are important to learn, neither should be discouraged, and the best indie games generally strike a balance between the two.

Gjaller:
My last game did something similar, although using a hash map so I could access the images by name. Let’s just say, during the game’s public exhibition, none of our users noticed, cared about, or even understood our code. ;D

[sproingie]

You want a singleton, learn how to use Guice or PicoContainer. You really think it’s ivory-tower egghead abstract theory just to avoid using static? How about just the most basic ability to test things? That’s practical, right? I get the feeling like most advice is being handed out by people who just don’t understand the alternatives or won’t even bother to learn of them.

[65K]

@Gjallar

@65K

Static… well, use it when it makes sense, naturally. Only that more often it doesn’t. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

So far in my cough “games” cough I’ve been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images[x].
Is this a bad way of going about this?

What does static actually mean ? In your example, it means that all image loaders share the same set of images. Is that correct ? Very likely not. If you say you only need one image loader anyway, then maybe use a static image loader, but static images inside the loader is not bad but wrong design.
And making it public is the second broken encapsulation here.
Static breaks encapsulation because members are no longer private to specific objects.

Encapsulation is really, really important to keep software maintainable and stable.

[ReBirth]

[quote]Static breaks encapsulation because members are no longer private to specific objects.
[/quote]
Public is, not static. FTFY.

[Gjallar]

This might almost be a little thread-hijack, sorry about that, but now I’m really curious about what is bad about this code. ;D
Yes, I’m still quite the newbie.

package loaders;

import java.awt.image.BufferedImage;

import javax.imageio.ImageIO;

/**
 * Ist für das Laden der Sprites zuständig.
 */
public class ImageLoader {
	
	/**
	 * Speichert Sprites für die Achsen und den
	 * Start-Bildschirm.
	 */
	public static BufferedImage[] image = new BufferedImage[4];
	
	/**
	 * Läd sämtliche Bilder aus dem "resource" Ordner und speichert
	 * sie im BufferedImage Format.
	 */
	public ImageLoader(){
		
		image[0] = loadImage("title");		        //Title "S.T.E.P.S."
		image[1] = loadImage("deco");		//Deco für Title-Screen

	}
	
	/**
	 * Läd die einzelnen Sprites.
	 * 
	 * @param title Titel/Name des Sprites.
	 * @return Gibt das zu ladende Sprite zurück.
	 */
	public BufferedImage loadImage(String title){
		
		try{
			BufferedImage image = ImageIO.read(ImageIO.class.getResource("/resource/" + title + ".gif"));
			return image;
		}
		catch(Exception ex){
			ex.printStackTrace();
			return null;
		}
	}
}

Just ignore the javadoc. That code is part of my diploma and I had to comment everything nicely.
Thanks in advance

edit:
Then I create an object of this class when the user starts the program, so the images get thrown into the BufferedImage Array.
And then I simply use it in other classes like so…

g.drawImage(ImageLoader.image[0], x, y, null);

[ReBirth]

These’s not all, but here some points:

1. You use magic constant in indexing the array
2. If you won’t do anything to them except be drawn, use Image
3. It may be no sense but try change it to singleton

[Gjallar]

@ReBirth

These’s not all, but here some points:

1. You use magic constant in indexing the array
2. If you won’t do anything to them except be drawn, use Image
3. It may be no sense but try change it to singleton

Sorry, it might just be the fact that it’s quite early in the morning but i hardly understood anything of that.

1. magic constant? do you mean that the size of the array is 4? i deleted some of the code, it actually does store 4 pictures
2. Use Image instead of BufferedImage, I guess I understood that. but why?
3. Singleton ???
4. Sorry and thank you

[65K]

@ReBirth

[quote]Static breaks encapsulation because members are no longer private to specific objects.

Public is, not static. FTFY.
[/quote]
Don’t know what you actually mean here.
In the example, encapsulation is broken twice: by using public fields and by static, because image loaders do not hold their own private encapsulated images, but share them with other loaders.

[davedes]

An array is a poor way to store your images. What if you have 40 images after some more work on your game? How will you keep track of them all?
HashMap at the very least would allow you to store them by name.

You should definitely encapsulate your methods (getImage/setImage/etc). Don’t use public fields unless they are final.

[quote]1. magic constant? do you mean that the size of the array is 4? i deleted some of the code, it actually does store 4 pictures
2. Use Image instead of BufferedImage, I guess I understood that. but why?
3. Singleton Huh
4. Sorry and thank you
[/quote]

1. Magic number = Value with little meaning that should be replaced by a constant or some other means. i.e. If you have 40 images, using number 25 for the “player walk forward” image is arbitrary and poor design, whereas you could have used a final static int called PLAYER_WALK_FORWARD. The latter will lead you to less errors and easier debugging in the long run.
   http://en.wikipedia.org/wiki/Magic_number_(programming)

2. This allows you to use ImageIcons and VolatileImages without needing another list, as they all rely on the Image class for rendering (ImageIcon through getImage).

Following the same logic, let’s say you have a method that looks like this:

public void hide(JFrame f) {
  f.setVisible(false);
}

Since all you need is setVisible, you should use Component instead (which is where JFrame inherits that method from):

public void hide(Component c) {
  c.setVisible(false);
}

Later on, you can then use that method for any component that extends Component. It makes your code more flexible for yourself and others.

3. I’ll let you google that.