Menu
▾
▴
cplproject-developers — Developers mailing list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(26) |
Nov
|
Dec
|
|---|
|
From: Andrew B. <an...@br...> - 2002-10-17 16:30:35
|
On 10/15/02 at 10:14 PM, mox...@de... (Petras Kudaras) wrote: > Hello, [big snip] > Please comment on anything in this email. I am waiting for your input, > ideas and opinions. > Just a quick note...Sorry I have not responded yet. I'm just a bit busy with work this week. I will get back to you on this and your previous email, but probably not until next week. Don't finish without me! :-) Andrew |
|
From: Petras K. <mox...@de...> - 2002-10-15 20:15:04
|
Hello,
We have already had some discussion on the game implementation itself, so
I thought that it would be beneficial for us to work out the source tree
structure and to decide on coding style.
First of all, coding style:
I propose to follow perlstyle manpage as our guideline to coding style.
This means 4 column indent, space before opening curly brackets and
around most operators and so on (consult perlstyle manpage for more).
However, this project is for learning, so I would like to propose the
following additions:
* Subroutine declarations should be well documented, preferably in POD
format. Subroutine documentation should state purpose of the
subroutine and how it fits in with the big picture. Sort of like an
answer to the question "WHY?". This is a learning
project, too much documentation has not hurt anyone.
* The code should be also commented within the subroutines. This is
like an answer to the question "HOW?". This is a learning project,
too much documentation has not anyone.
When you write code for this project, please keep in mind that people
with only some knowledge in the subject will be reading it and trying
to understand. This project is here so that we would learn. Therefore
comment everything: if you are taking a shortcut, add a note about it;
if you are using a complex regexp, comment it; if you are using
complex things with map {}, explain them (things like saying "doing a
Schwartzian transform here" is probably not enough, unless this has
been already explained). Please write readable code, choose readable
variable and function names. The last thing we would want is some Ofbu
code ;)
Now, onto the source code tree. As we have few separate things, we
should try to separate them in the source code. So here is how I see
things:
/doc documentation
/src source
|- server server source code
|- client client source code
|- CGI CGI client source
|- console console client source
|- ... any other client source
/themes themes
|- perlmonks default perlmonks theme
|- maps perlmonks theme maps
|- characters perlmonks theme characters
|- ... any other theme resources
|- ... any other game theme
Please comment on anything in this email. I am waiting for your input,
ideas and opinions.
--
Sėkmės,
Petras Kudaras mailto:mox...@de...
|
|
From: Thomas S. <Tho...@ms...> - 2002-10-11 22:18:39
|
I just happened to remember seeing a couple of modules on CPAN the other = day that might actually be of use to us for this. The modules in question= are Games::Maze and Games::Object. IMO, we might want to take a look at = these. Tom ----- Original Message ----- From: Andrew Brosnan Sent: Friday, October 11, 2002 4:07 PM To: Petras Kudaras Cc: cpl...@li...; cplproject-develop= er...@li... Subject: Re: [cplp-dev] Re: What's next On 10/11/02 at 10:01 AM, mox...@de... (Petras Kudaras) wrote: > Here I am going to present my view of the first stages of the game. > Feel free to express your opinion and comment on this. > =20 > The goal is to make a charactermove in the world and interact with > walls. So there are a couple of objects that we must pay attention to: > =20 > a) a character, > b) a world map, which consists of: > 1) walls; > 2) empty space. The world map would be an object? (and things in it?) I guess that makes good sense. I'm going to have to get my OO programming book out. (I just got Damian Conways book...guess I'd better get to it) > =20 > We also have a client/server structure. =20 Are we talking about writing our own http client or using a browser? > In my opinion, the server has the following duties: > =20 > a) generating the map (or reading it from somewhere), what would the map be based on? coordinates? > b) generating the character (in theory it could be generated by the > client, but I think it is easier to leave it for the server), yes, also generating it on the server would give us more control to update & change things without *necessarily* requiring users to upgrade or even know about it, wouldn't it? > c) transmitting the map information and character information to the > client via some protocol, > d) waiting for the client to give instructions (which at this stage > would only be "move north/south/east/west") > e) process the instructions from the client and respond witha status > message (either "successful" or "not successful -- bumped into a > wall") hmmm...just wondering out loud...how will we keep session stuff straight. I mean, if the server generates a map and characters, sends them to the client, and then the client wants to do *something*, (which may eventually alter the character or map), obviously client and server need to be in sync. Any thoughts on managing sessions? Is this what you were thinking? > =20 > The client has these things to do: > a) handshake with a server, get a map and character data, > b) somehow display this data on screen (ASCII art like nethack?), I am clueless here..sorry. I'm happy to research it though. > c) take instructions from the player and send them to the server, > d) update map information internally and redraw the map (if the move > was successful, if not -- display a message why it was not successful) > =20 > The communication between client/server could be over XML-RPC. > =20 > In terms of Perl, map and character could be instances of object > classes "map" and "character" respectively. Keeping objects separate > would probably help us when we will want to expand or add another game > theme. Yes, although I'm sure that using inheritance (base->derived classes) will make sense for many things, especially for things in the 'world'. (I'd better get to that book:-) > =20 > This is my view of the game and I would like you to present yours. I'm going to work on this some more. Good discussion. Andrew ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ cplproject-developers mailing list cpl...@li... https://lists.sourceforge.net/lists/listinfo/cplproject-developersGet mor= e from the Web. FREE MSN Explorer download : http://explorer.msn.com |
|
From: Petras K. <mox...@de...> - 2002-10-11 20:50:58
|
Friday, October 11, 2002, 10:03:46 PM, Andrew Brosnan rašė: > The world map would be an object? (and things in it?) I guess that makes > good sense. I'm going to have to get my OO programming book out. (I just > got Damian Conways book...guess I'd better get to it) Well, as far as I can remember, James [Mastros] suggested the idea of a object oriented approach and I think it makes sense. If anyone has arguments against, we would all like to hear them before making the final decision ;) >> We also have a client/server structure. > Are we talking about writing our own http client or using a browser? I think we are talking about a browser interface for the first version (XML-RPC would enable us to add more interfaces later on). So here is how I envision the client/server thing: A server is an application that is sitting on some port and accepting XML-RPC queries (which is just some XML over HTTP) A client is a CGI application that connects to the server, does what it needs to do, formats a HTML result and sends it to browser. So the scheme would look like: /------\ XML-RPC /----------\ HTTP /-------\ |Server| <------- |CGI Client| <---- |Browser| \------/ -------> \----------/ ----> \-------/ > what would the map be based on? coordinates? I guess so. It might be inefficient to store the map in a two dimensional array in some cases, but would that be a problem for us? >> b) generating the character (in theory it could be generated by the >> client, but I think it is easier to leave it for the server), > yes, also generating it on the server would give us more control to > update & change things without *necessarily* requiring users to upgrade > or even know about it, wouldn't it? Yes, I agree with that. > hmmm...just wondering out loud...how will we keep session stuff > straight. I mean, if the server generates a map and characters, sends > them to the client, and then the client wants to do *something*, (which > may eventually alter the character or map), obviously client and server > need to be in sync. Any thoughts on managing sessions? Is this what you > were thinking? There is no concern about keeping sessions during CGI applications, because we can use HTTP cookies (if that is what you meant). So once the initial handshake is made, a special token (so called unique session ID) is generated and is shared between client and server. So server can know which client is playing who and what map it is using and so on. Obviously this session ID has to be passed to every XML-RPC request, so that the server can track users. >> b) somehow display this data on screen (ASCII art like nethack?), > I am clueless here..sorry. I'm happy to research it though. Displaying a map in the browser is not a difficult thing to do. The map will presumably have tiles, so displaying them in ASCII or in a set of images would be simple IMHO. >> In terms of Perl, map and character could be instances of object >> classes "map" and "character" respectively. Keeping objects separate >> would probably help us when we will want to expand or add another game >> theme. > Yes, although I'm sure that using inheritance (base->derived classes) > will make sense for many things, especially for things in the 'world'. > (I'd better get to that book:-) I am looking forward to this, because I also wanted to learn more OO Perl ;) -- Sėkmės, Petras Kudaras mailto:mox...@de... |
|
From: Andrew B. <an...@br...> - 2002-10-11 20:04:35
|
On 10/11/02 at 10:01 AM, mox...@de... (Petras Kudaras) wrote: > Here I am going to present my view of the first stages of the game. > Feel free to express your opinion and comment on this. > > The goal is to make a charactermove in the world and interact with > walls. So there are a couple of objects that we must pay attention to: > > a) a character, > b) a world map, which consists of: > 1) walls; > 2) empty space. The world map would be an object? (and things in it?) I guess that makes good sense. I'm going to have to get my OO programming book out. (I just got Damian Conways book...guess I'd better get to it) > > We also have a client/server structure. Are we talking about writing our own http client or using a browser? > In my opinion, the server has the following duties: > > a) generating the map (or reading it from somewhere), what would the map be based on? coordinates? > b) generating the character (in theory it could be generated by the > client, but I think it is easier to leave it for the server), yes, also generating it on the server would give us more control to update & change things without *necessarily* requiring users to upgrade or even know about it, wouldn't it? > c) transmitting the map information and character information to the > client via some protocol, > d) waiting for the client to give instructions (which at this stage > would only be "move north/south/east/west") > e) process the instructions from the client and respond witha status > message (either "successful" or "not successful -- bumped into a > wall") hmmm...just wondering out loud...how will we keep session stuff straight. I mean, if the server generates a map and characters, sends them to the client, and then the client wants to do *something*, (which may eventually alter the character or map), obviously client and server need to be in sync. Any thoughts on managing sessions? Is this what you were thinking? > > The client has these things to do: > a) handshake with a server, get a map and character data, > b) somehow display this data on screen (ASCII art like nethack?), I am clueless here..sorry. I'm happy to research it though. > c) take instructions from the player and send them to the server, > d) update map information internally and redraw the map (if the move > was successful, if not -- display a message why it was not successful) > > The communication between client/server could be over XML-RPC. > > In terms of Perl, map and character could be instances of object > classes "map" and "character" respectively. Keeping objects separate > would probably help us when we will want to expand or add another game > theme. Yes, although I'm sure that using inheritance (base->derived classes) will make sense for many things, especially for things in the 'world'. (I'd better get to that book:-) > > This is my view of the game and I would like you to present yours. I'm going to work on this some more. Good discussion. Andrew |
|
From: Petras K. <mox...@de...> - 2002-10-11 08:02:46
|
Friday, October 11, 2002, 3:19:29 AM, Andrew Brosnan rašė:
> I think it would be useful to try to describe or define how the game and
> program are going to work in writing. Starting off with perhaps even a
> few sentences or paragraphs, and refining it to become more and more
> detailed. My approach to writing anything but simple programs is 'If you
> can't state it in English(or some natural language), you probably aren't
> ready to write the code. That's how I feel now. If you asked me to
> describe to you how the overall program will work, I couldn't. Does
> anyone else feel this way?
[...]
> I think we have a good first goal: making it possible for a player to
> move in some world (not interacting with anything but walls). I suggest
> that we write up the details of how we plan to accomplish this.
Here I am going to present my view of the first stages of the game.
Feel free to express your opinion and comment on this.
The goal is to make a charactermove in the world and interact with
walls. So there are a couple of objects that we must pay attention to:
a) a character,
b) a world map, which consists of:
1) walls;
2) empty space.
We also have a client/server structure. In my opinion, the server has
the following duties:
a) generating the map (or reading it from somewhere),
b) generating the character (in theory it could be generated by the
client, but I think it is easier to leave it for the server),
c) transmitting the map information and character information to the
client via some protocol,
d) waiting for the client to give instructions (which at this stage
would only be "move north/south/east/west")
e) process the instructions from the client and respond witha status
message (either "successful" or "not successful -- bumped into a
wall")
The client has these things to do:
a) handshake with a server, get a map and character data,
b) somehow display this data on screen (ASCII art like nethack?),
c) take instructions from the player and send them to the server,
d) update map information internally and redraw the map (if the move
was successful, if not -- display a message why it was not successful)
The communication between client/server could be over XML-RPC.
In terms of Perl, map and character could be instances of object
classes "map" and "character" respectively. Keeping objects separate
would probably help us when we will want to expand or add another game
theme.
This is my view of the game and I would like you to present yours.
> btw, I wondered about using IRC. I don't know if this would be
> [helpful|chaos]. And then there's time differences...just a thought.
IRC is great, but personally I am pretty busy at work (where I have a
normal connection to the internet) and I can only use internet to
check emails at home. Well, if you would agree on a time, I hope I can
manage it (Unless it's at 3am at my local time). By the way, to my
understanding there is almost 50/50 split between Americans and
Europeans, is that right? (I'm from Lithuanian, so this is Europe).
--
Sėkmės,
Petras Kudaras mailto:mox...@de...
|
|
From: Andrew B. <an...@br...> - 2002-10-11 01:20:18
|
On 10/10/02 at 9:21 PM, mox...@de... (Petras Kudaras) wrote: > > What's next with the project? > > 2) Start coding the game itself ;) > > Seriously, we have come to the point where we have enough ideas to > start cracking on our first goal -- making it possible for a player to > move in some world (not interacting with anything but walls ;) > > I think we have agreed on a client/server model, so we also need to > work the protocol. I would personally choose XML-RPC because it is XML > based over HTTP (thus can be easily done via a webserver) and very > simple. But this is my personal opinion, and I would like to hear > yours. I can see a shortcoming of XML-RPC that it can be seen as > "hyped up and buzzwordy and having lots of overhead and not terribly > useful", so tell me what you think about this. Well I guess that I don't have a clear enough idea in my head of how the game and program are going to work for me to suggest a protocol to use. XML-RPC looks like a fine choice for many applications. I think it would be useful to try to describe or define how the game and program are going to work in writing. Starting off with perhaps even a few sentences or paragraphs, and refining it to become more and more detailed. My approach to writing anything but simple programs is 'If you can't state it in English(or some natural language), you probably aren't ready to write the code. That's how I feel now. If you asked me to describe to you how the overall program will work, I couldn't. Does anyone else feel this way? Anytime I am going to write a subroutine, or a module, or a complex program, I need to have a clear idea of how the thing is going to work before I start writing code. Since there are fourteen developers signed up for this project, I think it's necessary for us all to have that clear picture; preferably the same one :-) I think we have a good first goal: making it possible for a player to move in some world (not interacting with anything but walls). I suggest that we write up the details of how we plan to accomplish this. Andrew btw, I wondered about using IRC. I don't know if this would be [helpful|chaos]. And then there's time differences...just a thought. |
|
From: Petras K. <mox...@de...> - 2002-10-10 19:22:23
|
Wednesday, October 9, 2002, 6:55:41 PM, Andrew Brosnan wrote: > What's next with the project? Well, there are two things things, really: 1) Fill the webpage with information. We need to construct the FAQ. Anyone would be interested in at least asking the questions so that I could answer them? 2) Start coding the game itself ;) Seriously, we have come to the point where we have enough ideas to start cracking on our first goal -- making it possible for a player to move in some world (not interacting with anything but walls ;) I think we have agreed on a client/server model, so we also need to work the protocol. I would personally choose XML-RPC because it is XML based over HTTP (thus can be easily done via a webserver) and very simple. But this is my personal opinion, and I would like to hear yours. I can see a shortcoming of XML-RPC that it can be seen as "hyped up and buzzwordy and having lots of overhead and not terribly useful", so tell me what you think about this. -- Sėkmės, Petras Kudaras mailto:mox...@de... |
|
From: Dave B. <ba...@ma...> - 2002-10-10 14:03:04
|
A big thank you to all who sent a response,
I've been beavering away fixing minor problems with CSS, again a
*huge* thanks for all the testing you guys have been doing, its made
my life a hell of a lot easier. ;^)
Fixes/Updates:
* Increased the default text size for large res monitors
(may have to be increased again...!?!)
* Increased the line-height accordingly
* Added a temp GIF as a logo (placeholder) with alt tags for lynx
* 3 gazillion minor teaks on the code/layout/look/feel ;)
Please feel free to saunter over any time to the development pages
and send your comments/bug reports to me... I'm all ears and always
ready to learn new stuff.
http://cplproject.sourceforge.net/dev/index.html
Ta, Dave
|
|
From: <Sim...@br...> - 2002-10-10 09:02:14
|
Hi, good work, Dave! The site looks really nice. I have one request however - please make the standard font size a bit larger. Now we have the minimum readable font size, which is fine for short texts, but longer texts are hard to read when you're working with a high screen resolution. test results: no problems with: Mozilla 1.0 and 1.1 (Windows NT and 98) IE 5.5 (Windows NT and 98) Opera 6.03 (Windows NT) Netscape 4.78 (Mac OS X) font size too small to be readable, no font face in top and bottom navigation: Netscape 4.78 (Windows NT and 98) Cheers, Django |
|
From: <kr...@be...> - 2002-10-09 18:38:09
|
Looks good on w2k IE 5.5 and AIX 5.1 Netscape 4.79 --=20 When I am an evil overlord I will not include a self-destruct mechanism u= nless absolutely necessary. If it is necessary, it will not be a large red butt= on labelled "Danger: Do Not Push". The big red button marked "Do Not Push" w= ill instead trigger a spray of bullets on anyone stupid enough to disregard i= t. Similarly, the ON/OFF switch will not clearly be labelled as such. Quoting Gregor Kasieczka <gr...@gm...>: > Hi; >=20 > > Many thanks to the chief 'moxliukas' who has put it through its paces= =20 > > with much patience. So, I would like everyone to have a look and see=20 > > if; > >=20 > > a) Its OK visually > > b) Works as it should under as many browsers as you can test with >=20 > a)The page is not only OK, I think this thing looks really cool! Great > Work! > b) Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) --> works >=20 > Ciao, Gregor >=20 >=20 >=20 > --=20 > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > NEU: Mit GMX ins Internet. Rund um die Uhr f=FCr 1 ct/ Min. surfen! >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > cplproject-developers mailing list > cpl...@li... > https://lists.sourceforge.net/lists/listinfo/cplproject-developers >=20 |
|
From: Gregor K. <gr...@gm...> - 2002-10-09 18:25:10
|
Hi; > Many thanks to the chief 'moxliukas' who has put it through its paces > with much patience. So, I would like everyone to have a look and see > if; > > a) Its OK visually > b) Works as it should under as many browsers as you can test with a)The page is not only OK, I think this thing looks really cool! Great Work! b) Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) --> works Ciao, Gregor -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! |
|
From: Andrew B. <an...@br...> - 2002-10-09 16:56:27
|
On 10/9/02 at 6:05 PM, mox...@de... (Petras Kudaras) wrote: > Test Home Page for project> I've uploaded two index.html files the > first is just a "Coming soon" at: > > http://cplproject.sourceforge.net The second is under development > > at: http://cplproject.sourceforge.net/dev/ > > I would like to thank Dave for this excellent work and also for > putting up with my nitpicking ;) > > Of course there are still some bits and pieces -- I am still > concerned with the FAQ question sizes and possibly the hover link > color of the links at the bottom of the page they seem almost black > on black), but I really like the overall concept. What are your ideas > and thoughts? > I think the webpage looks great. Nice work Dave. What's next with the project? Andrew |
|
From: Petras K. <mox...@de...> - 2002-10-09 16:06:11
|
Test Home Page for project> I've uploaded two index.html files the first is just a "Coming soon" at: > http://cplproject.sourceforge.net > The second is under development at: > http://cplproject.sourceforge.net/dev/ I would like to thank Dave for this excellent work and also for putting up with my nitpicking ;) Of course there are still some bits and pieces -- I am still concerned with the FAQ question sizes and possibly the hover link color of the links at the bottom of the page they seem almost black on black), but I really like the overall concept. What are your ideas and thoughts? Petras Kudaras aka moxliukas |
|
From: Dave B. <ba...@ma...> - 2002-10-09 14:07:59
|
Hi guys, I've uploaded two index.html files the first is just a "Coming soon" at: http://cplproject.sourceforge.net The second is under development at: http://cplproject.sourceforge.net/dev/ I have checked the HTML: (http://validator.w3.org) And CSS: (http://jigsaw.w3.org/css-validator/) The only error: -------------------- Below are the results of attempting to parse this document with an SGML parser. * Line 99, column 35: ... eforge.net/tracker/?group_id=62952&atid=502368" class=button ... ^ Error: unknown entity "atid" Sorry, this document does not validate as HTML 4.01 Transitional. -------------------- But I can live with that... ;^) Many thanks to the chief 'moxliukas' who has put it through its paces with much patience. So, I would like everyone to have a look and see if; a) Its OK visually b) Works as it should under as many browsers as you can test with I'm not precious about the design of it so any constructive criticism is welcome. Please bear in mind though that the text is --UNDER CONSTRUCTION--, we can fix the text/links whatever at a later date, the object of the exercise is to see if everyone is happy with the simple layout: http://cplproject.sourceforge.net/dev/index.html Many thanks, Dave |
|
From: Michael E. <mj...@si...> - 2002-10-08 13:49:08
|
> > Any suggestions to layout/content/design most welcome, I > believe some > > time ago it was decided to start off 'thinking small', this > I believe > > is the way to go and can expand as needs warrant. > > Well, in my opinion, the design should be as simple as > possible, so that the website could be accessed via lynx and > also via graphical browsers. I was thinking of a simple > design with a few buttons menu (that could be easily expanded > in the future -- text only without graphics?) -- something > like most open source projects have. I think the content should, at a minimum, include the following sections: Project Purpose FAQ I agree, the layout should be simple. mike |
|
From: moxliukas \(P. Kudaras\) <mox...@de...> - 2002-10-08 11:50:20
|
-----Original Message----- From: cpl...@li... [mailto:cpl...@li...]On Behalf Of Dave Barr > Any suggestions to layout/content/design most welcome, I believe some > time ago it was decided to start off 'thinking small', this I believe > is the way to go and can expand as needs warrant. Well, in my opinion, the design should be as simple as possible, so that the website could be accessed via lynx and also via graphical browsers. I was thinking of a simple design with a few buttons menu (that could be easily expanded in the future -- text only without graphics?) -- something like most open source projects have. Petras Kudaras aka moxliukas |
|
From: Dave B. <ba...@ma...> - 2002-10-07 12:54:38
|
At 21:16 +0200 6/10/02, Petras Kudaras wrote: >I am glad to announce tht Dave [Barr] has agreed to take up the webmaster >position in our project. If you have ideas about our website, or if you can >offer help, please contact Dave directly as he his now responsible for it. >If your ideas will require some sort of discussion, I am sure Dave will >forward them to the list. I also hope we will get some sort of status >reports andrequests for help from Dave as well. [..] Hi Petras & all other developers, I am pleased, nay, honoured to have been given this position :) I apologise for the delay in getting back to you all, my current workload has just shot through the roof, I'm sure we've all been there. Any suggestions to layout/content/design most welcome, I believe some time ago it was decided to start off 'thinking small', this I believe is the way to go and can expand as needs warrant. Looking forward to working with you all. Dave |
|
From: Petras K. <mox...@de...> - 2002-10-06 19:18:16
|
I am glad to announce tht Dave [Barr] has agreed to take up the webmaster position in our project. If you have ideas about our website, or if you can offer help, please contact Dave directly as he his now responsible for it. If your ideas will require some sort of discussion, I am sure Dave will forward them to the list. I also hope we will get some sort of status reports andrequests for help from Dave as well. I would like to wish him all the best in this position. Petras Kudaras aka moxliukas PS. I am currently working on some coding guidelines that I will forward them to the list for the discussion. They are mostly dealing with coding and commenting style (well, most of them are just taken from perlstyle manpage verbatim ;). I will also work out the source tree structure and you will also have a chance to comment on it, because I think we have enough ideas to start coding for our first goal -- making it possible for a character to move in some sort of a world, still not interacting with it (except bumping into walls ;) |
|
From: moxliukas \(P. Kudaras\) <mox...@de...> - 2002-10-03 12:31:22
|
>> problem that I have come up so far is the algorithm for wall
>> generating: should the game world map be more like a room based
>> (like a plan of a house with big areas ("rooms") and narrow passages
>> ("corridors") -- much like nethack) or should be a more open area.
> Is storing the floorplan as a big 2-D array the way these things are
> done, or are there more clever ways of doing it? If it is just an
> array it shouldn't bee too hard (I'd even do it) to write code that
> parses an xpm (or bitmap) image and returns a floorplan. It would then
> be really easy to create floors/levels/whatever using your favorite
> image editor. We could further encode terrains, objects, and creatures
> in pixel colors.
Interesting... This thought has never struck my mind (Thank you!).
I was thinking of a more random map generating algorithm (like in nethack).
Yes, it would be easier to make a map by human, rather than generating it
randomly.
Petras Kudaras
aka moxliukas
|
|
From: Dean S. <du...@us...> - 2002-10-03 12:04:55
|
> problem that I have come up so far is the algorithm for wall
> generating: should the game world map be more like a room based
> (like a plan of a house with big areas ("rooms") and narrow passages
> ("corridors") -- much like nethack) or should be a more open area.
Is storing the floorplan as a big 2-D array the way these things are
done, or are there more clever ways of doing it? If it is just an
array it shouldn't bee too hard (I'd even do it) to write code that
parses an xpm (or bitmap) image and returns a floorplan. It would then
be really easy to create floors/levels/whatever using your favorite
image editor. We could further encode terrains, objects, and creatures
in pixel colors.
Good Day,
Dean
|
|
From: Gregor K. <gr...@gm...> - 2002-10-03 12:01:58
|
> > Or, when you say web-based game.. do you mean HTML based, or just like > any > > client/server based game? > > I think we ment HTML/Perl/CGI solution, because that one is very tied to > Perl. > > If we go client/server path, we can even add different we based > interfaces: > Flash? Java applets? something else? Ah.. that is the problem I had (-; I was thinkig about a kind of client which is running in a permanent connection, like a Telnet connection(->mud-like), beacuse I have some difficulties in imagining a only HTML based only RPG(mainly because of speed and input methods?) Ciao, Gregor -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Günstige DSL- & Modem/ISDN-Tarife! |
|
From: moxliukas \(P. Kudaras\) <mox...@de...> - 2002-10-03 11:47:03
|
>Hey folks; >This is my first message to this list, so I think I may introduce myself a >bit. My name is Gregor Kasieczka and I'm an Austrian schoolboy. Welcome ;) > Or, when you say web-based game.. do you mean HTML based, or just like any > client/server based game? I think we ment HTML/Perl/CGI solution, because that one is very tied to Perl. If we go client/server path, we can even add different we based interfaces: Flash? Java applets? something else? Petras Kudaras aka moxliukas |
|
From: Gregor K. <gr...@gm...> - 2002-10-03 11:38:39
|
Hey folks;
This is my first message to this list, so I think I may introduce myself a
bit. My name is Gregor Kasieczka and I'm an Austrian schoolboy.
I'm learning Perl for some months now, and I especially want to learn some
ways of proper coding and how to particip in bigger projects. And I think the
cplproject combines this with a lesson in teamwork and much fun(at least I
believe so)
Now to the real(TM) thing (-;
> James (Mastros) has suggested object oriented game design, and I think it
> is a good idea. I have thought this through and I am starting to get a
> picture of the game structure in my head. The only problem that I have
come up
> so far is the algorithm for wall generating: should the game world map be
> more like a room based (like a plan of a house with big areas ("rooms")
and
> narrow passages ("corridors") -- much like nethack) or should be a more
> open area.
If we really go a Fantasy/Perlmonks based way, I would say that
rooms/corridors are easier for cities, dungeons and building. For the outside open areas
are required, but theoretically a big area is nothing else than a very big
room, so it may be easier that way? Anyone else?
> * overall program design (standalone/bundled into one or with
> client/server architecture?) [I would like to be going for client/server,
> because that would allow easier further extensions, IMHO]
I also think client/server, split up so, that the client only collects the
input of the user and receives the answers from the server(so a very thumb
client)
This would IMHO bring the advance that we can code some different clients,
and it also makes it possible to maybe add a grapphical client lateron...?
Or, when you say web-based game.. do you mean HTML based, or just like any
client/server based game?
Ciao Gregor
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Günstige DSL- & Modem/ISDN-Tarife!
|
|
From: Petras K. <mox...@de...> - 2002-10-03 10:41:19
|
Hello,
> It's been pretty quiet lately. Is there anything that can be done to
> get things going again? I know a few people are working on the web
> site, but how are things coming with ideas for the game?
I am sorry that I have been exceptionally busy for the past week, but things
are sorted out now and should be able to put more work into this project.
James (Mastros) has suggested object oriented game design, and I think it is
a good idea. I have thought this through and I am starting to get a picture
of the game structure in my head. The only problem that I have come up so
far is the algorithm for wall generating: should the game world map be more
like a room based (like a plan of a house with big areas ("rooms") and
narrow passages ("corridors") -- much like nethack) or should be a more open
area.
I think for our first task we should make it possible for people to move
around the game world without much interacting (except probably bumping into
walls :). While this might seem like a pretty easy thing to do, there are a
lot of issues to be decided here:
* how we are going to store data (DB? XML? DBM? any others?)
* overall program design (standalone/bundled into one or with
client/server architecture?) [I would like to be going for client/server,
because that would allow easier further extensions, IMHO]
We have decided that we are going to make web-based game, but I think we
should provide some sort of API for future possibilities... Designing the
structure with this in mind can affect the whole game implementation.
Once we have solved these issues, we can start the actual coding ;)
Oh, by the way, how is our website doing? Any progress? (Dave -- have you
done anything on this?)
Petras Kudaras
aka moxliukas
|
