projectx-develop Mailing List for Project X

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Comrades,

Not being able to test the DJGPP stuff last night, I now realize that
there were a few mistakes I made.  Redownload the zipfile and those
should, luck permitting, go away.  Good luck.  You'll need it. ;)

Ben

--- 
"Far and away the best prize that life offers is the
 chance to work hard at work worth doing."
       -- Theodore Roosevelt

Comrades,

Here are the instructions for getting everything working with DJGPP:

First, download these two zipfiles:
  http://www.netbrick.com/crowder/striker/striker.zip
  http://www.netbrick.com/crowder/striker/proto.zip

Unzip the two wherever you want.  Here's how to install Striker:

  Change into the 'striker' directory you just made
  Type 'make -f makefile.dj'
  Type 'make -f makefile.dj install'

Here's the Project X (aka Proto) instructions:

  Change into the 'proto' directory
  Type 'make -f makefile.dj'

It should all work.  If it doesn't, let me know and I'll fix the problem,
then reupload it.

Later,
Ben

--- 
"Far and away the best prize that life offers is the
 chance to work hard at work worth doing."
       -- Theodore Roosevelt

Comrades,

School's now out and most of us have somewhat more free time than we did,
which means that work on the real Project X can start anew.  Before we get
going, though, I need to know *for sure* who's in and who's not.  So if
you won't have time or you aren't interested or whatever, please e-mail me
(privately if you wish) so I can remove you from this list (this is more
for your benefit than mine -- it doesn't particularly bug me to have you
receive all of these messages ;)).  Anyhow, I need a list of people who
are staying with the project and whom I can count on.  This means that you
actually have to check your e-mail -- if I don't get a reply from you
within a week from Saturday (i.e. June 3), you're off the project (unless
you have an excuse, such as cancer or your house burned down or a similar
disaster).  I'm not trying to be mean here, but seeing how the project
rapidly lost members over the last month of school, I don't want to make
the same mistake again.

With that said, discussion can start on the game.  We're not going to
begin actual coding until you guys start talking about it, so get to it.
Look through the design doc, think things over, see if you can come up
with a way of doing something (or a better way), note any modifications
you want made, and send your ideas to the list.  It's brainstorming time.

In retrospect, as I noted before, this may seem like a snappy letter.  I'm
sorry if it comes across that way -- I surely didn't intend for it to be
so.  It's just 6:15 a.m. and so I'm understandably out of it. ;)

Ben

--- 
"Far and away the best prize that life offers is the
 chance to work hard at work worth doing."
       -- Theodore Roosevelt

Comrades,

I'm including the proposal sheet which I'll hand to Mr. Royce (along with
the design document).  If you think you won't be able to do your
assignment, let me know *now* so I can change it.  If you have any
questions at all, please e-mail me so we can get things worked out soon.
Remember, we only have five weeks to work on this, so we have to move
*fast*.

Project X Job Assignments
=========================

Short description of project: Project X will be a fast-paced multiplayer
action game.  Think Zelda 3 with twenty Links, all fighting each other.
It's not just a bloodbath, however (and, in fact, there won't be any blood
at all) -- strategy is required to maintain one's status and to beat out
the competition.

What's already been done: Ben has already written a tile engine, Striker,
which we'll use.  It works with Linux and DJGPP, but hasn't yet been
tested under MSVC -- the port will be part of the project.  Other than
that, there isn't much there.  Ben's started on a prototype, but it's
basically dead in the water for now.

Groups
------

Note: the first person in each group is the group leader.

Game Engine and Logic: Annie, Ben, Tom, Brandon, Nate
  The game engine will be as generic as possible, and it will basically 
  just take data in and spit data out.  Scripts will be written for the
  actual game logic, which gives us incredible extensibility and
  customizability (oh, how I love big words... ;)).  Things that will be
  covered by this pair (the engine and the scripts) are movement, enemy
  appearance, game rules, player characteristics, weapon characteristics,
  map features (i.e. teleports and such), combat, and so on.

Scripting: Matt, Tom, Cristian
  This group will interface the core game classes (written by the game
  logic people) with Lua, the scripting language we're using.  They'll
  work closely with the game group and keep everything up-to-date.  In
  addition, they'll write scripts like crazy to test features and to make
  sure we can do everything we need to do.  They'll give feedback to
  basically all groups.

AI: Nate, Jonny
  Ideally, everything will be controlled by scripts, including the
  artificial intelligence.  Until the scripting and game groups get the
  interface set up, this will basically require sketching out ideas and
  putting them into pseudocode.  We'll use finite state machines for the
  implementation, with a full-featured script interface.  AI covers all
  computer characters, creatures, and possibly weapons.

Networking: Don, Ben
  The networking group will create an API for sending and retrieving game
  messages.  They'll be in charge of insuring synchronization between
  machines, making sure that everyone has the right data, and the chat
  system.  The API will also have a script interface.

Level design: Tom, Nate, Jonny
  These guys will strive to create the most entertaining and intriguing
  maps possible.  They'll create artwork and build a library of levels for
  use later on.  They'll also test things out like crazy.

Menus (Flash): Brandon, Cristian, Jonny
  This group will be in charge of all the flashy stuff like the menus and
  help screens and so on.  They'll write a menu system, and use it for
  setting options, connecting clients to servers, choosing maps, and so
  on.  They'll also be in charge of the title screen and the credits.

Implementation: Ben, Nate
  This is a kind of overseer group, insuring that things happen.  They'll 
  also be in charge of keeping portability alive -- which first requires
  porting the tile engine to MSVC.

Assignments (in alphabetical order)
-----------

These are the assignments for now.  Some are long-term, while others are
short-term (and thus new assignments will be given after the short-term's
are completed).  If any assignments are found to be a problem (i.e.
skill-wise), they will be given to someone else and a new assignment will
be made.

Annie:
  * Fleshing out the core game classes
  * Tweaking gameplay values (i.e. movement stuff)
  * Getting animations (players & weapons) working

Ben:
  * Core game engine (the initial classes)
  * Movement logic
  * Networking API
  * Chat system
  * Utility tools (Striker and friends)

Brandon:
  * Menu ideas
  * Design of menu system
  * Layout for menus (i.e. which menus we'll have, where they go, etc.)
  * Gameplay ideas

Cristian:
  * Test scripts (for all areas)
  * Documenting scripting interface
  * Menu implementation
  * Menu bugfixing

Don:
  * Networking API
  * Documenting network interface
  * Chat system
  * Server/client exchanges
  * Tutorial on network API

Jonny:
  * Core menu implementation
  * Menu graphics (look and feel)
  * Level design
  * Artificial intelligence for creatures

Matt:
  * Hooking script engine into game engine
  * Tutorial on scripting
  * Sample game (like Pong or Pacman) using script engine
  * Test scripts

Nate:
  * Weapon system
  * Level design
  * Artificial intelligence for computer characters & weapons
  * Finite state machine implementation for AI
  * Script interface for FSM implementation

Tom:
  * Object system (powerups and world objects)
  * Level design
  * Testing Striker script interface
  * Multiple floor levels (i.e. a base floor and a roof)

-------------------------

Have fun! ;)
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.

Comrades,

Assignments are due next Friday, the 31st.  That's an A-day, so either get
it done by Thursday or e-mail it to me on Friday.  At the very *least*,
give me an update report on where you are on it.

The Lua bindings are going fairly well -- I've been working Allegro hooks,
but they're being rather nasty, so it'll have to wait until later.  It's
not relevant to the game, though -- all that matters (as far as scripting
hooks are concerned) in Project X is Striker (done) and the game logic
(will be easy).  So things are looking good. <g>

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.

Don,

It's looking good.  A few suggestions are: for the type argument in the
send() method, 0 should send to all players, while 1-n send to that player
# (n being the number of players).  That way you can send messages to just
one person.  In fact, that would be kind of cool since you could send
messages to the AI players (and if someone wanted to write a script to
parse that input and reply, it would be even cooler ;)).  I think the
update() methods will just create a string with the client's info and 
then send that to the server -- i.e. something like this (without the
quotes):
  Player #   Name   X   Y   Move_X   Move_Y   Health   Armor Strength" 
  "2 Bob 203 193 5 -2 95 33"

Of course we'll need to update information on which weapons the player has
and how much ammo and all of that too.  Once I finish coding the prototype
(which is after I finish coding the Boulderdash tutorial), we'll finalize
the game classes (all those .h files) and then start writing script
wrappers.  Once that happens, work can begin in earnest.  Until then, look
around for ideas and do your assignments.

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.

On Wed, 22 Mar 2000, Don Jordan wrote:

> Ben,
> 
> 	Here is what I think should be in wrapper class at present.  If you would
> like to change anything let me know and I will see if I can figure out how
> to do it.  Also where it says I'm not sure and has a question mark if you
> could possbily fill some of those in.  I'm unsure of what arguments will
> be.  It all depends on how the other things are going to work.

Matt,

When you have the block wand, you can create unlimited blocks (perhaps
we should limit this, and make it use ammo?).  The blocks stay forever,
but you can push them around, which balances that out.  Maybe the blocks
"slide" out from you -- so when you create them by waving the block wand,
it's as if you had kicked them.  Or maybe we should just keep it the way
it is and have the block appear X pixels in front of the player.  What do
you guys think?

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.

On Thu, 23 Mar 2000, Mathew Davis wrote:

> Ben,
> I was reading Nathan's reply and you answer about the block wand and I think
> that the block wand should do more than just one block or else the wan would
> be kind of hard to use but I don't think the blocks should stay for ever, if
> they were ever going to stay for ever.  you could just make a line of blocks
> perpindicular to the direction they were facing
> 
> ______________________________________________
> FREE Personalized Email at Mail.com
> Sign up at http://www.mail.com/?sr=signup
> 
> 
> _______________________________________________
> ProjectX-develop mailing list
> Pro...@li...
> http://lists.sourceforge.net/mailman/listinfo/projectx-develop
> 

let me know if you want me to pick you up today.

Ben,
I was reading Nathan's reply and you answer about the block wand and I think
that the block wand should do more than just one block or else the wan would
be kind of hard to use but I don't think the blocks should stay for ever, if
they were ever going to stay for ever.  you could just make a line of blocks
perpindicular to the direction they were facing

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Comrades,

Here are the Allegro and Striker URLs.  You need to get them both
installed and working ASAP.  Get to it. ;)

Allegro: http://www.talula.demon.co.uk/allegro/
   Go to the WIP link and download *that* (the 3.9.32 version, not 3.11).

Striker: http://www.netbrick.com/crowder/striker/
   Go to the download link and click on striker-0.1.zip.

Installation instructions will be forthcoming -- until then, I believe I
sent a message some time ago with instructions for DJGPP.  Just type
'make' if you're on Linux, and 'make -f makefile.dj' if you're using
DJGPP.  Afterwards, you'll need to type 'make' or 'make -f makefile.dj
install'.  Have fun.

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.

Ben,

	Here is what I think should be in wrapper class at present.  If you would
like to change anything let me know and I will see if I can figure out how
to do it.  Also where it says I'm not sure and has a question mark if you
could possbily fill some of those in.  I'm unsure of what arguments will
be.  It all depends on how the other things are going to work.
fill me in on the ride up

-nate
"can't type... too early"

Comrades,

I have some fairly good news -- Lua scripting is now interfaced with
Striker.  There are still a few kinks I need to work out, but it does load
maps and all of that fun stuff.  Scripts are incredibly cool... ;)
Further updates will be forthcoming (not tonight, though).

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.

Nathaniel,

Well, as to the AI players not knowing others are allied, that's a good
thing.  You have to look at it from the human perspective -- if we had
four players, and two players decided to ally behind the others' backs,
that's a strategy.  Keeping alliances hidden can be part of the fun.  And,
with a little extra work, the AI could notice that two or more players
appear to be cooperating, and use that in its strategy.  I'm not quite
sure what #2 means ("Make it so the bots only attack the things the team
leader attacks").  Care to explain?  There *are* teams, mind you.  But
"alliances" (which is what I think you meant) will be strictly virtual
(i.e. set up by players via the chat system).  It adds an extra element of
strategy, and the two humans also get to use the ice rod (as opposed to
just one).

Removing the grunts would be fine with me, though I must say that coding
them will be quite easy (you just take the carrier code and remove the
weapon dropping stuff).  If somebody can think of something cool to do
with them, we'll keep them in -- otherwise, they're gone.

Yes, carriers will have to pack a punch, and have a somewhat large radius
(this could allow for some excitement on small levels -- if you only have
to get reasonably close to a carrier, and you don't see the one in front
of you, all of the sudden you get zapped).  I'm thinking about half the
screen, perhaps a bit less (this is just a rough estimate, mind you).
I.e. if you're half a screen away from a carrier, you'll get zapped.
Also, on multi-floor levels (i.e. where you have roofs and stairs and
such), sometimes you won't be able to see carriers until you get zapped.
And you'll know that a carrier is nearby when you see the flash.  This has
some really cool potential as to gameplay... ;)

What I was thinking for the dark level idea was that each player would
inherently carry a torch (i.e. it's always on the player), and that the
small circle of vision around the player would always remain the same (but
we could have, say, the torch wand light up areas).  So it's a constant
torch at a constant size (though the size could vary by character).  It
makes life a lot easier (and what would you do if a player didn't have a
torch?  Wandering around in total pitch dark isn't terribly fun... ;)).
The block wand, at least as I'm thinking of it, will create a block in
front of the player, at the nearest tile boundary (i.e. draw a vector out
from the player in his current direction and put the block at the first
clear tile).  We don't necessarily have to place them at tile boundaries,
though -- in fact, we shouldn't.  They'll be able to be all over the
place.  So, I suppose, we'll just have the block be placed in the closest
clear area to the player (in the direction he's facing).  Having it placed
at the mouse cursor would be a cool idea, but we don't want to ostracize
those who don't want to use a mouse (like yours truly <g>).  This input is
good, by the way.

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.

On Tue, 21 Mar 2000, Nathaniel Newell wrote:

> One problem with the whole virtual team thing is that the AI players
> won't know their allied. Their are several solutions, 1) Remove them
> completely(crap) 2)Make it so the bots only attack the things the team
> leader attacks(could be interesting) 3) Make teams allowed(hard work,
> but it works).
> 
>     I don't think the grunts should be completely helpless. If they
> don't do anything then we shouldn't implement them. Although I do
> think they are a good idea we have an extremely short amount of time.
> 2 months anyone? If it were completely up to me, wich it's not, I
> would just say scrap um, although they could be cool are they worth
> it?
> 
>      Ben and I have talked a lot about the carriers and I am really
> pleased with the way they are turning out. We have to have them really
> pack a punch so people won't even want to be around them, so we can
> eliminate the whole follow the carrier cheat. I think it would be neat
> to have a standard amount of carriers for each map, i.e. 2 carriers
> for each map no matter the size. This would make larger maps more
> challenging and make smaller maps fast action. I don't think we should
> have places were weapons are set permanently. I think everything
> should be dropped by the carriers.
> 
>     I really like the dark level idea. Are we going to have players
> start with torches, or do the players have to pick them up? How will
> the block wand work? Will they appear in a set amount of distance?
> I.e. 50 pixels away? Or are we going to implement the mouse so they
> will just appear wherever the mouse is?
> 
> Just my thoughts,
>     Nathaniel
> 

One problem with the whole virtual team thing is that the AI players =
won't know their allied. Their are several solutions, 1) Remove them =
completely(crap) 2)Make it so the bots only attack the things the team =
leader attacks(could be interesting) 3) Make teams allowed(hard work, =
but it works).=20

    I don't think the grunts should be completely helpless. If they =
don't do anything then we shouldn't implement them. Although I do think =
they are a good idea we have an extremely short amount of time. 2 months =
anyone? If it were completely up to me, wich it's not, I would just say =
scrap um, although they could be cool are they worth it?

     Ben and I have talked a lot about the carriers and I am really =
pleased with the way they are turning out. We have to have them really =
pack a punch so people won't even want to be around them, so we can =
eliminate the whole follow the carrier cheat. I think it would be neat =
to have a standard amount of carriers for each map, i.e. 2 carriers for =
each map no matter the size. This would make larger maps more =
challenging and make smaller maps fast action. I don't think we should =
have places were weapons are set permanently. I think everything should =
be dropped by the carriers.

    I really like the dark level idea. Are we going to have players =
start with torches, or do the players have to pick them up? How will the =
block wand work? Will they appear in a set amount of distance? I.e. 50 =
pixels away? Or are we going to implement the mouse so they will just =
appear wherever the mouse is?=20

Just my thoughts,
    Nathaniel

Matt,

Since this really won't be an RPG (though the engine will be more than
capable of that), we'll leave the experience points for later.  *This*
game will be an action hack'n'slash arena.  As to allowing the players to
put in as many computer opponents as they'd like, you have a valid point.
In addition to the little NPCs (like the grunts and the carriers and
such), we *will* have computer players.  I neglected to mention that in
the design doc.  Each computer player will have its own team (that is,
each *major* computer player -- each little guy won't), and they'll be
capable of anything a normal player is capable of.  The server will decide
how many computer opponents there are, not the clients (but since the
server will be run by a player, most of the time, that's fine).  For
alliances, Nate and I talked and came to the consensus that it'll be far
easier and simpler to make alliances "virtual" -- i.e. "I'm with you and
you're with me, but we're still on separate teams."  See, remember that
the ice rod can only be used by the team captain.  If you have two humans
on one team, only one could use it.  But if you have two teams with two
humans working together, you have twice the power.  So alliances will be
set up just by the players talking to each other.  We're not going to
worry about subgames like Steal the Flag just yet, but they're definitely
a possibility in the near future.  We want to get the core game done first
(then we can write scripts for all of that).  Last man standing, though,
*is* the core game. ;)  What I was thinking was that at the bottom of the
screen each player would have a kill meter which shows how many kills they
have.  At the end of the round, a screen would pop up with stats on who
killed whom how many times.  By the way, thanks for the input --
discussion is very valuable at this stage in the game.

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.

On Mon, 20 Mar 2000, Mathew Davis wrote:

> Ben,
> The document sound really good.  The only thing is the experiance points for
> the characters we will have to decide which monsters will give you how much
> experiance points and how strong they will have to be to move up a level 
> (I.E. 8100 exp until level 10.)  Also I think that if we are going to have
> computers at all I think that the players will be able to place in as many
> computer oponunts as they like I also think that people should be able to
> alley them selves with people but we should put a limit on how many people
> can be on one team at a time.  also I think that we should have mini games
> in the multiplayer like steel the flag or the last man standing or something
> like that.  We should also have a kill limit or something like that or some
> way to show stats on how strong the player and how many times you killed
> curtian people and how many time you were killed by other people and by who.
> If anything sounds dumb or shouldn't be added just tell me I am sure we
> could talk about it and figure something out well that's all good bye.
> 
> ______________________________________________
> FREE Personalized Email at Mail.com
> Sign up at http://www.mail.com/?sr=signup
> 
> 
> _______________________________________________
> ProjectX-develop mailing list
> Pro...@li...
> http://lists.sourceforge.net/mailman/listinfo/projectx-develop
> 

Ben,
The document sound really good.  The only thing is the experiance points for
the characters we will have to decide which monsters will give you how much
experiance points and how strong they will have to be to move up a level 
(I.E. 8100 exp until level 10.)  Also I think that if we are going to have
computers at all I think that the players will be able to place in as many
computer oponunts as they like I also think that people should be able to
alley them selves with people but we should put a limit on how many people
can be on one team at a time.  also I think that we should have mini games
in the multiplayer like steel the flag or the last man standing or something
like that.  We should also have a kill limit or something like that or some
way to show stats on how strong the player and how many times you killed
curtian people and how many time you were killed by other people and by who.
If anything sounds dumb or shouldn't be added just tell me I am sure we
could talk about it and figure something out well that's all good bye.

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Comrades,

I've started playing around with Lua, and hopefully I'll have it hooked in
to Striker by the end of the week (fingers crossed ;)).  Since we're all
idling around waiting for something to happen, it's time for assignments.
They're in alphabetical order (by first name), in case you were wondering.
;)  If any of you have any questions at all, e-mail me.  We can't sit on
our haunches forever, guys.  Besides, this'll probably be the 4th term
grade for a few of you.  Have fun:

Cristian Moreno: 
  Some video footage of people walking around (from a top-view, so you'll
  need to get on a roof or a tall car or something).  We'll need them in
  all eight directions.  Once you have that, get it into computer format
  and chop it up into frames (we don't need all of them -- just eight or
  nine frames for each direction, at the very most).  If you want to get
  some sword slashing type stuff too, go ahead.

Don Jordan: 
  A rewrite of the networking class as soon as possible, with a
  post to the list of the source code.  If you can also write a short
  tutorial of the basics of the wrapper class (i.e. "This is how you
  initialize a connection, this is how you send data...", etc.), that
  would be good.  Comment the chat program, and we'll use that as a form
  of documentation as well.

Jon Cuevas:
  Find out how to do the generic input device in Allegro.  You'll need to
  read Vivace, and possibly search the Allegro mailing list archives as
  well.  Write a test program (or several) *with* comments.  We need input
  from the keyboard, mouse, and joystick.  Most of what you need *will* be
  in Vivace, so study that as much as you need to.

Matt Davis:
  Try to get SeeR working and hooked into Striker.  I'll work on Lua for
  the time being (as it's more...interesting ;)).  Once you have it in and
  set (hooked into Striker means that most, if not all, of the Striker
  functions are accessible through the scripting language), write some
  test scripts.  We need to find out which script language will work best
  for our purposes (which is full extensibility).

Mike Reynolds:
  Research game networking.  We need to find solutions for a handful of
  issues: Synchronization.  Each client needs to stay synchronized so
  weird things don't happen (you understand what I mean, of course ;)).
  We need to be able to send the map data in chunks to each client, so
  you'll need to find out how to do that.  Also, if you can look into
  having clients connect/disconnect at any time, that would be good too.
  Mainly just look into real solutions for these problems (which will be
  real problems shortly).

Nate Newell:
  Put all of your AI ideas down on paper (well, textfiles would be
  better).  We need pseudocode (gasp! shudder! ;)) on all of the
  algorithms, so that we'll be able to transfer them almost directly over
  to scripts once we reach that stage.  For the time being, since the game
  structures still aren't in place, just act on a more general level (i.e.
  instead of "player.x_vel += 50.235", put "player moves right by
  50.235").

Scott Burton:
  Get Striker compiled and running on Visual C++.  Now that we have the
  compiler at school, it'll be quite easy.  Once it's working, everyone
  can see the progress we're making, which will (hopefully) stimulate and
  inspire work.  Make sure that Carto and all of the utility functions
  work as well.  Take notes of what was required to get it working (we'll
  post them on a website once we get to that point).

Tom Ouyang:
  The game logic needs to maintain a constant frame rate (i.e. 60 fps),
  while the graphics loop will only draw when it gets free CPU cycles.
  This will keep the game synchronized to a large extent.  However, this
  doesn't happen magically, and it's your job to figure out how to do it.
  There are quite a few messages in the Allegro mailing list archives on
  it, so you'll need to do some digging and write some test programs.

Everyone:
  Get Allegro installed.  Get Striker installed.  Get cracking. ;)

Yours truly: 
  Write Striker tutorials, work on the design, and set the stone rolling.
  And get Lua hooked in.

Listen, fellows.  Nobody's replying to any of the messages on this list --
while not necessarily evil (okay, it is, but that's beside the point right
now), it's not helping very much.  I want this to be a team effort, not a
one or two person project.  Start checking your mail more frequently (once
every two weeks doesn't quite cut it), and *reply* to messages.  We've
had, what, two or three messages on the list from people other than me in
the last three weeks?  Come on...  If you're too busy to help right now,
but would like to later on, then let me know.  I need to know who I can
count on (right now is the part that matters most, and if I can't count on
you then you may as well wait until later).  I'm sorry if this sounds mean
or rude in any way -- it wasn't meant to be.  I want to see this project
succeed, and I need your cooperation.  Thank you.

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.

Comrades,

Striker now has a website.  So far it just has download links, but it's
better than nothing. ;)  The instructions for installing are in that
message I sent a few weeks ago.  Try it out and see if you can get it to
work -- then send a message to the list describing what happened (if it
worked, if it didn't, etc.).  I'm going to write a tutorial on how to use
the map editor, today if possible, so look forward to that as well.

http://www.netbrick.com/crowder/striker/

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.

Comrades,

I've attached the latest incarnation of the design document for the game.
It goes through most of the gameplay issues.  Look through it and if
there's anything that particularly annoys you or you think would be awful,
let me know.  And if you have any additions, also let me know.  I'm
working on a prototype right now, which I want to finish before tomorrow
night if possible (right now I'm fixing a bug in the map editor).  I'll
give out assignments after I finish the prototype.

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.

Comrades,

No, Project X is not dead (though since it was never alive to begin with,
I suppose it's not much of a difference). ;)  With the programming
competition and the end of term, it's been hectic and I've been a zombie.
But, as of today, Project X is revived and will soon get in gear.  I'm
going to revise the design document tonight if possible, getting the
gameplay down and anything else I can think of.  Then I'll give out
assignments and deadlines.  So if any of you have any ideas, you'd better
tell me soon. :)

And as for Matt's message, is anyone opposed to team leaders?  If I don't
hear any opposition by next week, I'll assign leaders and start giving out
assignments.

Finally, everyone who is still interested in helping with Project X (in
any way -- even if it's just a wee tiny bit), please send a message to the
list so I know your pulse is still going.  Dead programmers aren't much
use (though they can make rather nice decorations if the coloring hasn't
gone too sour). <g>

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.

On Wed, 15 Mar 2000, Mathew Davis wrote:

> I think that We should have team leaders because we ne someone to lead
> people and divy out assignments and organize the individual groups and set
> deadlines arrange meetings and set things into motion.  Also we will need
> leaders to push people to get this thing going otherwise I think this
> project is going to start of slowly and we will have no chance of finishing
> project x
> 
> _______________________________________________
> ProjectX-develop mailing list
> Pro...@li...
> http://lists.sourceforge.net/mailman/listinfo/projectx-develop
> 

I think that We should have team leaders because we ne someone to lead
people and divy out assignments and organize the individual groups and set
deadlines arrange meetings and set things into motion.  Also we will need
leaders to push people to get this thing going otherwise I think this
project is going to start of slowly and we will have no chance of finishing
project x

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

bring games...    Lots of em.

bring headphones. As much as I would like to hear different things =
coming from 20 different speakers, yeah, you get the picture.