Vidiot_X

Not sure what you mean. Can you elaborate?

^LOL.. more late nights at coding. @all I have implemented a method that handles positioning of remote ships appearing in a client. It seems to be working well and I think I can get it to handle high ping rates of 150ms-200ms average. That said PUSC will run best at latencies of 100ms or less and support for higher ping rates in general is not recommended but possible. I have added in support for bots into the server and client. It is just the support end for them and I still need to add a bot script framework but that is relatively easy. The bots should be pretty kind to bandwidth as data is only one way (from server to client) for bots and testing 30 bots here locally (server and two clients) yielded only a small increase in bandwidth. I have also added in more option to the HUD to make it easy to access the options you need. The HUD (for now) folds to a smaller footprint (clicking the H/S button) so that the buttons can be hidden. The design is not final but works really well. I have also added a real-time dynamic net/system status window that shows the current, high/low, average ping rate as well as packet loss. Here is an image showing it and the HUD. I will be testing my next build here shortly and it is looking good. - Rich -

Hi, I have been working on the server and now have a complete client correction system in place. Basically what this is a way for the server to correct a connected clients position (game state) and more. This prevents clients from cheating and allows the server to be completely authoritative meaning it can control a connected client. Because clients now only send move/options data (left, right, thrust, fire and so on) there is no way for a client. For the more technically inclined the Phoenix USC server uses a method outlined in Gabriel Gambetta wonderful tutorial on fast paced multi-player games which you can find here. This method works really well and when coupled with an 'Unreal engine" like buffer for lag compensation yields a smooth client correction (from server) and can handle high latency. In fact the client and server are in almost perfect sync using this method allowing for very few corrections to the client aside from when the client is sending inputs. This means for example when the ship is coasting in your client it requires virtually no corrections from the server even when it hits a wall. This is possible because the client and the sever both run exactly the same code for movement and such. I will be working on getting remote ships appearing in a client to move smoothly. I have a working method and I am applying it now. Once that is done the networking code will pretty much done and I can finaly move on. http://www.phoenixusc.com/board/images/smilies/happy.png I have also started to add a ship selection interface that will allow hundreds (that's right 100's) of ships to be available. Here is a early draft of what the interface will look like. I'll post some more media as soon as I get the next build done. Rock on, - Rich -

Hi, I put up a Twitch feed webpage on my site. Here. For now you will be able to check us out testing Phoenix USC, but after PUSC's release I may expand it to include others. - Rich -

Thanks. The board plugin I use was written by a Polish author and I need to fix his misspellings. Actually I am installing a new version of it tonight so I will fix it up. It is based on GameQ which is an open source server listing PHP library which will allow PUSC user to setup server listings for PUSC on their own sites. You will be able to do both. Once you setup PUSC you will be able to click on 'join' from the webpage and it will run the PUSC client and log on to the server. You will also be able to use the PUSC client launch application which is similar in stye to Continuum's. - Rich -

Hi, Still hard at work developing PUSC. I have setup a server listing system for PUSC on my site and you see it in action here: Main Board Index http://www.phoenixusc.com/board/index.php Server info page http://www.phoenixusc.com/board/serversboard.php?action=more_information&sid=5 I am using sort of a minecraft JSON query protocol which works over TCP and is supported by the PUSC server which means the server can report it's status to a website or to the PUSC client launch application similar to how SS's works. The server listing on the site gets an update from the PUSC server every five minutes and reports who's playing, number of playes, the current map and more. You can even launch/run the PUSC client right from the website. I have redesigned the server to be completely authoritative now correcting a clients state such as position and velocity. It seems to work well and allows the server to correct a client when it is out of position or is cheating. The system should 'nip cheating in the bud' as the only data the client sends to the server is moves and options data, no position or velocity data is sent. So I am just about to test the new server and if that goes well it will not be to long before I can move onto other areas and bring PUSC to open beta. Checkout the server listing. - Rich -

Hi, I am hard at work trying to do just that. I am still working on the networking stuff which is pretty tough to get right, but I'm homing in on it. - Rich -

Here is an image of us testing. I'll have a video up after I make a few more bug fixes and changes. http://www.phoenixusc.com/Personal_Post_Data/net_test_2.jpg

Hi, This early version of the server is functioning pretty good. Mainly at this point I am interested in handling latency, packet loss and out of order packets and the server is at this point is ignoring packet loss and out of order packets to a large extent but functioning great. Really this is a test of the client and the server as they both use the same code to execute game. The design I am using is based on the time a packet was sent and a buffer of game states for a client. The server and the client both have a buffer of the past moves (left, right, thrust), velocities, position and more that are used to look up where a ship (client) was when the packet for that client was sent and can replay a clients movement both in real-time and past states quickly replayed to sort of catch up to a position. This kind of technique is similar to something you might see in Quake or Unreal. The upshot is it is good at handling lag and packet loss which as you all know is the 'name of the game'. So aside from some connection issues which I believe we have worked out the performance overall is excellent even in it's early form. I will try to post a video soon and let you see how it performs from a client view here soon. Looking like a great start. - Rich -

Hi, I will be testing the server for PUSC today with the beta team. Looking good so far. I will let you know how it works out. - Rich -

Hi, I think not It describes how Continuum generates it's encryption key and more an interesting read especially if you want to make a new client or server for SS but could be used as an exploit. Basically it appears that Continuum uses an expansion method to generate the encryption key. - Rich -

That makes sense to me. I do have a link to how the encryption might work in continuum but fear to post it.

That is true but the map editor is easy enough to use and the graphics can carry over to it. Fresh start! - Rich -

Hi, I have been working on the server and client model for Phoenix USC over the last month. This, with out a doubt is the toughest portion of the project to code and develop. My goal is to make the client/server model as secure and cheat free as possible. This requires an approach known as client side prediction and an authoritative server. Basically a system that takes control away from the clients and makes the server the supreme authority on all aspects of the game. The biggest problem with developing a system like this in a 'twitch' style game like Phoenix USC is the lack of position, velocity and other data being sent from the clients. In the above model only moves (left, right, thrust) and a time code are sent to the server. This makes it especially tough to implement in inertia style games where the client ship (actor) keeps moving between packets sent from the client or server. Additionally the ship can move in any direction and can form curved paths and also react to hitting a wall or other forces such as repel. All very difficult to predict and maintain a parity between the server game state and the clients games state. So I am working on two different networking models at the moment. One as described above and another that allows additional client data to be sent to the server that is secured by encryption and other security measures. This second method uses a authoritative server and client prediction but relies on additional data from the client such as velocity and position. While potentially open to cheating the server monitors the actions of a client and can reposition a client if needed or discontinue a client that is cheating. So, I am wading through all of this and it is really a matter of balancing security and performance. I will keep you posted on my progress and I am not to far off from locking this all down and moving forward. I have a working server and client and it is now a matter of choosing the best model for networking and security. Regards, - Rich -

Ya, I wish I could get better video at HD levels. But I am able to record video at 30FPF 1366x768 while playing Phoenix on my lowly Emachines dual core with on motherboard video. Really not bad and shows how efficient Phoenix runs even on low end systems like mine. Almost everyone should be able to run the client no problem on the humblest of systems. - Rich -

Anyone tried this? Never played it before

@Resol The video really does not do justice to the shield FX or the rest of the FX and in game look pretty good. But I'm always improving things. - Rich -

Shown here is a very large 1024x1024px background wormhole effect which includes blending effects like transparency and alpha blending. The bullets/lasers use a light blending effect that allows them to change color slightly to stay visible over the background effects. The 'in game' look is just awesome and the parallax effect is outstanding giving the game a realistic and pleasing look and feel. Very happy with it. If you are following Phoenix USC I welcome any feedback and look forward to getting our tech/preview demo ready for you to take a look at. Thanks for your support. - Rich -

Hi, Refining and improving animation effects. This looks really cool in game. - Rich - http://www.phoenixusc.com/Personal_Post_Data/new_anim1.jpg http://www.phoenixusc.com/Personal_Post_Data/new_anim2.jpg

Hi, I am experimenting with very large animated images as backgrounds. This wormhole effect is a 1024x1024 image scaled by 200% and LIGHT blended which gives it a bit of a lighted effect and Alpha'ed at about 60%. I'm in the process of allowing all parts to be animated or static which will help to liven up the game. - Rich -

Hi, - That I would interpret as the shields having squared edges? This is an error in the animation images for the bot shield. On the fix list. - Rich -

Hi, Well, I am thinking more along the lines of how to integrate the changes into the code as apposed to what to do. - Rich -

I think I can and I am looking at the best way to do it code wise. It would help with weapons impact tracking and if I can I will add color to the impact so that a player can tell what weapon is impacting shields at a glance. On the list.

http://www.youtube.com/watch?v=YPrckubBo-8&feature=youtu.be Hi, I have added shield effects for ships. Now weapons impact is indicated by an animated shield effect. In this development video the bot ships glow green and my ship glows red with the shield effect. This really helps with weapons impact tracking and looks cool. Also added is the energy status of each bot shown just under the ship. I have also reduced the size of the weapons sprite for general laser/bullet style weapons. This helps with less weapons clutter with lots of ships engaged in battle. Weapons like bombs and EMP's will have larger animated effects for weapons discharge. Generally all the weapons and ship graphics and physics are fully configurable and can be changed to suit a map design. This video is recorded at 30FPS for better viewing.

Map Editor Part Construction Hi, A little louder audio in this second map editor video on part construction. I will rerecord the audio as soon as my new mic/headset arrives. - Rich -