Last week, Evan talked to us about the Game Cabinet, a Windows-based arcade machine in the Union to show off Game Dev games. To get your game working on it, you have only to install your exe on the machine, provide your author etc information in an XML document, and set your game's keyboard controls up with the cabinet's settings. Talk to an officer to get the details on the key bindings and XML format.
We also heard from Franklin, who gave us an update on his helicopter mining / digging game. He's planning on submitting it to a few competitions, with the deadlines approaching in three weeks. Since last time we saw it, the game now has a functioning store, and boundaries on the world, thanks to feedback he had received from club members and outside testers (testing & feedback == very important!)
Dan gave us a high-level tutorial on collision detection theory, using a method of projecting 'shadows' of objects onto axes perpendicular to the polygonal face being checked. He also discussed how to check for a collision between frames (for example, a bullet which is on one side of a wall in the first frame, and on the other side of the wall on the next frame -- of course this must register as a collision, even though no frame has the two objects colliding).
Chris gave a brief word of wisdom on loading grid data from a text file -- for example, loading a 2D map from a file which has rows and columns of 1's or 0's for wall or no-wall. The problem is that loading [row, column position] from a text file (aka reading normally, top-to-bottom, left-to-right) to your map array as [x,y] will reverse X and Y. So, you must switch your nested reading loops to make the program read [y,x], which, when reversed, will give you the correct [x,y].
Tonight, Andrew gave us a more detailed Python tutorial, including drawing to the screen and basic movement, and Justin let us in on a few of his techniques and algorithms for creating procedural maps. (Gentlemen, feel free to provide some more substance to this meek little mention, my notes are non-existent and my mind is failing me. Face-palm!)
From what I (Jono) hear, apparently Thomas, Russell, and Ben also showed their
Project Needlemouse (
projectneedlemouse.com) at some point, while I was too busy with my weekly Wednesday tacos and rum (it can't be stopped, not even by the pressing duties of the Secretary). Their game is a mock of my
Needlemouse, and has garnered them some interesting attention:
- They received the best comment the internetz have ever spewed forth: "Tails looks like an abortion."
- The game was featured on Joystiq, and declared "likely less of a disappointment than Sega's upcoming Project Needlemouse"
- The gents got a contract Flash game offer out of it. How is a mystery to me. But congrats.
This activity was designed to introduce members new to Game Development to the concept of The Black Box, or, more textbook-like, modular development. Members wrote new definitions for bullets, targets, and explosions in simple Python files, and just imported them into Chris' base code (without any knowledge of how that base code works) to create new functionality in the game. This activity encapsulates, on a small scale, how a larger-scale game would be put together: one programmer writes the physics, another writes the display, another writes the movement controls, each module treating the others as 'Black Boxes': knowing only the input and output, not having to worry about the specific implementation. When brought together, these modules create a game.
Fig 2: From time to time, you'll find yourself with many components. 
