Difference between revisions of "User talk:Chaosteil/Galaxy Stations/To Do List"

From WiiBrew
Jump to navigation Jump to search
Line 6: Line 6:
 
::::I had "Unified Accounts" in mind, not "Unified characters". We could allow some servers to use the same character database, but maybe some servers do some modification to their game, so some characters may be overpowered in some servers, while they may be too lame in others. Your skeleton-based sprite system could prove indeed very useful to us and I'm looking forward to see its implementation ;) --[[User:Chaosteil|Chaosteil]] 21:56, 3 July 2008 (CEST)
 
::::I had "Unified Accounts" in mind, not "Unified characters". We could allow some servers to use the same character database, but maybe some servers do some modification to their game, so some characters may be overpowered in some servers, while they may be too lame in others. Your skeleton-based sprite system could prove indeed very useful to us and I'm looking forward to see its implementation ;) --[[User:Chaosteil|Chaosteil]] 21:56, 3 July 2008 (CEST)
  
=Physics Engine Over Net=
+
== Physics Engine Over Net ==
 
The physics engine would be handled client-side. All the client would have to transfer is their X,Y,Direction Facing, and a few other basic stuff. We would probobly also make monster AI client-sided, and have the client just give the server their info to distribute to the other players.Station information (Like whether a door is closed or open) would be server side (so a door is not open for one person, and closed for another). This is just an idea of how I would implement it. --[[User:CloneDeath|CloneDeath]] 00:35, 4 July 2008 (CEST)
 
The physics engine would be handled client-side. All the client would have to transfer is their X,Y,Direction Facing, and a few other basic stuff. We would probobly also make monster AI client-sided, and have the client just give the server their info to distribute to the other players.Station information (Like whether a door is closed or open) would be server side (so a door is not open for one person, and closed for another). This is just an idea of how I would implement it. --[[User:CloneDeath|CloneDeath]] 00:35, 4 July 2008 (CEST)
 
:No, no, no, no, no, no. No actual game-changing code is on the client. The client just sends what he does, and receives what everything around him does. There is no other way to implement it easy and nice into a MMO. P2P is exceptionally hard (I tried it once, never again), so we should just stay on the server-does-most-of-stuff route. Physics are hard to implement this way, but we could also use a lightweight engine made on our own. --[[User:Chaosteil|Chaosteil]] 00:47, 4 July 2008 (CEST)
 
:No, no, no, no, no, no. No actual game-changing code is on the client. The client just sends what he does, and receives what everything around him does. There is no other way to implement it easy and nice into a MMO. P2P is exceptionally hard (I tried it once, never again), so we should just stay on the server-does-most-of-stuff route. Physics are hard to implement this way, but we could also use a lightweight engine made on our own. --[[User:Chaosteil|Chaosteil]] 00:47, 4 July 2008 (CEST)
Line 12: Line 12:
 
We did some talk about the physics engine in the IRC Channel. Basically we will tie the player physics to the client and only let the server broadcast it to the other players. (Still lightweight, since the AI of the enemies is on the server). Shooting stuff is accomplished by sending the position and trajectory vector to the server and let him decide who dies. Box2D is used only for animations to make the whole thing look dynamic, but it won't affect gameplay at all. For lag compensation etc. we'll use a timestamp system. If I forgot something, please write it down here, guys --[[User:Chaosteil|Chaosteil]] 00:07, 5 July 2008 (CEST)
 
We did some talk about the physics engine in the IRC Channel. Basically we will tie the player physics to the client and only let the server broadcast it to the other players. (Still lightweight, since the AI of the enemies is on the server). Shooting stuff is accomplished by sending the position and trajectory vector to the server and let him decide who dies. Box2D is used only for animations to make the whole thing look dynamic, but it won't affect gameplay at all. For lag compensation etc. we'll use a timestamp system. If I forgot something, please write it down here, guys --[[User:Chaosteil|Chaosteil]] 00:07, 5 July 2008 (CEST)
 
::I just mowed the lawn, and we live in the south, and it is a BIG lawn, so excuse me if my rantinging make little sense. I kinda had a bit of that idea in mind, and doing monster AI on client side would be more difficult, but ultimately spread the lag out (instead of concentrating it onthe server), but whatever is fine. As for flying body parts, just send a flag for when someone dies to all the clients that "it be dead by means of an explosion" and have each client run the physics on their own (meaning that the trajectory on every client of the body parts will not be synchronized). Make sense? Anyhow, I am about to faint from exaustion, so ima go play flash games and lie on my bed, bye yall... I will try to get an IRC thing on my laptop soon. --[[User:CloneDeath|CloneDeath]] 21:22, 5 July 2008 (CEST)
 
::I just mowed the lawn, and we live in the south, and it is a BIG lawn, so excuse me if my rantinging make little sense. I kinda had a bit of that idea in mind, and doing monster AI on client side would be more difficult, but ultimately spread the lag out (instead of concentrating it onthe server), but whatever is fine. As for flying body parts, just send a flag for when someone dies to all the clients that "it be dead by means of an explosion" and have each client run the physics on their own (meaning that the trajectory on every client of the body parts will not be synchronized). Make sense? Anyhow, I am about to faint from exaustion, so ima go play flash games and lie on my bed, bye yall... I will try to get an IRC thing on my laptop soon. --[[User:CloneDeath|CloneDeath]] 21:22, 5 July 2008 (CEST)
 +
:::IRC is really preferred right now, as we discuss a lot of things there nobody will probably write about. You can get your SVN and webspace account there for example. #galaxystations on efnet ;) --[[User:Chaosteil|Chaosteil]] 01:11, 6 July 2008 (CEST)
  
 
== Coding style/Naming convention ==
 
== Coding style/Naming convention ==

Revision as of 01:11, 6 July 2008

Small talk

What I placed there is a base of how the to do list would look. First we should decide if the data for characters would be stored locally on the SD card, or remotely on the Server. Either is fine for me, but I prefer server so that no one "hacks" their char to make them stronger. Post what you think --CloneDeath 16:33, 3 July 2008 (CEST)

Data will have to be stored on the server, but we could create a cached copy on disk if we want offline stats viewing. TD-Linux 21:25, 3 July 2008 (CEST)
Data will be obviously stored on the server. I have a realm server system in mind. We could then have multiple servers which connect to the realm server and allow the player to connect to these servers. A thing we would need to decide is if we would have a unified account system or for each server another accounts. I prefer the first version, as it is easier for the user then. --Chaosteil 21:34, 3 July 2008 (CEST)
Yes, I agree, the "Unified Accounts" is always the best, and it avoids that "Most popular server" thing or "Aww man, you did that server? Guess I gotta make a new guy to play with you" kinda thing. I also like the reaserch thing, I usually just plan it in my head, but I do suppose it is good to have it written down too. Ohh, by the way I have made a couple skeleton based kinda sprite system. Very complex... But I feel I could do it again. Anyhow, I gotta go catch the bus now. I will try to be on later. --CloneDeath 21:52, 3 July 2008 (CEST)
I had "Unified Accounts" in mind, not "Unified characters". We could allow some servers to use the same character database, but maybe some servers do some modification to their game, so some characters may be overpowered in some servers, while they may be too lame in others. Your skeleton-based sprite system could prove indeed very useful to us and I'm looking forward to see its implementation ;) --Chaosteil 21:56, 3 July 2008 (CEST)

Physics Engine Over Net

The physics engine would be handled client-side. All the client would have to transfer is their X,Y,Direction Facing, and a few other basic stuff. We would probobly also make monster AI client-sided, and have the client just give the server their info to distribute to the other players.Station information (Like whether a door is closed or open) would be server side (so a door is not open for one person, and closed for another). This is just an idea of how I would implement it. --CloneDeath 00:35, 4 July 2008 (CEST)

No, no, no, no, no, no. No actual game-changing code is on the client. The client just sends what he does, and receives what everything around him does. There is no other way to implement it easy and nice into a MMO. P2P is exceptionally hard (I tried it once, never again), so we should just stay on the server-does-most-of-stuff route. Physics are hard to implement this way, but we could also use a lightweight engine made on our own. --Chaosteil 00:47, 4 July 2008 (CEST)
How about we use a own very lightweight physics engine (fall-down, push this, pull that) for the environment, but for animations and stuff absolutely not related to gameplay, Box2D? It would be just for eye-candy (flying body parts, destroyed objects) and would give the game the "wow, nice" feeling. The own leightweight engine could still allow us to have the effect of "push block from cliff -> kill enemy" without killing the server. --Chaosteil 01:23, 4 July 2008 (CEST)

We did some talk about the physics engine in the IRC Channel. Basically we will tie the player physics to the client and only let the server broadcast it to the other players. (Still lightweight, since the AI of the enemies is on the server). Shooting stuff is accomplished by sending the position and trajectory vector to the server and let him decide who dies. Box2D is used only for animations to make the whole thing look dynamic, but it won't affect gameplay at all. For lag compensation etc. we'll use a timestamp system. If I forgot something, please write it down here, guys --Chaosteil 00:07, 5 July 2008 (CEST)

I just mowed the lawn, and we live in the south, and it is a BIG lawn, so excuse me if my rantinging make little sense. I kinda had a bit of that idea in mind, and doing monster AI on client side would be more difficult, but ultimately spread the lag out (instead of concentrating it onthe server), but whatever is fine. As for flying body parts, just send a flag for when someone dies to all the clients that "it be dead by means of an explosion" and have each client run the physics on their own (meaning that the trajectory on every client of the body parts will not be synchronized). Make sense? Anyhow, I am about to faint from exaustion, so ima go play flash games and lie on my bed, bye yall... I will try to get an IRC thing on my laptop soon. --CloneDeath 21:22, 5 July 2008 (CEST)
IRC is really preferred right now, as we discuss a lot of things there nobody will probably write about. You can get your SVN and webspace account there for example. #galaxystations on efnet ;) --Chaosteil 01:11, 6 July 2008 (CEST)

Coding style/Naming convention

We agreed on having the whole Galaxy Stations source code have the same naming convention and coding style as libwiisprite to keep all the code more organized. The source code is available at request to peek at. If somebody has a better idea, feel free to post it here. The Galaxy Stations team also agreed that we'll try to implement every GX hack we do into libwiisprite to give back some of our knowledge, so this is also useful for quickly implementing code back into libwiisprite. --Chaosteil 00:21, 5 July 2008 (CEST)