Can I figure out some way to treat these modules more as objects? Alloc'ing and dealloc'ing space for them like w/ "new()" / "delete()" methods... I'll need to keep track of what I create & free it all... Hopefully I'm not too tired to get some work done on the shooter when I get home today. And I should get that laptop from Mike, so I can try building it on Windows. So linked lists for the objects. Actually, just one list should be fine â enemies & bullets alike. Alright, so I updated the enemy code so it'll alloc & free & deal w/any enemy, not just one declared statically in the file itself. The display function now takes a pointer to the enemy struct; modify this so it traverses -the list- a list & optimally checks each object & calls the correct drawing code.
So I've almost got it built. One error, redefinition of a symbol. I can't remember which one. Hunt that down & hopefully I'm good. Then I can get back to coding the game itself. Sweet. It was the cygwin runtime, which actually sorta solves two problems. One: getting it to compile & run on Windows. Two: my worry that it would need the cygwin runtime.
Okay, I've got about the most rudimentary collision-detection system possible in place. But it is in place. Next let's do shooting & enemy AI? Moving left & right 'll slightly change the ship's momentum (very slightly) and I think it might be cool to have the ship's momentum slightly (again, very slightly) affect the angle @ which it shoots. Flocking AI for some enemies. Flocking is really beautiful in practice and I think enemies in a shooter is the perfect application for it. -could do something really cool w/the adaption of this. Add some sort of flocking rules to the player's bullets. Some sort of laser, spread, fire? Going to have to keep track of lots of bullets onscreen. So... Hey, what about that special-purpose programming language that guy uses to make those shooters? I don't think I necessarily want to use it, but it may be helpful. I don't know if an array is the best way to store bullets/enemies. The # of elements is constantly going to be changing. A linked list seems like a good choice - I've never really worked w/em, true, but the principle is pretty straightfoward. Can probably do a one-way linked list, but two-way is possible if I ever need to traverse it in reverse (or don't know the prior element beforehand) I'm going to need a really good collision-detection algorithm. I'll probably want to break the screen into sectors... That's tough: I don't really know how to go about it. But now's the perfect time to learn.
ed note: I don't know when this was written. None of the entries in my notebook are dated. It's the first reference I could find to the game. I'll be going through & adding all my other notes as time goes on. So alright. My task then is to make a very simple prototype. Collision detection & possibly shooting. I have till the weekend or Monday, whichever. This should be pretty easy. I mean, there's already a pong tutorial that I can work from. What license is Allegro released under? hopefully LGPL, not that I think we're gonna sell this. Even better â "giftware" â Completely free to do whatever the hell I want w/it.
Ok. Object creation (a ship, a wall, or some other obstacle). Collision detection (maybe some pre-written routines for this?) I'm so used to OO programming now that going back to functional (or "modular") feels weird. I suppose I could try & learn C++. Or use Ruby objects... Or Obj C...
