The programming lanugage used is C++. I was originally using plain C (C99 dialect), but later converted the entire code base to C++ (the idea was to start with C, which I was familiar with, and gradually convert the code to C++ in order to learn C++ properly).
Windowing & Input
To me, portability is an extremely important issue. Therefor I use GLFW for windowing, user input and timing.
Graphics are rendered using the OpenGL API. The choice was simple (easy to use, portable, programming language neutral, state of the art 3D, etc).
I decided very early on that I would only be using static models (vehicles, buildings etc) rather than animated models (such as walking monsters). With that in mind, I decided to go for a very simple mesh structure: a static binary bounding box tree. The tree structure is not absolutely necessary for the rendering, but it can come in handy in a number of different situations, such as: view frustum culling, occlusion culling, collision detection (although I plan to use a physics engine for that), and also bullet/model interaction (i.e. “did I hit the target?”).
Since I plan to use very simple maps (small arenas), I have not yet made any special map structure, as is often found in most larger games. I hope that the simple mesh structure will do - I will just use many large static objects to represent the map.
I am currently using the ODE (Open Dynamics Engine) physics engine, but I am looking at the Bullet physics library which is a C++ only library. It seems to have a cleaner API, and also seems to be more actively developed.
I tend to think that the sound is what really makes a game come alive, so I do not like to underestimate the importance of sound in a game. I have not yet figured out exactly how sounds will fit into the game engine, but I suppose some kind of event system will take form sooner or later, and when it does the sound will hopefully fit right in.
Currently, the FMOD Ex API is used for playing sounds. It has good 3D sound support, music playback, and it is highly portable. While FMOD is not an open source project, it is very powerful, and free to use for non-commercial projects.
OpenAL is another candidate. It might be supported as an alternative backend in the future, if required.
Quite early on, I knew that I would need some kind of scripting capabilities in the game engine. Since the engine is minimalist by design, I may not go as far as to scriptify all behaviour (e.g. as has been done in the Unreal Engine), but at the very least I need some way to describe maps (which models and textures to use, etc).
Since I have had some previous exerience with Lua, and it is both portable and very minimal, it was the obvious choice. You may already know that Lua is used in many different game engines.
It is very easy to integrate Lua scripting into your program, and since it is a full blown programming language, it can be used for much more than just parsing simple text files, making it both more readable and more dynamic compared to XML, for instance, which might have been my other choise for a map description language.