|
From: Ben C. <cro...@ne...> - 2000-02-16 02:32:32
|
Comrades, While doing some looking around tonight, I ran into another scripting engine called SeeR. Considering that I found it on the Allegro website, I think we can safely assume that it in fact coexists nicely with Allegro. That's a good thing. ;) I don't yet know if it's easier -- I haven't played around with it yet, since I've been working on the tile engine. Matt, this would fall under your area, so have at it. :) The URL is at the bottom of this message. Everyone needs to either download Allegro at home and install it or else start playing around with it at school. The URL is at the bottom -- if you need help with installation, just ask me. Play around with it, get a feel for it, write a few test programs and see what you can do. While everyone doesn't necessarily have to be familiar with Allegro, it will make life easier for all of us. Okay, assignments. Here are the ones I came up with in class -- if you have serious objections to what you have, tell me quietly (private message) and I'll work with you. Drum roll... :) Scripting (SeeR vs. Lua) : Matt Davis Artificial intelligence : Nate Newell Sound and music : Brian Buss Character movement : Tom Ouyang Networking : Don Jordan Graphics (sprites, tiles, etc.) : Brandon Love Game logic : Annie Yu Libraries (encryption) : Harley Liston Flash (transitions, menu screens, etc.) : Cristian Moreno Here are quick summaries of what each assignment entails. If you have questions, e-mail me. Scripting: Finding out the pros and cons of both SeeR and Lua, writing test programs and scripts, seeing how much we can do with each, getting a basic grasp on both languages and deciding which would work better (i.e. most flexible and easiest to learn). Artificial intelligence: Since this primarily depends upon the script language, at the moment this just means looking for ideas on how to do various AI. Finite state machines, pseudocode scripts for enemy movement, and a general grasp on the topic. Sound and music: Finding out how to play WAV samples in Allegro, and how to play MOD modules (the music) -- probably needs an add-on library, which you can get at the Allegro website. Not only playing WAV samples, but doing cool things like panning and (if possible) mixing multiple samples and such. Character movement: Finding the best way to move players around. A test program is all that's really required, where you can move the player around with the keyboard. Getting input from multiple devices (mouse and joystick in addition to keyboard) could fall under this. What we're looking for is a method that feels best and looks best. Networking: I've already written 80% of a client/server program, and this would just entail finishing that, learning libnet, and writing a wrapper class (for libnet). What we need is some kind of messaging architecture that doesn't care about how we do it (high-level, not low-level). Graphics: Basically drawing stuff -- this can be either hand-drawn art or photo-manipulated stuff (like a Photoshop pattern). We need sprites and tiles. If we can find public domain art to use as placeholders until we get real art done, we'll use those -- so this assignment would entail looking for such repositories. Game logic: This is the game-specific information; what each player has as attributes (i.e. strength, weapons, etc.), how and when weapons and power-ups appear, how often and where computer AI characters show up, how the winning/losing will work, etc. This is the most theory-centered assignment, and so it's basically just a list of ideas. We'll implement most of them later on in scripts. Flash: These are screen transitions (fades, dissolves, etc.), menus, and so on. If we can get functions that do the transitions from one bitmap to another, that's best. This one will need a knowledge of Allegro. Libraries/encryption: Since we don't want all of our finished scripts to be accessible by the average dumb user (who wants to tweak things so he can cheat), we'll put them into libraries and encrypt them. I believe Allegro has facilities for this (datafiles and packing), so that's a possible option. The first deadline for basic research in these areas is Wednesday, the 23rd. Get as much done as you can by then and we'll work from there. More ideas -- I'm thinking of storing the maps and tilesets on the server, which would make life easier on one hand (you don't have to worry about multiple copies of the map, about clients changing their copies, and you can do cool stuff from the server), but harder on the other (getting the map and tileset to the clients). I've been looking at a possible solution which would work fairly nicely, but it's still kind of vague. Basically it's this: the maps are subdivided into "chunks" of smaller areas, and the server sends only nearby chunks to the player (I'll explain this better later on). Just something to think about. Remember, we need feedback. Look through everything we have so far and give us your input. Here are the addresses: SeeR: http://home.elka.pw.edu.pl/~ppodsiad/seer/index.html Allegro: http://www.talula.demon.co.uk/allegro/ Later, Ben -- "The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy." -- Martin Luther King, Jr. |