Switch Racer - day 1 progress
malcolmt on 2011/09/11 12:15
of Hermit Coder 42
— edited on 2011/09/11 12:16
Onto the actual game that won the decision process...
Switch Racer
It's your basic racer style game. Except your vehicle keeps changing. You have a series of vehicles available at the start of the race, with different properties in terms of speed, agility, weapons(?) and defensive capabilities. You order them and then start the race in the first vehicle. Every so often — and I'm thinking at least once per lap — you have to change to the next vehicle in the sequence. This will happen "magically" and isntantaneously, since my mental image is based around a series of magic students having a race (unclear if the graphics will support that vision or not).
Tactics feature in terms of how the vehicles work with different portions of the track. Maybe there are shortcuts you can take in smaller vehicles and maybe the more powerful ones are better uphill. You can only use each vehicle once, so you need to find the right balance (and have a decent vehicle left for the end).
As a twist, in some races, you can force everybody's vehicle to change to the next one in their sequence. So you aren't entirely in control of when things change and have to be prepared to react. If you get a bad vehicle for the place in the race you are, maybe you throw it away by self-changing immediately, losing any advantage it might give you elsewhere.
Code and progress
I've decided to develop in the open. I'm pushing my code to a github repository as I go. After 4 or 5 hours on this today, i have a pretty solid idea of what I'm building and a plan of attack. Starting out with a simple 2D overhead version of the race, since the mechanics aren't completely tied to the visual presentation. Ultimately, I'd like to use a 3D view, but if that falls afoul of time constraints or enthusiasm, I can stick to the 2D graphics.
Had a bit of a wrestle, both mentally and at the keyboard, with technology choices. I know I want to use PyOpenGL for the graphics (pyglet is out of the question, since it has a long-standing bug that prevents it working without a patch on 64-bit Linux systems with Nvidia drivers, which is exactly my system). However, I still need something to manage the windows and draw text, etc. Using GLUT felt a little too low-level and I was concerned about support on Mac and Windows (freeglut isn't the default there). So it was pygame or wxPython. Both of these do not build cleanly in a virtualenv environment. WxPython because they are "special" and don't build via setup.py. Pygame because it hasn't joined 2011 with respect to Linux systems yet and has a bug in the headers it's including (they also have some interesting problems with pip & easy_install picking the right version to download). Fortunately, the build problem is easily fixed with a local build and I've documented that in the README file to save people a couple of minutes. Still it feels very heavy to use all of pygame for one tiny corner of it, but I've made my choice and am not going to lose any more cycles on that one.
Tomorrow's goals
Get most of the 2D overhead version working on a simple oval or rectangular track. The graphical side is the straightforward piece here. Possibly the most fiddly in some respects, but not particularly brain-stretching. Modelling the game entities is going to be more interesting, but more details on that tech tomorrow.
(log in to comment)
Comments
jtrain on
2011/09/12 10:39:
gcewing on
2011/09/11 23:04:
Depending on how much GUI you want, you might find Albow useful:http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/
It allows OpenGL and pygame surface based widgets to coexist fairly easily.