Using code generation in your game.

Game Mechanics
#1

I was curious if anyone used code generation (writing code that writes code) in their projects. I haven’t seen the technique described in the context of java game development but I have dabbled in it a bit and have liked what it gives me and may look for opportunities to do more. I want two things which seem to work against one another. I want to be able to specify things in config/data files because it is often the most convenient and least error prone way to do so. I also want what I specify to be used as if it were hard coded and to take advantage of Java’s built in type checking. For instance, if I describe my ExplosionEvent message in a data file:

+ Explosion
  position mygame.util.Vector3
  strength float

I want to be able to say things like:

System.out.println("BOOM " + explosion.strength);

instead of

System.out.println("BOOM " + (float)explosion.getParam("strength"));

So I have code (in a separate project) that reads in the message config file, and generates a java file for each message definition in the appropriate directory in my game project code. (I suppose i could change the build so that it automatically creates a jar that I import instead).

public class ExplosionMessage extends Message {
	
	public final mygame.util.Vector3 position;
	public final float strength;


	public ExplosionMessage(Entity sender, Entity recipient, mygame.util.Vector3 position, float strength) {
		super(sender,recipient);
		this.position = position;
		this.strength = strength;
	}
}

Pros

  • More efficient. Properties are fields not entries in a hashmap.
  • lds not property maps. Message types are classes not a generic message type with a name parameter.
    Compile time safety. If, in my game code, I misspell a property I will get a compile time error, not a run time error.
    Because the fields are explicitly typed, I don’t have to do a lot of casting.

Cons

[li]Extra project/code necessary to do the conversion of config file to java classes

  • An extra build step

For me, the cons are hardly a bother (if you are using external config files, you need to write some code to read it into your game engine anyhow and running the CodeGen code takes seconds). Event messages are the simplest application of this because they are simple data containers but I could see the potential for trying to do more.

Does anyone else do anything like this? What has your experience been?

#2

mm,
I don’t quite understand why you want to generate a java source file from a config file.

The other way around makes propably more sense, generating some config data from a source file.

Besides, in Java one can use the annotations processing functionality of the java compiler for code generation. Just google it, its quite usefull. Take a look at project Lombock for example. In Netbeans you also get the benefit of support of this processors in your coding environment. http://netbeans.org/kb/docs/java/annotations-lombok.html

I for example wrote an own processor to automatically create the config files needed for the java util ServiceLoader: my processor

#3

Why not set up a simple GameRules by yourself class which reads all properties at startup (early failure in case of mispelling) with methods like getExplosionStrength() ?
That way, you wont duplicate the essential information.

Code generation is mostly a bad approach, IMHO. Quite popular in Java business development, though. Unfortunately.

#4

Add-On: If I want to experiment with different game paramters, I just want to edit plain text files. No build hassle. Could even be re-read while the game is running.

#5

so how do you think of compiling your generated source code at runtime?

I know that you can do it with a custom classlaoder and so on, but remember that only developers have the javac installed

#6

[quote=""]
The motivation is that I need a set of Java source files that all look very similar except for some minor differences. The config file allows me to express those differences succinctly. Thanks for the annotation processing links, I will check them out.

[quote=""]
I guess I am not quite following what you mean here. I have a set of messages each with their own set of properties. I am not using the config files to determine the content of the messages, only their structure. Or maybe I am confused by what you are saying.

[quote=""]
Funny you should say this given my background :). But yes, I agree that the code generation code can quickly get brittle and hard to understand. That’s why I picked doing it for messages, as the classes are very simple.

#7

Compiling the source at run time isn’t a big deal to me. If I need to create a new set of messages:

  1. Add it to the config
  2. Run the CodeGen project
  3. The source files are now injected in my game project

The only thing players will see is the final, compiled game.

#8

Now I am confused…

[quote=“actual,post:6,topic:38560”]

Hah ! Another business guy here 8)

#9

A significant part of my game is going to be event driven which means I am going to have a number of different message types. These message types will all inherit from a base class and are pretty simple except for the properties they expose. So let’s say I am writing a new part of my game and I need 5 new message types. Rather than write 5 new java files, with all of the boiler plate, I want to make entries into the config file and then run the code generation. It will read in the config file and produce the code for those 5 message types.

What I am not talking about here is save game data. The player would never see or interact with this set up. This is purely for me as the developer to use. Let’s say my game has 15 message types with an average of 3 fields a piece. That is 15 source files, 11 lines a piece (165 total) vs. a single file that contains nothing but simple parameters. I acknowledge that Doing this or not certainly is not going to make or break a game project.

#10

Ok, now I understand. But I wouldn’t generate event code. In fact I have events as well, and it sucks writing the serialization code each and every time.
With code generation you would have the same information twice in your project.
What if the simple code generation isn’t sufficient any more, what if some messages need special code, what if the generator overwrites changes by accident ?
If events would be based on external tools/formats maybe, but writing meta files by yourself instead of writing Java files ?

#11

For the messages I am talking about it works well because it is simple and there is no custom code per message but I do see where things can get complicated. Part of my motivation for posting this was to see if anyone else had tried and what their pain points were.

For instance different entity types respond to different messages but because they each respond to messages differently you couldn’t really do code generation unless you included the java code in the config file itself which seems like a bad idea.

#12

Concerning your original post: that is impossible.

Think about it this way: you want to generate new code at runtime, but you also want the non-existing variables to compile without errors…at compile-time. That makes no sense. Those variables don’t exist.

I think what you’re trying to do is beyond overkill. Make those variables exist at compile-time, since you already know you are going to use them.

#13

Maybe I haven’t been explaining myself well. I am not looking to generate new code at run time and it isn’t impossible as I have been doing it. This is about programmatically generating code that I then use at development time in order to develop the game.

Let’s say I am writing up some new functionality, and I think I am going to need 5 new types of events. How would I do this normally? I would write out the 5 new classes. I could then use them in my project. How would I do that in my set up? I would at the entries for the new Event types to the config file. Run the CodeGen (right click and hit run, < 6 seconds start to finish). The source for those same 5 classes are now in the proper directory in my game project and I can use them in my project just like the classes I hand coded.

What does it get me? If I need a new event called AttackEvent I can write:

+ Attack
attackType String
damage     int

instead of

package mygame.events;

public class AttackEvent extends Event {

   public final String attackType;
   public final int damage;

   public AttackEvent(Entity sender, Entity receiver, String attackType, int damage) {
      super(sender,receiver);
      this.attackType = attackType;
      this.damage = damage;
   }
}

The other thing it buys me is that it is easier for me to see all of the events I currently have defined as well as their properties. One nice list as opposed to n different java files. Think of it more like a JSP for java code.

#14

Ohh so you basically just created a program that creates the classes for you from the given properties. You so lazzyyyyy ;D

#15

Yes…and hell yes. :slight_smile:

Isn’t that supposed to be a virtue?

#16

Hmmm the only thing I have done similar to this is my particle editor which outputs .java class files so you can easily use them instead of writing every effect you want from scratch but it does not do it at runtime just makes a .txt file or something similar.

#17

I’m still confused over why nobody got the intent of your original post. It’s not like its rocket science.

What you are doing is OK, and at least >9000x better than working with (hash)maps to store properties.

Keep in mind that you overwrite Java source files: eventually you want to put methods on this Events, and you’ll run into trouble. I suggest you generate abstract classes, and extend them with the versions that provide the methods.

package mygame.events;

@@ public abstract class GeneratedAttackEvent extends Event {

   public final String attackType;
   public final int damage;

   public AttackEvent(Entity sender, Entity receiver, String attackType, int damage) {
      super(sender,receiver);
      this.attackType = attackType;
      this.damage = damage;
   }
}

public class AttackEvent extends GeneratedAttackEvent {
   // ...
}
#18

Thanks Riven, that’s a good idea. I know that I do not want to have pure java code in my config files but wasn’t sure how to apply this technique to game structures that include methods.

#19

The self rewriting code was in various languages for ages and after a longer/shorter while it was always announced as obsolete/unrecommended/bad/lame (regardless of what language it was, which is a curious thing :)). There were always 2 points raised:

  1. Inferior performance (missed cache in case of machine code/assembler language, unable to utilize the most advanced compilers in case of interpreted languages).
  2. It’s a bad coding practice (the end conclusion was always that the people who used it could have done it another way which would be better, in short people who used it were doing something wrong with their coding style or simply didn’t knew how to do it properly).

Again, this is a historical thing, not necessarily related to your concept. Still, so far all self rewriting/coding generation was always marked as a bad thing by a huge majority of programmers which means you should think twice if this does apply to your situation or not.

#20

Point 1 is not even relevant, as the code is compiled, just like everything else - hence this argument doesn’t hold in any language. Even if it was runtime generated, it would perform like any other class in Java, because the JVM does nothing but loading classes just in time (not to be confused with HotSpot/JIT). In short, why are you even bringing this up as a counter point?

Point 2 is even worse. So you’d prefer unsafe dynamic typing with lookups in hashmaps? Four downsides: overly verbose accessors, IDE refactoring won’t work, deplorable performance and a huge number of runtime errors, due to typos in the property names and/or assuming the wrong type of a property.

And please don’t say that you told us that it might not necessarily be relevant in this context, because the provided use case is trivial and could be taken into consideration before posting.