;long time ago;
i was thinking about zymotic and splitscreen, co-op and all tht ssh*T. Well i thought of a feature in zymotic that lets you do the whole campaing on-line (would be possible even in nexuiz e.g. lvl 4 Team DM that you could play on-line with your m8 and if your team won the .cfg file would change to 5 as it does when you complete it single player). Now here is the funniest part, i was thinking of it 2 or a year ago and EA has just made a game that does exactly the SAME its called Army of Two!!! I think that would be dead easy to do (i think a simple modder can acomplish it).
;far, far away in the far, far galaxy;
VoIP Wars
well it's the post named "this feature must be included in multiplayer games". The basic idea was of integrating some open-source app/or building from scratch an in-game VoIP.
I think it would rather have a larger effect in Nexuiz because it is more dynamic, but anyway NO ONE uses the keyboard in the game (apart from the begging and end) everybody uses Xfire but not every one. This results in isolation and sh*t games due to the lack of co-operation. Now some of you said there is no way such thing can be made because of the lack of open-source VoIP client we could use, now i made it easy:
http://www.voip-info.org/wiki-Open+Source+VOIP+Software
There are also codecs which can be used to compress the sound to limit the bandwitch usage. http://www.speex.org/
This website also contains free-source TTS (Text-To-Speech) that can be used to generate dialogs in the game. Like Cortana on HALO. This would be a great alternative to recording dialogs and storing them as an audio file. There is a simple TTS that is downloadable for Game Maker (app for retard game makers). This TTS can read script from a .txt file and what's best you can script in changes of pitch as it reads the text so even each sylabel is read at a different pitch (e.g. australian accent which tends to go up at the end of the sentence).
THE PASS IT ON TECHNIQUE
At this point I thought of the problem of using the team and all player message because if there are 13 players overall the message would have to be sent 12 times!!!! So i think of a "pass it on" method e.g. when player a sends a message to all players his computer sends it only to player no. 2's PC but before the actual sound there would be command to send it to player 3 and player 3 plays the sound and at the same moment starts to execute the command to send it to player 4 and so on. Single messages on F1 are just simply sent with no passiong on
what i meant was if you were speaking to the whole team of let's say 6 ppl you would have to send the message 5 times (remember one of the 6 would be you) that means that if you had a the audio streamed at 44kb/s means 220kb/s when the message is sent and that means a lag. To prevent this kind of thing the sending computer would locate the computers that have their microphones idle and the one's that dont. There are 3 idle computers. It sends the audio only to one idle computer and one "busy computer", the message has to get to three more computers(2 idle, one busy). How is it going to get there? The first idle computer sends ("passes it on") the audio to the next idle computer, then that one passes it on to the next one and the last idle computer passes it to the second busy computer. Now let me visualise this:
[img=http://img356.imageshack.us/img356/6933/73270969kf4.th.png]
![[img=http://img356.imageshack.us/img356/6933/73270969kf4.th.png]](http://img356.imageshack.us/my.php?image=73270969kf4.png){kind=link}
Note: by idle i mean not speaking to the mic and by passing on i mean streaming ( if any1 had experience with shoutcast, e.g. there is a popular radio and i t has a limit of 100 listeners and M who is maintaining all of this wants to brodcast to 100 more then he can get some1 to make another radio but on the playlist they would have that M's radio)
This way we end up with amazing 88kb/s. There is only one problem one of the idle computers could send the message back to the computer that has sent it (e.g. idle 3, sends it to idle1). So each time the audio is passed on an index is sent on the begging and then every second, that index would state what computers are streamed to already. In the above situation my computer would send an index to the first idle computer stating :
sent
xx.xx.xxx.xxx:port which would be my ip
xx.xxx.xxx.xxx:port which would be busy1
then each time the machine receives the audio, it would add it's own ip into the index and send it to the ip that is not on the list. Ofcourse there would be no need to pass the index to the far end computers (busy2 and 1). Due to lack of index busy1 and busy2 would treat this call as an individual call. The index passe from idle2 to idle 3 would be:
sent
xx.xx.xxx.xxx:port which would be my ip
xx.xxx.xxx.xxx:port which would be busy1
xxx.xx.xxx.xx:port which would be idle1
xxx.xx.xxx.xx:port which would be idle2
NOW HOW WOULD THIS WORK?
To avoid confusion and all other lags/errors/sh*t the VoIP service would have to have a different port. The integration would be kept to the VoIP being included in the game app, F3, F4 and F5 mapped as Team, Player and ALL. At the begging of the game, the coputer would load the list of the players, their IPs, teams and if it's a DM only playernames+IPs. Then they would be loaded into a xml or cfg file that would have name+IP+(not present in DM)Team=B/G/R/Y. The app also tries to connect to the VoIP port of the other computers, if after 3 tries the connection is timed out, the player is removed from the contact list file. This is to check if the player has the VoIP patch/VoIP enabled. So if you press F4 the computer checks if the players with your team variable are idle or busy and then the whole process starts which is described under THE PASS IT ON TECHNIQUE. If you press F4 the list of players on your team scrolls down, then you choose the player with your numpad 0-9 and if ther are more than 10 players on your team +,- would be used to go onto the next,previous page. Then the audio would be streamed without the index. F2 could be mapped as a quick response button so if you get a personal call like in the example above you can answear it right away, without the hassle of pressing F$ and all the rest. The program would just have to index who was the last one to call you and incase of the Team call it would index the IP from the top of the index.
;light years ago;
SPLIT SCREENT
Problems:
MULTIPLE VIEWS
the engine supports multiple views already using CSQC but the views are dependent on the position of the cursor/aim so the variable would have to be reinvented into maybe P1CURSOR=x,y,z and P2CURSOR=x,y,,z . If joystick enabled P2CURSOR=x,y,,z would become Display=x,y,z
INPUT - AIM SUPPORT
Some of you say its rather a big problem, and i would like to show its not. The Gamepad's second analog stick has two axis Rx and Ry the position of the cursor(i would call it the fire line) changes only when the variables change from 50 in some cases the middle point is 0 and then you have negative values as down or left. Then i don't know how it is done in nex that the cursor turns red if you go over an enemy but i suspect nex draws a line from your character model through the position of the cursor and until something gets in its way. Then ofcourse if an object like the opposite team player crosses that line, the action of changing the cursors colour to red or loading a tga with a red cursor is triggered. If it does something else there are more ways of getting around it. So if we add a tube that is drawn just like that line but has 1 and 1/2 metre in diameter and the centre of it would be that line described above. Now here is the trick, we have two variables that are stating positions on would be real and one called display, after each spawn they would be equal and the movement of the joystick would affect both in the same way. Real would record the position of the cursor so when the joystick moves the position changes and Display would be just the same (note: they are not dependent on each other) but Display are the only variables that the program will position the cursor from (so the position of your cursor depends on Display not Real). Every 800 ms the program will check (let me call this a trajectory check) if a hostile object such as a player or an AI bot crosses the 1.5 metre tube, the variable Real and Display will not be calculating where is the cursor according to the joystick movements but will change so the cursor is in line with the enemy (if there are more than one then it will lock on the closest). After this is done the Real variables will be calculated normaly untill (only if a hostile object crosses the tube) next 800 ms. Now here is the realism the tube is dependent on REAL but the displayed cursor isn't. Even thou you might be locked on and your cursor pointed at an enemy, if you move the joystick the tube will change its position. So if within 800miliseconds (next trajectory check) your target that you were fixed upon is not within that tube the Display value and consequently the aimer/cursor is synchronised TO the Real value. So just like on PC it would be easy to aim at a still target but hard to keep on the moving one.
NOTE: After locking on the Display variable and the position of the cursor would be constanlty calculated in the event of the enemy moving. Keep in mind that you would still have to follow him with a joystick because after 800ms the computer would check if the tube is still fixed on the player. I think there should be a ghost cursor(grey), but the view wouldn't depend on it. If it get's out of the view (outside of the screen), the synchronisation would be triggered automatically, so if you dont follow with the ghost you loose track even before the next trajctory check.
IF SUM1 THINKS THIS IS A BIT CONFUSING I CAN POST AN IMAGE OF WHAT IT WOULD LOOK LIKE.
PROBLEM NUMBER 3
FLASH
damage, pickup etc. When you pick up health your screen flashes and things like that. I think there is a shader responsible for all that and it can be modified, if i am wrong then the feature can be removed from the console and replaced with something.
SOUND
Great problem! but yet another dull try to avoid split-screen. Well guys have you thought of making a bit more use of Sound Systems. Let's keep it simple, there is a thing called balance which can be used to make sound seem as if they are on the right or on the left.
So if you add the function of audio balance into the game and a WARNING screen telling which player should sit on which side of the sound system, you have the problem solved. If the sounds that are played get labeled with the player number 1 and 2 or top and bottom, you can play them at different ballances. Example player 1 otherwise known as bottom is on the keyboard and to keep a lot of space for his right arm he sits to the right, his sounds are played at a 100% balance.
NETWORKING
make the clients game adress the ports to different players, so they dont get killed if only one of them dies and make the other one use a proxy server to save confusion for the host.
EASIER WAY
You just launch two apps in windowed mode and half the second resolution parameter - 16. On one disable mute when idle, etc., now you would only need joystick aiming support. If you want to play a co-op campaign you just do as in my first idea (if my idea was realised).