Game Dev Diary 5: About Textures and 2D

After we finished the control schemas last time, it’s time to look a bit deeper into OpenGL.

Since we want to be able to build a basic UI, we will take a look at drawing 2D in OpenGL today. Also we will have a look at texturing our scene and UI elements.

Continue reading

Game Dev Diary 4: Extending the Control

Last time we started, adding control elements to the scene. We defined a controller class, that could take gamepad input and manipulate the camera position accordingly.

Today, we want to extend that, by adding keyboard and mouse control. For this simple scene, we want the user to be able, to use all three control schemes simultaneously.

On the Keyboard, the user should be able, to control the latitude and longitude via WASD or the arrow keys, and the center-distance via 1 and 2 or 9 and 0 respectively.

With the mouse, latitude and longitude should be controlled via the movement of the mouse, while using the mouse-wheel to control the center-distance.
Continue reading

Game Developers Diary 3: Getting in Control

In the last chapter we created a pretty cool scene with movement and sound.

Today we will take a look at the most important UI interface for games ever: Controls. Until now, our scene was pretty static, with the camera flying around wildly on a kind of weird, prescripted path.

Let’s implement some controls, to steer the camera on a spherical path around the main cube. Imagine a sphere around the cube and the camera as a kind of bubble on the outside of that sphere; always looking into the center. The user can choose to fling the camera-bubble along the latitude and longitude of this imaginary sphere, as well as shrink or grow the sphere itself (make the radius closer or wider).

We want to end up with a program, where the user is able to control the scene via a Gamepad, the keyboard or the mouse as he chooses.
Continue reading

Game Developers Diary 2: The world is alive with the sound of OpenAL

In the last chapter we learned a bit of basic OpenGL functionality. While not enough, to be actually useful in a game, it got our appetite wet and gives a good base, from which to investigate further.

Today, we will mainly leave OpenGL behind and focus on the other second-most important user interface in games: Sound.

More to the point: Sound, using OpenAL. That choice is convenient for a few very simple reasons:

  • It’s available in nearly any possible target system
  • It’s open and rock solid
  • It’s very simple to understand
  • It has most of the basic features, you could want from a game sound interface

Continue reading

Game Developers Diary 1: OpenGL and Cocoa

I am currently doing some basic research, how one could make games with basic OpenGL, OpenAL and system dependent libraries. At the end of which a simple multi-plattform game engine should be the goal.

I will post updates to the things I found out here, in form of a diary/tutorial as soon as I reached another milestone along the way.

Since I start developing on my Mac, we will also start supporting the Mac and move up from there.

Creating an OpenGL enabled application on OsX Lion

Our first project, to get a hand on OpenGL on the Mac, will be, to create a simple application, that draws a rotating cube inside a Cocoa View and behaves nicely with the system. It should work in Window-Mode and support the Lion’s way of doing fullscreen.
Continue reading

Day 2: Using Python to compile C++

This is the next step, in creating a simpler C++ build environment.

The tools available, to build, compile and link in C++ allow you a great freedom in how you may set up your final application. That flexibility comes at a higher price in complexity. Most of the time, you would want to build either a framework, or an application, using a standard approach, that works best on your chosen target environment.

If the goal is, to have a build environment, that is extremely easy to use, using the convention over configuration approach, one step on that road is to simplify the compiling & linking step in the chain. In the end, the compiler interface should know which target it is supposed to be building for, which libraries and includes to use and which sources to compile into the final product. It should behave similar on any supported platform. The end-product of the compilation step should be a static or shared library or an executable.

To accomplish that goal, I created a compiler Class in Python, that gives me the abstract handles I need and implemented it for OsX. I also wrote a simple script, to call the compiler.

Next up:
Integrating this compiler and a script to automatically create a main for the UnitTest framework, from Day 1 so that I can run unit tests on any c++ project in a very simple way.

Day 1: A simple Unittest Framework

As I did rant about the lack of a useful build and test ecosystem in C++ earlier, I obviously needed to write my own for my development.

The first step for this is the Test Framework.

For every Unit-Test framework, one rule is more important than any other: The more difficult it is for a developer, to write and perform unit tests, the less he/she will write them. Therefore any unit-test framework that aims to be really used, needs to be as simple as possible.

For the development of my game engine, I will accomplish that, by utilising Python in the build itself, to automatically find any test class written, and perform the tests while building.
Continue reading