empyrean-devel — Development discussion

Re: [Empyrean-devel] Developement Issues

[TIMOTHY J F. <tj...@ps...>]

It seems that we dont need them. 

Next thing, what should I do?

On Mon, 27 Jan 2003 17:46:04 +0000, Chad Austin wrote:

> I think our problem is not the mailing lists so much as lack of motivation 
> and/or time.  I also don't think this game should be designed by a committee. 
> We need a cohesive team with distinct tasks, or nothing will get ever get done

> (even less than is happening right now).  Kevin is doing a great job with the 
> design document and andy was doing a great job with some of the important 
> subsystems.  Having one person in charge of something allows for quick
decisions 
> and a clear architecture (or structure, when talking about a document or
process).
> 
> However, I'm not opposed to regular meetings.  Are you going to plan them?
> 
> Chad
> 
> TIMOTHY J FITZ wrote:
> > It seems that these lists remain rather innefective in the sharing of ideas,
I
> > sugest we mandate an easy time to meet and have as many people make it as
> > possible, and officially decide on things there. (Like 10pm mondays, EST,
> > #empyrean on espernet)
> > -- Tim Fitz, tj...@ps...
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Empyrean-devel mailing list
> Emp...@li...
> https://lists.sourceforge.net/lists/listinfo/empyrean-devel
> 
> 

-- Tim Fitz, tj...@ps...

Re: [Empyrean-devel] Developement Issues

[Kevin G. <jan...@ci...>]

That or maybe everyone is too busy and doesn't have any particularly 
stunning ideas to share. I know both are true of me.

As for irc meetings, I'm up for that. But I have an unreliable schedule 
so I wouldn't make them very regularly. :/

On Mon, 27 Jan 2003 3:41PM -0800, TIMOTHY J FITZ wrote:
> It seems that these lists remain rather innefective in the sharing of 
> ideas, I
> sugest we mandate an easy time to meet and have as many people make it 
> as
> possible, and officially decide on things there. (Like 10pm mondays, 
> EST,
> #empyrean on espernet)
> -- Tim Fitz, tj...@ps...

Kevin Gadd

Re: [Empyrean-devel] Developement Issues

[Chad A. <ae...@vr...>]

I think our problem is not the mailing lists so much as lack of motivation 
and/or time.  I also don't think this game should be designed by a committee. 
We need a cohesive team with distinct tasks, or nothing will get ever get done 
(even less than is happening right now).  Kevin is doing a great job with the 
design document and andy was doing a great job with some of the important 
subsystems.  Having one person in charge of something allows for quick decisions 
and a clear architecture (or structure, when talking about a document or process).

However, I'm not opposed to regular meetings.  Are you going to plan them?

Chad

TIMOTHY J FITZ wrote:
> It seems that these lists remain rather innefective in the sharing of ideas, I
> sugest we mandate an easy time to meet and have as many people make it as
> possible, and officially decide on things there. (Like 10pm mondays, EST,
> #empyrean on espernet)
> -- Tim Fitz, tj...@ps...

[Empyrean-devel] Developement Issues

[TIMOTHY J F. <tj...@ps...>]

It seems that these lists remain rather innefective in the sharing of ideas, I
sugest we mandate an easy time to meet and have as many people make it as
possible, and officially decide on things there. (Like 10pm mondays, EST,
#empyrean on espernet)
-- Tim Fitz, tj...@ps...

RE: [Empyrean-devel] Empyrean wiki stuff

[Kevin G. <jan...@ci...>]

Awesome. I loved Diablo 2. :)

Kevin

-----Original Message-----
From: emp...@li...
[mailto:emp...@li...] On Behalf Of Chad
Austin
Sent: January 21, 2003 10:08 PM
To: Kevin Gadd
Cc: emp...@li...
Subject: Re: [Empyrean-devel] Empyrean wiki stuff


> Also, just up front - is the gameworld going to be persistent at all? 
> Are we only going to save what the player has accomplished, or are we 
> going to save some of the world data, or none at all...? That's the 
> fuzziest area for me so far.

As I understand it, we were planning on only saving what quests had been

accomplished and the character data.  Sort of like Diablo 2.

Chad




-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies! Can't
afford IT training? All 2003 ictp students receive scholarships. Get
hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Empyrean-devel mailing list Emp...@li...
https://lists.sourceforge.net/lists/listinfo/empyrean-devel

Re: [Empyrean-devel] Empyrean wiki stuff

[Chad A. <ae...@vr...>]

> Also, just up front - is the gameworld going to be persistent at all?
> Are we only going to save what the player has accomplished, or are we
> going to save some of the world data, or none at all...? That's the
> fuzziest area for me so far.

As I understand it, we were planning on only saving what quests had been 
accomplished and the character data.  Sort of like Diablo 2.

Chad

RE: [Empyrean-devel] Empyrean wiki stuff

[Kevin G. <jan...@ci...>]

Joe is really echoing a lot of my thoughts on the game. I love the idea
behind MMORPGs, but every single one I've ever played I have hated with
a passion. I don't want to do an MMORPG, mainly because we're not very
likely to do one right. :) I really thought of most of the MMO-style
ideas as completely optional features, and only even thought of them
because I had no idea what concurrent player count we were going for.

Also, just up front - is the gameworld going to be persistent at all?
Are we only going to save what the player has accomplished, or are we
going to save some of the world data, or none at all...? That's the
fuzziest area for me so far.

Thanks,
Kevin

-----Original Message-----
From: emp...@li...
[mailto:emp...@li...] On Behalf Of Chad
Austin
Sent: January 21, 2003 8:35 PM
To: Joe Lee
Cc: emp...@li...
Subject: Re: [Empyrean-devel] Empyrean wiki stuff


I agree with almost everything you said.  Most of all, we need to make
sure this 
project is doable.  A finished, small submission is better than an
unpolished, 
large submission, especially since we can always resubmit in future
years or 
even as the judging process goes on.  (You could in the student
showcase, at least.)

However, I worry a little about making a player skill-based game.  We
need to 
write down which skills we emphasize.  Reflex skills don't really work
that well 
over a network, unless our network code is really good.  If we are going
to 
focus on reflexes, then we should put more effort in network code.  If
we focus 
more on the ability to manage character skills (or anything that doesn't
require 
low-latency response) we can spend more time elsewhere.

Kevin, what do you think?

Chad

Joe Lee wrote:
> If we're still making this for the IGF competition, we should consider

> that a massively multiplayer game would be difficult to judge unless 
> it is already well established.  Looking over the finalists in the 
> competition and student categories, it looks like Furcadia is the only

> massively multiplayer game -- indeed, the only multiplayer game with 
> preserved state.  It also took twice as long to develop as any other 
> finalist, which I believe is not a coincidence; debugging and 
> balancing a multiplayer game takes much longer than other games, since

> you have to get and maintain a large player population.  I think we 
> stand a better chance of completing an entry if we set our sights on a

> game that minimizes persistent state between games, thus reducing the 
> complexity of the multiplayer interaction.  The difference is like 
> that between balancing Starcraft (difficult) and balancing Ultima 
> Online (nigh impossible).
> 
> I believe we should concentrate on making a game that:
> 
>   - is fun to play in small groups.
>   - emphasizes player cooperation over competition.
>   - emphasizes player skill over character statistics.
>   - keeps all players actively engaged over the course of a campaign.
>   - allows a player to start and stop gaming without worrying too much
>     about the well-being of their character or that of their 
> teammates.
> 
> I realize that these goals run contrary to the way most online RPGs 
> work.  This may actually be a good thing, since the IGF judging 
> process rewards innovation; a half-polished, innovative game will 
> score higher than a well-polished knockoff of an existing game.  I 
> believe these goals will result in a game that is as fun (or more so) 
> than existing multiplayer games, but I'm not opposed to a more 
> traditional online RPG approach.  I'm curious to hear what you guys 
> think.
> 
>                                 --=o0o=--
> Joe Lee -- jc...@cs...




-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies! Can't
afford IT training? All 2003 ictp students receive scholarships. Get
hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Empyrean-devel mailing list Emp...@li...
https://lists.sourceforge.net/lists/listinfo/empyrean-devel

Re: [Empyrean-devel] Empyrean wiki stuff

[Chad A. <ae...@vr...>]

I agree with almost everything you said.  Most of all, we need to make sure this 
project is doable.  A finished, small submission is better than an unpolished, 
large submission, especially since we can always resubmit in future years or 
even as the judging process goes on.  (You could in the student showcase, at least.)

However, I worry a little about making a player skill-based game.  We need to 
write down which skills we emphasize.  Reflex skills don't really work that well 
over a network, unless our network code is really good.  If we are going to 
focus on reflexes, then we should put more effort in network code.  If we focus 
more on the ability to manage character skills (or anything that doesn't require 
low-latency response) we can spend more time elsewhere.

Kevin, what do you think?

Chad

Joe Lee wrote:
> If we're still making this for the IGF competition, we should consider
> that a massively multiplayer game would be difficult to judge unless it is
> already well established.  Looking over the finalists in the competition
> and student categories, it looks like Furcadia is the only massively
> multiplayer game -- indeed, the only multiplayer game with preserved
> state.  It also took twice as long to develop as any other finalist,
> which I believe is not a coincidence; debugging and balancing a
> multiplayer game takes much longer than other games, since you have to
> get and maintain a large player population.  I think we stand a better
> chance of completing an entry if we set our sights on a game that
> minimizes persistent state between games, thus reducing the complexity
> of the multiplayer interaction.  The difference is like that between
> balancing Starcraft (difficult) and balancing Ultima Online (nigh
> impossible).
> 
> I believe we should concentrate on making a game that:
> 
>   - is fun to play in small groups.
>   - emphasizes player cooperation over competition.
>   - emphasizes player skill over character statistics.
>   - keeps all players actively engaged over the course of a campaign.
>   - allows a player to start and stop gaming without worrying too much
>     about the well-being of their character or that of their teammates.
> 
> I realize that these goals run contrary to the way most online RPGs
> work.  This may actually be a good thing, since the IGF judging process
> rewards innovation; a half-polished, innovative game will score higher
> than a well-polished knockoff of an existing game.  I believe these
> goals will result in a game that is as fun (or more so) than existing
> multiplayer games, but I'm not opposed to a more traditional online RPG
> approach.  I'm curious to hear what you guys think.
> 
>                                 --=o0o=--
> Joe Lee -- jc...@cs...

Re: [Empyrean-devel] Empyrean wiki stuff

[Joe L. <jc...@cs...>]

On Mon, 19 Jan 2003, Chad Austin wrote:

> About bazaar and player shops:  I wasn't picturing this game as
> "massively multiplayer".  Were I designing the game, only four players
> could play at the same time.  I think this makes the game a lot easier
> to design by keeping some linear, single-player aspects.  However, if
> you think player shops fits well in the design, I'm all for it.

If we're still making this for the IGF competition, we should consider
that a massively multiplayer game would be difficult to judge unless it is
already well established.  Looking over the finalists in the competition
and student categories, it looks like Furcadia is the only massively
multiplayer game -- indeed, the only multiplayer game with preserved
state.  It also took twice as long to develop as any other finalist,
which I believe is not a coincidence; debugging and balancing a
multiplayer game takes much longer than other games, since you have to
get and maintain a large player population.  I think we stand a better
chance of completing an entry if we set our sights on a game that
minimizes persistent state between games, thus reducing the complexity
of the multiplayer interaction.  The difference is like that between
balancing Starcraft (difficult) and balancing Ultima Online (nigh
impossible).

I believe we should concentrate on making a game that:

  - is fun to play in small groups.
  - emphasizes player cooperation over competition.
  - emphasizes player skill over character statistics.
  - keeps all players actively engaged over the course of a campaign.
  - allows a player to start and stop gaming without worrying too much
    about the well-being of their character or that of their teammates.

I realize that these goals run contrary to the way most online RPGs
work.  This may actually be a good thing, since the IGF judging process
rewards innovation; a half-polished, innovative game will score higher
than a well-polished knockoff of an existing game.  I believe these
goals will result in a game that is as fun (or more so) than existing
multiplayer games, but I'm not opposed to a more traditional online RPG
approach.  I'm curious to hear what you guys think.

                                --=o0o=--
Joe Lee -- jc...@cs...

Re: [Empyrean-devel] Compiling

[Chad A. <ae...@vr...>]

... grrr

My computer crashed before I could finish writing the e-mail last time.  I'll 
try to remember what I was writing...

I have written a document describing how to build using SCons and Cygwin.  It's 
in the empyrean/doc directory.  Keep in mind, our current non-VC7 build process 
is very rudimentary.

Good luck.


Kevin Gadd wrote:
> Damn. Any suggestions on a good place to get VC7 cheaply? My college
> only has a crippleware version and I'd rather not spend a week warezing
> it, just so I can compile the empyrean tests.
> 
> - Janus
> 
> -----Original Message-----
> From: Andy Friesen [mailto:an...@ik...] 
> Sent: January 18, 2003 9:33 AM
> To: Kevin Gadd
> Subject: Re: [Empyrean-devel] Compiling
> 
> 
> Get VC7 you whore.
> 
> haha you suck.
> 
> Kevin Gadd wrote:
> 
> 
>>I got all the empyrean examples and such off CVS, but stupid VC6
>>refuses to build them no matter what I do. I get piles and piles of 
>>asinine build/link errors and such. Any suggestions (other than 'get 
>>vc7 you whore' or 'haha you suck')?
>> 
>>Thanks
>>Janus
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit encryption. 
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Empyrean-devel mailing list
> Emp...@li...
> https://lists.sourceforge.net/lists/listinfo/empyrean-devel

Re: [Empyrean-devel] Empyrean wiki stuff

[Chad A. <ae...@vr...>]

Sorry for the slow response.  I've been away from a working network for a while.

Why is a logoff delay a useful feature in persistent world games?  I'm not just 
asking...  the answer to questions like that should be in the document as well, 
so we all understand why certain decisions are made.  :)

About bazaar and player shops:  I wasn't picturing this game as "massively 
multiplayer".  Were I designing the game, only four players could play at the 
same time.  I think this makes the game a lot easier to design by keeping some 
linear, single-player aspects.  However, if you think player shops fits well in 
the design, I'm all for it.

Over Christmas I was trying to play Empyrean in my head to get a feel for how 
the game would flow and the important aspects of the gameplay.  You may want to 
try this if you haven't already.

And there stops my train of thought.

Chad

Kevin Gadd wrote:
> Yeah, in general my writing doesn't flow so I end up filling in minor 
> details before major ones. I'll try to focus on the major stuff first 
> though.
> 
> The logoff delay I thought was at least a somewhat useful detail, as not 
> allowing instant logoffs is usually a good idea in persistent world games.
> 
> The 'trash.skills' thing was the wiki being retarded and changing every 
> instance of 'Skills' in the wiki. I have no idea why it did it.
> 
> Character mechanics are a very fuzzy area for me right now, which is why 
> I avoided it... I don't have enough details to write them up. If you 
> guys have any existing docs or anything on character mechanics, i'd 
> appreciate a link or two. Otherwise I can just try and make stuff up and 
> see if it works.
> 
> Also, chad, with ideas like the bazaar and player shops; is that moving 
> too far into the MMO genre or did you like it?
> 
> On Fri, 17 Jan 2003 10:36AM -0800, Chad Austin wrote:
> 
>> I took a look at your changes, and I noticed a lot of things were 
>> placeholders.
>>
>> The design document looks pretty good.  About the networking 
>> aspect...  I was planning on storing all characters on the server, 
>> just like Diablo II.  This doesn't necessarily have to be the case, 
>> however.  In my opinion, that kinda stuff is a little too 
>> implementationy to be in the design document for now.  For example, 
>> "The player selects 'Log Off' from an ingame menu, and then has to 
>> wait a certain number of seconds (5 or 15, probably) before they can 
>> log off."  Why is waiting for 5 to 15 seconds part of the design?
>>
>> I also think you should spend some time and focus on character 
>> mechanics.  We still don't have a satisfactory mechanism for allowing 
>> the player to advance in ability and power.
>>
>> What's Trash.Skills?
>>
>> You probably want to sign up for the WebNotify topic in the 
>> Development web so you can get notified when anyone changes the wiki.  
>> (I added a small comment to the DesignDocument topic.)
>>
>> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/WebNotify
>>
>> I'm not trying to be overly negative here, I'm just nitty by nature.  
>> ;)  I'm very glad you're working on fleshing out a design for us, and 
>> so far it looks great to me.
>>
>> Chad
>>
>>
>> Kevin Gadd wrote:
>>
>>> I started work on the Design Document:
>>> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/DesignDoc
>>> ument
>>> And also put up a draft of my ideas for the Catacombs Quest (a quest for
>>> an area I came up with, under the city of Elaril):
>>> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/TheCataco
>>> mbsQuest
>>> I also did some maintenance and organization on the wiki and filled in a
>>> few small gaps. (I organized the current ideas/plans for towns, etc. And
>>> added entries for quests and such as well.)
>>> I'll be waiting for your suggestions and comments.
>>> - Janus
>>>
>>> -------------------------------------------------------
>>> This SF.NET email is sponsored by: Thawte.com
>>> Understand how to protect your customers personal information by 
>>> implementing
>>> SSL on your Apache Web Server. Click here to get our FREE Thawte 
>>> Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
>>> _______________________________________________
>>> Empyrean-devel mailing list
>>> Emp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/empyrean-devel
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
>> allow you to extend the highest allowed 128 bit encryption to all your 
>> clients even if they use browsers that are limited to 40 bit 
>> encryption. Get a guide 
>> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
>> _______________________________________________
>> Empyrean-devel mailing list
>> Emp...@li...
>> https://lists.sourceforge.net/lists/listinfo/empyrean-devel
> 
> 
> Kevin Gadd
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit encryption. 
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Empyrean-devel mailing list
> Emp...@li...
> https://lists.sourceforge.net/lists/listinfo/empyrean-devel

RE: [Empyrean-devel] Compiling

[Joe L. <jc...@cs...>]

On Sun, 19 Jan 2003, Kevin Gadd wrote:

> Damn. Any suggestions on a good place to get VC7 cheaply? My college
> only has a crippleware version and I'd rather not spend a week warezing
> it, just so I can compile the empyrean tests.

You can get Visual Studio .NET for $99 from journeyed.com (with proof of
academic status).  

                                --=o0o=--
Joe Lee -- jc...@cs...

RE: [Empyrean-devel] Compiling

[Kevin G. <jan...@ci...>]

Damn. Any suggestions on a good place to get VC7 cheaply? My college
only has a crippleware version and I'd rather not spend a week warezing
it, just so I can compile the empyrean tests.

- Janus

-----Original Message-----
From: Andy Friesen [mailto:an...@ik...] 
Sent: January 18, 2003 9:33 AM
To: Kevin Gadd
Subject: Re: [Empyrean-devel] Compiling


Get VC7 you whore.

haha you suck.

Kevin Gadd wrote:

> I got all the empyrean examples and such off CVS, but stupid VC6
> refuses to build them no matter what I do. I get piles and piles of 
> asinine build/link errors and such. Any suggestions (other than 'get 
> vc7 you whore' or 'haha you suck')?
>  
> Thanks
> Janus

Re: [Empyrean-devel] Compiling

[Chad A. <ae...@vr...>]

You cannot build with VC6, and we don't plan to support it (we use such things 
as standard C++ and libraries that depend on VC7).  You need VC7 or Cygwin and 
SCons to build it.

Kevin Gadd wrote:
> I got all the empyrean examples and such off CVS, but stupid VC6 refuses 
> to build them no matter what I do. I get piles and piles of asinine 
> build/link errors and such. Any suggestions (other than 'get vc7 you 
> whore' or 'haha you suck')?
>  
> Thanks
> Janus

Re: [Empyrean-devel] Empyrean wiki stuff

[Kevin G. <jan...@ci...>]

Yeah, in general my writing doesn't flow so I end up filling in minor 
details before major ones. I'll try to focus on the major stuff first 
though.

The logoff delay I thought was at least a somewhat useful detail, as not 
allowing instant logoffs is usually a good idea in persistent world 
games.

The 'trash.skills' thing was the wiki being retarded and changing every 
instance of 'Skills' in the wiki. I have no idea why it did it.

Character mechanics are a very fuzzy area for me right now, which is why 
I avoided it... I don't have enough details to write them up. If you 
guys have any existing docs or anything on character mechanics, i'd 
appreciate a link or two. Otherwise I can just try and make stuff up and 
see if it works.

Also, chad, with ideas like the bazaar and player shops; is that moving 
too far into the MMO genre or did you like it?

On Fri, 17 Jan 2003 10:36AM -0800, Chad Austin wrote:
> I took a look at your changes, and I noticed a lot of things were 
> placeholders.
>
> The design document looks pretty good.  About the networking aspect...  
> I was planning on storing all characters on the server, just like 
> Diablo II.  This doesn't necessarily have to be the case, however.  In 
> my opinion, that kinda stuff is a little too implementationy to be in 
> the design document for now.  For example, "The player selects 'Log 
> Off' from an ingame menu, and then has to wait a certain number of 
> seconds (5 or 15, probably) before they can log off."  Why is waiting 
> for 5 to 15 seconds part of the design?
>
> I also think you should spend some time and focus on character 
> mechanics.  We still don't have a satisfactory mechanism for allowing 
> the player to advance in ability and power.
>
> What's Trash.Skills?
>
> You probably want to sign up for the WebNotify topic in the Development 
> web so you can get notified when anyone changes the wiki.  (I added a 
> small comment to the DesignDocument topic.)
>
> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/WebNotify
>
> I'm not trying to be overly negative here, I'm just nitty by nature.  
> ;)  I'm very glad you're working on fleshing out a design for us, and 
> so far it looks great to me.
>
> Chad
>
>
> Kevin Gadd wrote:
>> I started work on the Design Document:
>> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/DesignDoc
>> ument
>> And also put up a draft of my ideas for the Catacombs Quest (a quest 
>> for
>> an area I came up with, under the city of Elaril):
>> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/TheCataco
>> mbsQuest
>> I also did some maintenance and organization on the wiki and filled in 
>> a
>> few small gaps. (I organized the current ideas/plans for towns, etc. 
>> And
>> added entries for quests and such as well.)
>> I'll be waiting for your suggestions and comments.
>> - Janus
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: Thawte.com
>> Understand how to protect your customers personal information by 
>> implementing
>> SSL on your Apache Web Server. Click here to get our FREE Thawte 
>> Apache Guide: 
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
>> _______________________________________________
>> Empyrean-devel mailing list
>> Emp...@li...
>> https://lists.sourceforge.net/lists/listinfo/empyrean-devel
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts 
> will
> allow you to extend the highest allowed 128 bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit 
> encryption. Get a guide 
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Empyrean-devel mailing list
> Emp...@li...
> https://lists.sourceforge.net/lists/listinfo/empyrean-devel

Kevin Gadd

Re: [Empyrean-devel] Empyrean wiki stuff

[Chad A. <ae...@vr...>]

I took a look at your changes, and I noticed a lot of things were placeholders.

The design document looks pretty good.  About the networking aspect...  I was 
planning on storing all characters on the server, just like Diablo II.  This 
doesn't necessarily have to be the case, however.  In my opinion, that kinda 
stuff is a little too implementationy to be in the design document for now.  For 
example, "The player selects 'Log Off' from an ingame menu, and then has to wait 
a certain number of seconds (5 or 15, probably) before they can log off."  Why 
is waiting for 5 to 15 seconds part of the design?

I also think you should spend some time and focus on character mechanics.  We 
still don't have a satisfactory mechanism for allowing the player to advance in 
ability and power.

What's Trash.Skills?

You probably want to sign up for the WebNotify topic in the Development web so 
you can get notified when anyone changes the wiki.  (I added a small comment to 
the DesignDocument topic.)

http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/WebNotify

I'm not trying to be overly negative here, I'm just nitty by nature.  ;)  I'm 
very glad you're working on fleshing out a design for us, and so far it looks 
great to me.

Chad


Kevin Gadd wrote:
> I started work on the Design Document:
> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/DesignDoc
> ument
> And also put up a draft of my ideas for the Catacombs Quest (a quest for
> an area I came up with, under the city of Elaril):
> http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/TheCataco
> mbsQuest
> I also did some maintenance and organization on the wiki and filled in a
> few small gaps. (I organized the current ideas/plans for towns, etc. And
> added entries for quests and such as well.)
> 
> I'll be waiting for your suggestions and comments.
> 
> - Janus
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________
> Empyrean-devel mailing list
> Emp...@li...
> https://lists.sourceforge.net/lists/listinfo/empyrean-devel

[Empyrean-devel] Empyrean wiki stuff

[Kevin G. <jan...@ci...>]

I started work on the Design Document:
http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/DesignDoc
ument
And also put up a draft of my ideas for the Catacombs Quest (a quest for
an area I came up with, under the city of Elaril):
http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/TheCataco
mbsQuest
I also did some maintenance and organization on the wiki and filled in a
few small gaps. (I organized the current ideas/plans for towns, etc. And
added entries for quests and such as well.)

I'll be waiting for your suggestions and comments.

- Janus

[Empyrean-devel] design conversation with janus

[Chad A. <ae...@vr...>]

KaimuMobile: Hey
KaimuMobile: What's up
aegisz: hey there
aegisz: Mobile?
KaimuMobile: Yeah
KaimuMobile: Hiptop :)
aegisz: ah
KaimuMobile: Viewing the wiki right now
KaimuMobile: How is my progress on the design doc so far
KaimuMobile: Is that the direction I need to go with it?
KaimuMobile: I was trying to just organize all the details into one place
aegisz: It looked like you are focusing on technical design, which isn't really 
what we need.
KaimuMobile: It's not? Oh.
aegisz: We need a core gameplay design.  We need to know how the program works, 
independent of the computing power it's run with.
KaimuMobile: Ahhhh
KaimuMobile: I see
KaimuMobile: I'll make a wiki subtopic for gameplay and work on that aspect then
aegisz: wait
aegisz: 
http://empyrean.sourceforge.net/cgi-bin/twiki/view/Development/DesignDocument 
<-- this should be 100% gameplay and user interface specification for now
aegisz: For example:  Graphics engine uses SDL for windowing and input, OpenGL 
for rendering. Rendering is done in layers, each layer contains objects sorted 
in a BSP tree by location for fast clipping.
aegisz: BSP tree?  Why is that part of the design?
KaimuMobile: Okay. I'll take out the rest
KaimuMobile: It was listed elsewhere in the wiki
aegisz: That's an implementation detail, (and even less important, an 
optimization detail).
KaimuMobile: I figured it was significant, but you're right
aegisz: The important things to cover are how you play, input issues, 
advancement issues, why the game is fun, etc.
aegisz: the audience
aegisz: feasibility
KaimuMobile: Ahh. I see.
aegisz: Hope that gives you some direction.  :)
KaimuMobile: Yes, that's very helpful hehe
KaimuMobile: I've been trying to catch you for a while
aegisz: Another thing:  "AI is done using a combination of Python and simple 
neural network-style behaviors."  Whether or not to use neural nets isn't the 
first decision to make.  The first decision is "What AI is in the game?  What 
does the AI need to do?"  You can tackle the problem of how after what.
aegisz: Ah, I've been really busy.
aegisz: E-mail is good.
KaimuMobile: Ok. What address?
aegisz: ae...@ae... works
KaimuMobile: The one in your wiki profile?
aegisz: all of my addresses go to the same place
KaimuMobile: K
aegisz: SWEET
aegisz: Only $35???  I'm ordering now!
aegisz: 
http://www.amazon.com/exec/obidos/tg/detail/-/193211131X/qid=1042773744/sr=8-2/ref=sr_8_2/104-8391840-9670340?v=glance&s=books&n=507846#product-details
KaimuMobile: ?
KaimuMobile: What book is that, hyperlinks don't work in this aim client
aegisz: oh...  out of print...  :|
aegisz: 
http://www.amazon.com/exec/obidos/tg/detail/-/1576104257/qid=1042773744/sr=8-1/ref=sr_8_1/104-8391840-9670340?v=glance&s=books&n=507846
aegisz: Game Architecture and Design
KaimuMobile: Ahh.
aegisz: http://www.xmlhive.com/mercator/book.htm
KaimuMobile: *reads sample chapter*
aegisz: *orders it used*
KaimuMobile: I'll have to get this book
KaimuMobile: It looks really good
KaimuMobile: Wow this sample chapter is awesome
aegisz: What chapter is it?
KaimuMobile: It's already giving me ideas for how to structure the design doc better
aegisz: :D
KaimuMobile: 8
aegisz: neato  ^__^
KaimuMobile: Also, I was wondering in general if you think neural networks will 
handle the kind of ai you want for the game
KaimuMobile: It seems like a good fit to me
aegisz: What AI do I want for the game?  :)
aegisz: We haven't even gotten to _that_ question yet!
aegisz: We don't even have a list of monsters.
KaimuMobile: Well from what i've read in the specs the town will be attacked and 
defended
aegisz: hm
aegisz: So what AI is that?
KaimuMobile: So that implies to me that at least monsters will have goal/rule 
based ai
KaimuMobile: Neural networks handle that well in my experience
aegisz: Why does that imply that?
KaimuMobile: Well if the monsters are not operating on goals, they won't present 
a coherent threat
aegisz: Why not?
KaimuMobile: Well, from what I read in the docs the goal is to have players 
cooperate to fight off waves of attackers
aegisz: Hm.
aegisz: I don't think that was ever part of my vision.  Where is that in the docs?
KaimuMobile: Couple places
aegisz: I would rather it be a quest / mission oriented cooperative game.
KaimuMobile: Let me find it
KaimuMobile: Ahhh cool
KaimuMobile: I like those better too
aegisz: Anyway, the point of the design doc is to have _one_ person do a 
cohesive design.
aegisz: Multiple people can't design a game together, IMO.
aegisz: It just won't mesh.
KaimuMobile: That's what I'm seeing so far
KaimuMobile: But I haven't wanted to stray from current designs cause like I 
said, I hate stepping on toes
aegisz: But no one person on our team is willing or has time to do that.
aegisz: ah
KaimuMobile: I have time for that
aegisz: Feel free to step on everyone's toes, IMO.
aegisz: Cool.  :)
KaimuMobile: Hehe
KaimuMobile: What I need is to get your vision in whatever form
KaimuMobile: So I can refine/extend it into a doc
aegisz: Okay.
KaimuMobile: And we can go from there
aegisz: The concept treatment covered most of what I thought, at least in a 
general stroke.
KaimuMobile: I can write really fast but only if I have inspiration
KaimuMobile: Ok, I can read over that again
aegisz: I never managed to flesh out the details of the skill system.
aegisz: The way I pictured it was like a map...  skills weren't split into 
classes or anything.
aegisz: Classes are just given an initial set of skills.
aegisz: The gameplay aspect here is that restricting skills to classes makes for 
less interesting choices.
KaimuMobile: If you have a time we should both just meet privately in irc so I 
have a log to work from
aegisz: okay
aegisz: Can't you save this?
aegisz: or let's just use e-mail
KaimuMobile: Cellphone
aegisz: o_O
aegisz: oh
aegisz: Anyway, let me get this thought out.  Restricting skills based on class 
sort of drives a character, but we wanted a more open ended system with a 
highly-balanced set of skills.
aegisz: So the character feels more in control.
aegisz: I can e-mail this to you if you want.
KaimuMobile: Sure
aegisz: What's your address?
aegisz: Actually.
aegisz: I'm going to sign you up for the empyrean-devel mailing list and send 
the message to that.  That way it's archived.
aegisz: It's too bad andy doesn't use mailing lists.
KaimuMobile: Jan...@ci...
aegisz: great
KaimuMobile: I' going to be afk for a bit, going to a play
aegisz: Okay.
Auto response from KaimuMobile: Hi, I'm unavailable.

aegisz: Cool.

[Empyrean-devel] Fw: , [ alexandria-Support Requests-646270 ] Project web services issue

[Theodore R. <ri...@su...>]

Begin forwarded message:

Date: Mon, 02 Dec 2002 12:21:00 -0800
From: no...@so...
To: no...@so...
Subject: [ alexandria-Support Requests-646270 ] Project web services
issue


Support Requests item #646270, was opened at 2002-11-30 20:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=646270&group_id=1

Category: Project Web Services
Group: Second Level Support
>Status: Closed
Priority: 1
Submitted By: Theo Reed (surreality)
>Assigned to: Jacob Moorman (moorman)
Summary: Project web services issue

Initial Comment:
There are files missing in

/home/groups/e/em/empyrean/twiki and

/home/groups/e/em/empyrean/cgi-bin/lib They were both

chmod 777 and I notice that the web stuff for some

other projects (sphere, crux) is messed up, so I assume

someone was having some fun with the shell services.

Are there recent backups available for these directories?

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

Comment By: Jacob Moorman (moorman)
Date: 2002-12-02 15:21

Message:
Logged In: YES 
user_id=152443

Greetings,



This response is believed to cover the inquiry discussed on this

support request.  The SourceForge.net team elected to delay the

response to this support request until a final course of action

for handling this issue had been determined. This message is a

canned response which has been sent to all related issue reports.

 Please submit a new support request if you require further

assistance after reviewing this response.



On 2002-11-30, world-writable and web server-owned files (i.e.

those that were writable by the nfsnobody user) were removed for

all projects.  The SourceForge.net project web services are

provided in a shared environment; all CGI scripts and PHP scripts

run as the nfsnobody user.  Thus, in order for files to be

writable by the web server, the nfsnobody user (or other, in the

case where user and group ownership is not nfsnobody) must be

able to write to that file.  This is a known limitation of the

project web services offered by SourceForge.net.



Projects that have elected to make use of project web services in

order to host an application that writes to the filesystem MUST

establish a backup policy for their project.  SourceForge.net

maintains project backups solely as to permit recovery from

catastrophic hardware failure, natural disaster, etc.  It is the

responsibility of ALL PROJECTS to maintain backups of the data

they place within their project group directory space, including

all CGI scripts, PHP scripts, and data.  World writable data is

particularly at risk.



Complete details regarding the SourceForge.net Backup and

Recovery policy may be found in the SourceForge.net Site

Documentation collection, as seen at:

https://sourceforge.net/docman/display_doc.php?docid=6840&group_id=1



We realize that this message is worded strongly.  Please take

appropriate action to protect the data you care about, as

described in our policy, before repopulating your group directory

space.





Specifically, there are four reasons why SourceForge.net cannot

maintain suitable backups of project web application-generated data:



1) Without having knowledge of your application, we do not know

exactly which portion of your content is regularly updated data

(or data you care about);



2) Applications use different mechanisms for data locking, and

locking is typically required to ensure a backup is complete and

atomic;



3) Different projects use their web space for different purposes,

not all of which are critical in nature, and some of which

require a high backup frequency (i.e. hourly, twice daily, etc.)

as to ensure a reasonable recovery period is maintained;



4) Data in your project web space is supplied by your users and

members of your project team and is not within our direct control

-- keeping your own offsite backups gives you the ability to

restore this data on-demand, as-needed.



SourceForge.net provides a shared web hosting environment.  While

we continue to consider possible solutions which would permit us

to make use of setuid/setgid during the operation of CGI scripts

and scripts run from mod_php, this is a particularly complex

problem due to the large number of VHOSTs we serve from our pool

of project web servers.  Additional information will be made

available by 2002-12-09 within the SourceForge.net Site

Documentation collection regarding these issues; the document to

be added will be placed with other policy-related documentation

(section J).





Moving forward, our standard policy is that on-demand restores

are not provided.



In this case, however, the SourceForge.net team is able to

provide an improved response in lieu of standard policy and

provide data archives produced 14 days ago (as part of our

scheduled project services outage).  This is a one-time

occurrance -- in the future, we will not be able to provide

on-demand restoration of project web content.  The archived

copies of all files in your project group directory space (as of

14 days ago) may be found in the /home/oldgroups filesystem

(which is mounted read-only) on the project shell server.  If

your project name is 'sitedocs', you would find your archived

data at /home/oldgroups/s/si/sitedocs/.



To proceed:



1. Please ensure you have established a backup policy for your

project.



2. Copy data from the /home/oldgroups directory structure as-needed.



3. Consider moving to MySQL for data storage (and establish

regular dumps of your MySQL database as part of your backup

strategy).



The archived data will be provided for a duration of not more

than two weeks and will be unmounted on 2002-11-16.  Please

complete the needed data transfer to your group directory space

by 2002-11-15.



Should you have further questions or concerns regarding

SourceForge.net project web services, our backup policies, or the

support response to this inquiry, please submit a new Support

Request at this time.



Thank you,



Jacob Moorman

Quality of Service Manager, SourceForge.net



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=646270&group_id=1



-- 
Theodore Reed (rizen/bancus)       -==-       http://www.surreality.us/
~OpenPGP Signed/Encrypted Mail Preferred; Finger me for my public key!~

"We have committed a greater crime, and for this crime there is no name.
What punishment awaits us if it be discovered we know not, for no such
crime has come in the memory of men and there are no laws to provide for
it." -- Equality 7-2521, Ayn Rand's Anthem

[Empyrean-devel] [Fwd: Re: Want to help out]

[Chad A. <ae...@vr...>]

I'm forwarding this to broadcast and archive it on the mailing list.

-------- Original Message --------
Subject: Re: Want to help out
Date: Wed, 27 Nov 2002 20:22:40 -0600
From: A M <ada...@ho...>
To: ae...@vr...

I have access to Max, Maya, Lightwave, and trueSpace, though most of my
experience (and easiest access) lies in Max and Maya. I can export my 
meshes
as geometry with UVs (and skeletal systems if they can be supported). It
really depends upon what your graphics programmer plans to use as his
format, as I can look for a freeware convertor.






>From: Chad Austin <ae...@vr...>
>To: A M <ada...@ho...>
>Subject: Re: Want to help out
>Date: Wed, 27 Nov 2002 19:32:16 -0600
>
>Oh yeah, I had another question or two.
>
>What tools do you use for modeling and animation?  Will they be easy to 
>integrate into an LGPL codebase?
>
>A M wrote:
>>Mr. Chad Austin,
>>
>>Greetings! Though I am certain my younger brother may have offhandedly 
>>mentioned to you some of the inquiries herein, I figured it would be best 
>>for me to speak with you directly.
>>
>>First, I would like to introduce myself. I am Adam Mechtley, a student of 
>>Game Art and Design at the Art Institute of Phoenix, and the older brother 
>>of Brandon (malis I believe is still his handle). Brandon had mentioned to 
>>me some of the projects on which you were working, and it piqued my 
>>interest so to speak.
>>
>>The Empyrean project on which you and some of the Sphere individuals are 
>>working sounds, with respect to gameplay and technology, very similar to 
>>the type of games in which I am interested in developing (those that make 
>>use of modern graphics technology and more traditional side-scrolling 
>>gameplay elements). As such I would be very interested in becoming 
>>involved. I would love to see it become an IGF submission sometime in the 
>>future, and would also love to make use of the technology in my future 
>>portfolio exhibition, but I digress.
>>
>>Additionally he mentioned to me that you were, with the ISU Game 
>>Development Club as it may be, working on another title, possibly for this 
>>year's IGF. Though I do not know, given my scheduling, just how much I 
>>would be able to contribute between now and the GDC, I would be more than 
>>glad to lend any assistance I can confer therewith.
>>
>>My specialization lies in 3D art (modeling, texturing, animating, and so 
>>forth--especially characters), though my curriculum at school deals 
>>greatly with fundamentals of game theory including gameplay, design, level 
>>design/environmental art, play balance, and so forth in addition to a 
>>great deal of traditional art skills. As such I would be willing to 
>>contribute in any of these ways possible, should you have a need. 
>>Additionally, I do have some past programming experience, primarily with 
>>C++, so I have a reasonable understanding of technical limitations and 
>>requirements with respect to art and design.
>>
>>The most recent [completed] project on which I have worked was The Past, a 
>>simple action space combat shooting game displayed at last year's IGF 
>>Student Showcase (available at http://www.bluedojo.com). Though with 
>>respect to design the game itself was perhaps not terribly intuitive, I 
>>learned a good deal about digital art optimization and so forth and 
>>enhanced my communicative skills dealing with technical parties. My main 
>>contribution included some [textured] spaceship models in later levels, as 
>>well as some prerendered item graphics, though unfortunately most of my 
>>content appears only in later stages due to my joining the project late in 
>>its development.
>>
>>If you have any questions or would like to see me demonstrate some work 
>>that may fit your project, please feel free to contact me at your 
>>convenience. I myself would love to ask you and some of the other members 
>>of your team about some of the technical features of the project so I 
>>could begin working on assets as soon as possible, should you desire my 
>>assistance.
>>
>>Thank you for your time,
>>
>>Adam D. Mechtley
>>
>>_________________________________________________________________
>>Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
>>http://join.msn.com/?page=features/featuredemail


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail

[Empyrean-devel] Re: Empyrean-devel -- confirmation of subscription -- request 271668

[Theodore R. <ri...@su...>]

On Thu, 21 Nov 2002 23:19:50 -0800
emp...@li... wrote:

> Empyrean-devel -- confirmation of subscription -- request 271668
> 
> We have received a request from 4.47.240.153 for subscription of your
> email address, <ri...@su...>, to the
> emp...@li... mailing list.  To confirm the
> request, please send a message to
> emp...@li..., and either:
> 
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
> 
> - or include the following line - and only the following line - in the
> message body: 
> 
> confirm 271668
> 
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
> 
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> emp...@li....
> 


-- 
Theodore Reed (rizen/bancus)       -==-       http://www.surreality.us/
~OpenPGP Signed/Encrypted Mail Preferred; Finger me for my public key!~

"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." -- Arthur Schopenhauer