I'm new to game programming, but not really to programming in general, and I thought it would be interesting to give it a try. At first I considiered using Lua, since it's what I'm most familiar with, but I would prefer to use a static language like C++, C#, or Java for performance and safety. The problem is that I'm not really sure how to manage the different types of game objects in a static language. I can probably think of something, but I thought it would be best to ask first:
* How to choose which class to make an instance of based on the object type name in the level layout file?
In Lua, since files can be loaded at runtime, the layout file could just contain the path to the script, which would be loaded at runtime. Even arguemnts to the object's constructor can be handled easily: just store them as strings in the layout file, load and run them as Lua code, and pass the result to the object's constructor.
In a statically typed langauge where all classes are built into the application and have names only known at compile time, the only obvious solution I see is to write a huge, centralized if/elseif statement that creates an instance of the right class based on the name given to it.
* How to load and unload the graphics used by the objects in the layout?
In Lua, I can have the object's script load the graphics and store them in a file-local variable, so the functions in the script have access to them. Since the references to the graphics are stored object scripts, and the object scripts are referenced by the "world" instance, everything will be garbage-collected when the level ends.
In a static language, the only solutions I can think of are to store the graphics in static variables, or load them when instances of the class are created.
With static variables, each class can have a static function, which is somehow called by the level layout loader, that loads the graphics into the static variables. The object's methods could then use these varaibles, simlilar to my Lua solution. The problem is that I'm not sure if static variables would be considered good practice, and second, this would prevent the graphics storage from being freed in a garbage-collected language unless I also add an "unload" method that clears the variables.
The other solution I can think of is to load the graphics inside the objects' constructors. Assuming that all objects are created when the level is loaded, this could be okay, but what if a new type of object is created by an existing object later in its lifetime? This will freeze the game while the new object's graphics are loaded.
* It's necessary for objects to find out about other objects of certain types for them to be able to interact.
In Lua, the object "classes" would just be table values, and they can contain a list of the other classes that they inherit from. This can let the "world" maintain lists of active objects that belong to each class, so it can have a function that takes a "class" table and returns all active instances.
Some static languages have runtime type information, but I'm not sure how well it performs, whether it can provide all the information needed, or if it's considered a good idea to use it heavily for non-debugging purposes like this.
It could also be possible to do something other than directly use classes to represent object types.
So the problem is that my solutions depend on the language having dynamic types and being able to load/unload code at runtime, and I'm really not sure how to make them work in a static language. I would guess that there are plenty of well-known solutions for these problems, which is why I'm asking. Any suggestions?