The core ideas of VatraLib

• All 2D games - no matter what genre they are - have one thing in common: they consist of a bunch of graphical objects, either still (like a tree just standing there) or animated (like a running player or a flickering fire)
• Only a few of those objects have some kind of specific behavior - like the player figure that moves according to keystrokes or the enemy figure that continually patrols from left to right
• What makes a game unique is only the behavior of these few objects and how they will interact with each other (and their surroundings, like walls or trees)
• Everything else - the mechanics of displaying graphical objects at certain positions, detecting collisions between them etc. - is common to all games
• When constructing different levels with certain special objects or events, it becomes especially clear that levels shouldn't be programmed - the objects within them should be programmed (that is, given their own specific behavior)
• What remains to construct a level is just to place the various graphical objects (some of them with specific behavior) within the virtual world
• By exploiting Springs capability of defining Java objects in XML, the act of putting together a level is taken out of the programming realm, enabling non-programmers to create levels for any game that uses VatraLib
• Thus, the amount of programming when creating a game is (almost) reduced to coding the behavior of all special objects (like the player object, some different types of enemies, and a few other objects like bullets and doors) in a uniform manner
• To prevent technology lock-in and to be more flexible in the future, all actual drawing-to-the-screen methods are decoupled from the core logic of VatraLib