Topic: PSPong server side proposals

OK I suggested this here:
www.ozoneasylum.com/Forum13/HTML/000043.html

so that thread could be devoted solely to questions of how to collaborate between the server and client side development people.

So to reiterate - I have a spare account at portland and am happy to open that up to the server side development people so we can get some good feedback going. If this is a good idea then I'll sort out the details today or tomorrow and get back to people here.

Emps


You're my wife now Dave

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

InI: A wise idea, esp. as the Doc has yet to deliver his second feature set. However, there are probably some basics of structure that could be built up and then tweaked at a later point but I bow to your wisdom (it will probably save some time).

Any thougts on this from other people?

Emps


You're my wife now Dave

I'd say wait on the second feature set.
not that it will do any good, since there's always someone who wants to see something new implemented 2 minutes before we go live...

yours,

Tyberius Prime

Regarding your spare portland account:
not too bad an idea, but unfortunatly they don't have the gdlib installed. meaning we won't be able to resample/modify/create any jpegs on the fly.
but still, it might be worth just to establish everything else.
or does anyone have a php account we can use that does have gdlib installed?

Tyberius Prime

TP: Yes that is a problem but a smallish one - if a better space comes up for testing then feel free to use that. The gd features shouldn't be too hard to integrate with the core features if things are developed sensibly.

I have now sent the details of my Portland account to InI and he can hand out the details to interested parties (drop your name in here if you think you've got some good server side skills that you can contribute so we all know who is doing what). I would suggest that to keep things simple that the number of people throwing ideas into the ring shouldn't go far into double figures and all changes have to be approved by InI as he has the best grasp of the Big Picture. Keeping things simple at this stage and working on the core will mean that there won't be too much work involved with the inevitable changes until things firm up a bit more.

mr.maX I'm sure we'd all appreciate your input in whatever way you see fit.

As I hadn't made very much use of the account I had forgotten that it needs to have the MySQL account set up so that has been requested and should be done automatically soon - when that is done I'll instal PHPMyAdmin.

Emps


You're my wife now Dave

well, count me in.

Tyberius Prime

TP: OK - Gald to see your enthusiasm hasn't waned with the little delays. Any others?

Emps

Gald??

Anyway MySQL should now be enabled but I'm having a free problems getting things into the webspace. Pos. a temporary glitch so I'll upload PHPMyAdmin tomorrow (or later tonight - I'm off out now) and we can go from there.

Emps

I've been talking to InI and as people now know he does have a lot on his plate at the moment:
www.ozoneasylum.com/Forum1/HTML/003244.html

He says he is going to try and throw some stuff into the hat but I don't want him to feel obliged so I thought it would be best if Tyberius Prime went on 'point' in these initial stages.

So I thought we'd start off by kicking a few ideas around concerning the database structure and see how that goes.

I'll collect my thoughts and post my initial thoughts here in a minute (I'm just in the midst of something).

Emps


You're my wife now Dave

Sorry I went and got distracted. So some thoughts:

USER_TABLE
user_id
user_name
user_password
user_graphic (if we wanted each user to have their own little graphic)
player_status (are they an active player or not at the moment?)

MATCH_TABLE
match_id
current_volley
??

MATCH_USER_LINK_TABLE (so that we keep things flexible and allow for double matches or for someone to step in mid-match)
match_id
user_id
serve_return (if you are on the side of the net that serves - useful for doubles/triples)
player_number (if we have doubles, or more we'll need to have something to work out the order)

PLAYER_TABLE
user_id
game_prefs (pos. type of graphics accepted)
pool_status (are you in or out)
challenge_status (any outstanding challenges?)
tournament_status (current tournament position)

VOTE_TABLE
match_id
volley_number
vote_1
vote_2
vote_3
vote_4
vote_5

COMMENTS_TABLE
match_id
user_id
comment
date

There are some other things but they are some of the things I was thinking of. Feel free to ask me to explain things if its not clear. Thoughts?

Emps


You're my wife now Dave

well, I'd assume the users want to show of a bit, so we'll need some more fields for that in the users table

like user_comment,
user_homepage...

and I'm not sure why you suggest a additional player table (why not include that in the user table?)

and for the comments, I'd suggest we use the table InI mentioned earlier.

quote:

---

InI wrote:

--- nodeID
--- nodeParentID
--- Player1ProfileID
--- Player2ProfileID
--- Postcontents (HTML)

---

just add a matchid and a say that ParentId is negative one, if it belongs to the match :-)
(but I don't know why Ini included a Player2ProfileID. I think he wanted to keep virtually everything in that table. including the matches. but we won't store any text in the matches table, so we won't need to search there. Right?)

so long,

Tyberius Prime

TP: All good points - although I would also suggest:

user_email
user_icq
user_msn
ETC.

As being able to contact people (esp. when they are players) is vital. It should be possible then to have a little bio page for everyone with links to any matches they are currently playing, etc.

Thats a good idea about using InI's comment table ideas (with those changes) and throw in a date/time so we can sort them with most recent on top (or at the bottom!!).

There may have been a reason why I had the player details in another table but I can't remember what it was!!

All ideas are provisional (the voting business could change quite a bit depending on how people want to do that - voting per player per match or per volley, etc.) and I forgot these tables:

FLAG_PLAYER_TABLE
user_id
player_id

FLAG_MATCH_TABLE
user_id
match_id

Any other thoughts?

Emps


You're my wife now Dave

not at the moment.
I'll write us a mysql wrapper class tomorrow, if that's fine with you, and then we can lay out the basic functions we need in order to manipulate the specific ids.
(if you have ICQ emp, that would be of great help. we can talk about the tables and finish that part of, cool?)

so long,

Tyberius Prime

TP: Go ahead that sounds like a good idea.

I'm home now for the next week and a half and I've yet to install ICQ but the number is: 143655003 (I've updated my profile to include it). I've got presents to wrap and people to see today but I'll sort it out tomorrow. You have my email address in the meantime.

Emps


You're my wife now Dave

I am able to write some code if nessesary. Not as busy now as I have been in the past couple months.

Let me know if you need some help with this.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

your help is sure welcome, InI.
I'll send you the code when it's finished.
I might also draw an UML diagram for the classes/databases...

Edit:
What I can't see though, is how we're limiting the number of posts. Except for using an id field for each, will limit us to 2^32 posts. If each of those posts stored a byte, that would still be 4 gigabyte! And a post is usually sereveral hundred bytes long... So I shall not worry about the DB being the limit here.


Have a safe trip InI...

[This message has been edited by Tyberius Prime (edited 12-23-2001).]

WarMage: The more the merrier (within reason, of course!!).

InI: Great to see you back and full of ideas!! I agree with you and TP about the USER/PLAYER table (I still haven't worked out what I was thinking about - it may come to me later). However, like TP I'm not sure what you mean when you say:

quote:

---

You're limiting the number of posts, match and match_user_link tables
could be one table...

---

All improvements gratefully received as that was only an intial back of the envelope sketch to provoke debate (as things have been a little quiet and it worked too). I'll admit that I'm unsure about the MATCH_TABLE and MATCH_USER_LINK_TABLE but it was the only way I could think of to get the flexibility but I also suspect there may be a better way.

All input welcome.

Emps


You're my wife now Dave

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

ok, I drew the diagram and openend a new thread