For another project I am working on we use Qt as a portability layer and hence also qmake for our build tool. We are also utilizing some other open-source libraries such as lua and bullet for which we also use qmake. For lua our qmake project file looks (similar) like this:

TEMPLATE = lib
CONFIG += dll
TARGET = lua
DESTDIR = ../../../bin/
 
INCLUDEPATH += ./
 
SOURCES = print.c \
    lzio.c \
    lvm.c \
    lundump.c \
...

and the funny thing is that it creates in the destination folder three symbolic links with names liblua.so, liblua.so.1, and liblua.so.1.0 that all point to the file liblua.so.1.0.0. This is the case for every library, eg. libname would result in the links libname.so, libname.so.1, and libname.so.1.0 and the actual library would be libname.so.1.0.0.

This all is due to the versioning that qmake does automatically for the libraries (e.g. projects with CONFIG += dll).

Now to disable it, you have to add the keyword plugin to the CONFIG specification in your qmake project file:

TEMPLATE = lib
CONFIG += dll plugin
...

After doing so, all the links disappear and you end up with a single liblua.so (or libname.so) as one might want to have it in the first place.

Now that is done … back to work!

I recently bought the third edition of the book “Game Coding Complete” from Mike McShaffry (a.k.a. MrMike) et al. which has been very delightful to read so far. I have been reading a few chapters which gave me a new way of looking at game architecture and other things that I was convinced that I already understood them quite well.

One of them is the famously known Design Pattern: the Model-View-Controller. To me, the Model always was the data that is being modified, the Controller takes care of the input (mouse, keyboard, maybe network, …) sent to the application and the View simply displays the data. If you want to improve graphics – you work on the View. You want to update keybindings in your input system – you’ll modify the Controller. Also the Controller keeps track of the player id that tells us which entity is being controlled by the player. Need a new type of vehicle / weapon? – Go to your Model (and of course, add code to the Controller and View to reflect them).

So far so good.

However in this book Mike gives an overview of a game architecture consisting of three basic parts: the Application Layer, the Game Logic and multiple Game Views. The Application layer hides the platform specific from the game and the Game Logic resembles what is going on in the game. The Game Views represent the game from different perspectives e.g. for a human player or a AI agent.

Game Architecture after Mike McShaffry

At first my head tried to map them onto a Model-View-Controller which failed as they resemble completely different things. Especially the description of the Game View gave me a different way of looking at the View in a Model-View-Controller. The Game View does not only display what is going on in the game, instead it also takes care of the input handling. More specific: the Game Views receive all the input events (key presses, etc.) and communicate with the Game Logic over events.

At first this seems a bit awkward concerning to what I wrote further up concerning the View, but giving the view the ability to receive input and send events has some nice properties. For example it might be “easier” to add a split-screen mechanic as each player has its own Game View (remember: we have multiple Game Views!) and also its own keybindings. Also one could imagine having a GameEditView which has completely different abilities than e.g. a HumanGameView. This gives the View more power as it also contains not only the way how you look at things but also how you interact.

Maybe I got it all mixed up, however I think it one shouldn’t be too strict on saying input is clearly handled in the Controller or that the job of a View is drawing only.