Step 2: interactivity.
In the previous article I explained how I implemented the event management. Now, our software bricks can talk to each other. Let’s get them to talk ! Well… let’s get them, first. We need bricks. The good ones.
Too often I started similar projects, focusing on an aspect such as the procedural landscape generation. It worked ! But I got stuck. I ended up with an ASCII dump of something representing a world, but I couldn’t do anything with it. There was no game built to explore that world. This time I want to start making the game interactive in the first place: we need to be able to explore before having something to explore.
I chose pygame for managing the input and the output. The input being the player’s fingers on a keyboard/mouse/joypad, and output being the screen and loud speakers reaching the player’s eyes and ears. Because I apply some kind of Model-View-Controller (I always say “some kind” because everyone has his own MVC), I will wrap the input in a Controller, and the output in a View.
We will have a PygameController and a PygameView class. I don’t want to use anything related to pygame in the Model classes, to make sure that when I decide to use a different rendering engine I only have to rewrite the input and output without touching the game logic at all. There will probably many other pygame-related views, probably one view per character to be displayed, for example. These views will be managed by the main PygameView. It would be wise to group everything pygame-related in one single package so that it can be replaced. Other views, like a console view for the server, would be kept in another package.
And, finally, we’ll need a game loop. I’ll go for the simplest game loop ever, but in a near future I shall write a whole entry on the subject.
Let’s get to work ! Very soon, the first screenshot ! I bet you can’t wait :).