Switch Racer
Race around a circuit with a variety of modes of transport, each with different strengths and weaknesses. You can (and must) change your vehicle a few times each race and, sometimes, you can force everybody else's vehicle to change as well.
Careful planning of vehicle changes can help, but messing with competitors might be more useful.
Awards
Diary Entries
Switch Racer - day 1 progress
malcolmt on 2011-09-11 12:15
The theme wasn't one of my preferred options. Was initially a bit bummed about that, but then I had three reasonable ideas in the next couple of hours and spent the early afternoon choosing one (competition started at 10 a.m., Sunday morning for me). This is probably my second-favourite idea, but I'm kind of playing to the crowd a bit and I suspect it's more fun than my somewhat academically inspired favourite.
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.
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.
Another DNF
malcolmt on 2011-09-14 20:27
Well, life imploded a bit the last few days. No chance I'm going to get something finished by the deadline. Game over. :-(