Python Snippet: Converting a complex object to json


Here’s a simple recipe, to convert most Python class-objects to json and back.

Here’s the setup:

import json

class Foo:
    def __init__(self, name, values): = name
        self.values = values

Converting to json:

an_object = Foo('John', (123, 456, 789))

json_string = json.dumps(vars(an_object))

Quite simple, isn’t it? Using the vars function, Python converts the object to a dictionary which can then be jsonified, using the json.dums function.

The reverse is quite simple as well:

a_fresh_object = Foo(**json.loads(json_string))

This simply takes the output of json.loads, which is a dict, and maps the keys and values of that dict to the names arguments of Foo’s __init__ method.


So long…

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

Writing Python Function Decorators

Python has a pretty neat way, of letting you write function decorators.

A Function decorator in general, alters or appends to the functionality performed by the decorated method, without having to directly depend on or know it.

Thus it is possible, to use decorators to declare aspects, without re-writing the same code over and over again.

In python, you can decorate a function by using the following syntax:

def my_function(arg1, arg2):
    print "Something with %s and %s" % (arg1, arg2)

By doing that, python exchanges any calls to your method, by calls to the decorator, defined as my_decorator. This decorator can now decide, to do some additional work and (if wanted) call the original function.

To define a decorator, you have to write a function factory. That is a function, that defines and returns another function, that can be called with the original function as an argument.

def my_decorator(argument):
    def outer_wrapper(original_method):
        # This code gets called, when the decorated
        # function gets defined

        def inner_wrapper(*args, **kwargs):
            # This method gets called, instead of the
            # actual function call to the decorated
            # function.
            print "I come from before the function"
            return_value = original_method(args, kwargs)
            print "The method returned %s" % return_value
            return return_value

        return inner_wrapper
    return outer_wrapper

Have fun.

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