stuff
this is something i sent to the contacts email address, but never got a reply.
as sent :
"
this is just a set of comments/opinions i have. just for another view.
make open privateer multiplayer only, with a 'fake-me-out single player'
- single player is a local client connected to local server, with a local state set dedicated to 'pseudo single player'
- this allows for simultaneous multiplayer and single player development in a single effort.
- you dont have to go back and modify what you've done to add-in multiplayer
- multiplayer will natively support missions.
- allow people to join your single player game and play with you as a hired wingman.
- possibly have a cooperative mode where there are 2 protaginists, or N protaginists in a multiplayer mode, seeking to complete the main mission first.
muliplayer section
- have a CS - P2P hybrid.
here is a sample scenario (same as i mentioned to hellcatv) :
"
the benefit of P2P broadcasts are 1/2 the lag time from the moment a person fires, to the time a shot is seen.
this is a clearer overview :
(caps A/B are entitys)
A sends coordinate/velocity/accel to server
B sends coordinate/velocity/accel to server
Server returns all coordinates to all other players withing sensor ranges of relative other players.
A broadcasts coordinate/velocity/accel to clients in sensor range
B broadcasts coordinate/velocity/accel to clients in sensor range
NOTE : this might be done at a range closer than sensor range, i.e. for faster and smoother gameplay, clients can update directly if REALLY close, like within 1/2 gun range or soimething.
A shoots at B.
- broadcast fire to all within sensor range
A strikes B on client side
- broadcast strike to all within sensor range
- send strike to server.
* server evaluates B's position at the time A sent the strike, back tracking B's position X seconds (where X = latency between A and B)
* server sends a validated health change to B OR server nullifies message of A, sending an inconsistency message. (accumulation of messages will result in a drop - aka kick cheater after he keeps it up)
N minute time interval.
- global server updated on player healths, states, etc. their active accounts stored.
A lands on planet, saves.
- global server stores a restore point.
- players allowed some amount of restores before they must continue as-is (or be dead and restart if thats what is). maybe have restore credits count up every so often, like one-more a month.
the broadcasting wouldnt be a problem if its only to ships in sensor range. this range could be cut down some. maybe have action-sensors and navigation-sensors be a bit off. like you can lock planets, etc, from far off, but you wont detect an enemy ship till some bit closer. in any case, it would smoothe out gameplay, while still having a server maintain fairness.
the only thing with a CS only setup is that you are dependant on your connection to that server completely. if you have bad ping to the server, you're screwed. while you might have good ping to many of the other players. [in a hybrid system] Even if you had terrible ping to the server, and average to the players, your gameplay would still be average, and your shots would take off health at some delay after they strike. but that wouldnt be that terrible in exchange for smoothe play.
-scheherazade
"
this thread has the whole post
http://sourceforge.net/forum/forum.php?thread_id=750923&forum_id=205254
i know of the P2P bandwidth issue. though if the P2P connections were capped to the immediate area, and the rest handled CS style, there would be a benefit of lesser lag (p2p) where it will be seen, and global containment like in CS. i think that rather than choose one ideology, take the best out of both. a new approach might do well. no one has tried, so it might be good, never know.
also, on the modellig end, give per pixel lighting a go (like tenebrae
http://tenebrae.sourceforge.net/index.php?page=screenshots.txt)
and possibly scripted shader support for modellers. (like quake3)
supoprt 32 bit tga's
these options would :
- look f'ing sweet and attract peoples attention like gnats to fly-tape.
- give artists some freedom to work with more ideas.
- have included alpha channel for transparency in textures.
- bump maps for surface details, saving polys.
- gloss maps for reflective ares, like glass, or some evvects on rounded edges to exaggerate backdrop lighting, like a suns rays creeping around edges of a ship from behind.
if i were to suggest a model format, i would say md3 (like in quake3)
why? because it is a 3ds file (arguably the most common format) with long filename support and extended frame cap added in. (or so i've read). i like 3ds files cause they are super universal and fairly versetile. the long filenames would be nice, and the frame cap is pretty low on them. also md3 documentation is fairly ez to get.
also, like in quake3 (btw i have worked on and still do work on quake mods, so i can attest to some advantages) i would recommend the use of tags. (just model objects named tag_blah, with a certain dimension that can be used as a new origin for a model daisy-chained to the tag).
this way you can :
- have visible weapons support. guns/missiles attached to tag locations. buy/sell/upgrade arms would be visible.
- have automatically distributed guns and calculated available gun slots and expansion slots
- have missiles fire from tag coordinates, saving effort of having to code in the coords or script them
- cut down on animations if any. ex. an attached model for landing gear would have its own anims. if the body had anims for some thing like a weapons bay opening, there would be separate anim sets.
i.e. body frames 0-15, gear frames 0-15
rather than
total frames 0-64, where 1-15 = gear up bay closed, 16-31 = gear down bay closed, 32-47 = gear up bay open, 48-64 = gear down bay open.
tags and attached models make animation simpler, modelling time shorter, and file size smaller.
so anyways, thats my rant. what are your feelings.
-scheherazade
"
because Origin/EA cannot patent it