Vidiot_X

It's working. I have the bots navigating the Line2D path. The bots start with the first line segment position and once reached then navigate to the next position. I am using Godot's NavigationServer2D to navigate the path from position to position. It's working well. The bots will use these Line2D paths as preferred paths and use them to arrive at an area of the map. Once the destination is reached (the end of the line path) bots will either hunt or defend and loiter. I will have lots of other uses for this Line2D path method for sure. More soon... Vidiot_X

Hi, I am currently working on navigation lines for bots to follow. In Godot, when queried the NavigationServer2D will return an array of points to a destination. These simple Line2D nodes in Godot provide an array of points to a destination which can be navigated to by a bot ship. I'm hoping this simple idea works out (it should). Bots will breakaway from the path when an enemy is near. Typically bots will use these navigation lines as a preferred path to get to the flag room or other areas of the map. More updates soon. Vidiot_X

Dedicated man!

Here are some images of the current state of Phoenix USC's map and lighting. Lots of tweaks and new normal and specular image maps have improved the look quit a bit.

Hi, I have been busy and making progress on Phoenix USC. In this video you can see the recent changes to the map and lighting. I have 32 bots on two teams fighting in base testing Phoenix USC. This simulated game play gives an excellent view of all the wonderful progress and a glimpse what is to come. Some of the key development progress: Small cones removed and replaced with dragons teeth barriers. Other areas of the map redone to improve the overall flow of the ships as they move around. Some ISO tiles have been redone for better lighting and visuals. All base areas now use navigation polygons and have been updated to include recent design changes. This allow bots to navigate in all areas in and around the base arena. All normal and specular maps are redone. This has improved lighting greatly and reduced specular artifacts to almost zero. It has also has greatly improved the visual clarity with better contrast and highlights. Some static lights have been removed and others have been resized and positioned to reduce the lights used in game. Changes to ship lighting for a cleaner brighter look. Your player ship is now supports a main dynamic light. This improves the look and works better with real-time shadows. All other lights are static and "do" interact with the map and all ships. All remote player and bot ships are affected by all lights and shadows in game. Code changes to attach mode. Development here is ongoing and will mimic current SubSpace / Continuum attach modes. For now I have attach mode working so that you can attach to a player and detach all with a key stoke (F7). Networking code improvements. These are the development highlights for this month. I will be working on attach mode getting it ready for match play and then moving to repel. Once these features are in place I will be working on a simple capture the flag match play system to get us going. Moore soon... Vidiot_X

It's been 10 years since my last post here. In that time I have learned much about development and coding. It feels like I've come full circle posting here again. I am pleased to show you what Phoenix USC is now. It is an all new game including a new server and client. Phoenix USC use a fully authoritative server, TLS encrypted networking and an encrypted client application. All this means 'ZERO' cheating. Phoenix USC now supports 2D ISO based visuals with real-time lighting and shadows and uses the same inertia physics as SubSpace. So much has been designed and developed sine my last post. Over the next week I will post more on Phoenix USC. I will be posting regular progress updates here and as we go along. For now you can checkout one of the sites below to catch up on Phoenix USC's progress. Awesome to be back! More Soon... Vidiot_X Phoenix USC Discord Phoenix USC ITCH.IO Phoenix USC YouTube Phoenix USC Website Phoenix USC Development videos: .

Hi, I would like to thank those following Phoenix USC for your interest and support. This forum (subspace.co) is closing so in order to follow Phoenix USC's progress you will have to use the following sorceresses. Phoenix USC Website - http://www.phoenixusc.com/ Phoenix USC Forum - http://www.phoenixusc.com/board Facebook - https://www.facebook.com/PhoenixUniverseOfSpaceCombat Google Plus - http://plus.google.com/u/0/b/102638684796408046432/102638684796408046432/posts Twitter - https://twitter.com/PhoenixUSC RSS Feed - http://www.phoenixusc.com/feed.rss Viemo - "https://vimeo.com/channels/phoenixusc" YouTube - https://www.youtube.com/user/PhoenixSpaceCombat I still am on track for a late November / early December standalone alpha demo release. I would encourage you to follow Phoenix's progress and get a copy of the alpha demo when it is out. As a continuum player I can guarantee you will be blow away by the leap in performance, features, visuals and an experience you only dreamed about in SS/Continuum. I would like to thank Polix for allowing me to have a forum here. I am going to miss being here and I wish him well. The spirit of SS will live on and I aim to make it happen. - Rich -

That would be me as well. I will miss this place and all of you. Polix you rock and may you find a new passion and have a happy life. Thanks for all you did and all that you spent. At the end all I can really say is thank you. - Rich -

Howdy, Just a little up date on my progress. I am still on track for delivering the alpha demo at he end of November or the beginning of December. All the basic features should be available and it will be preview of the what is to come in the online beta version of PUSC. Right now I am working on bot AI which is not bad at the moment as the bot will give you trouble and the ship settings seem close (movement/weapons). I am also setting up three different ships with different weapons packages (lasers/bombs and maybe mines) which you can select through the 'Ship' option in HUD. I am also trying to get the 'Buy' system to allow purchase of an additional weapon or two, it's a little difficult to do as it is setup for a server and not a standalone demo, but I think I can modify it. Lastly, fixing bugs, tweaking sounds/graphics and more. I am very hopeful this alpha demo preview will stimulate some wide spread interest. Technically, I am very happy with PUSC's performance and it's look and feel. I have gone to great lengths to develop a professional game over the last year and ten months. If you are Continuum player, well, you should be 'blown away' by PUSC. At lest that is my hope. So, look toward the end of November for the demo and please spread the word. - Rich -

Hi JoWie, I might do that in the beta release. It would not be to hard to do. - Rich -

Hi, I have posted some samples of the ambient soundscaps (music) I am developing for the alpha demo. You can have a listen to three one minute samples here. It looks as if I wont be able to have the demo available until next month at the earliest. I just could not cram into the demo everything left to do in such a short time frame. But, It should be ready late next month. You can always follow Phoenix USC at it's homepage: www.phoenixusc.com Rock on, - Rich -

Made it to 18th today in rank on IndieDB. Lot's of interest in the up coming demo.

Hi, This is a video of the alpha demos progress. I should have an early version available very soon. Be sure to register at phoenixusc.com . - Rich -

Hi, I have added in impact effects to PUSC. In this video you can see that all of the weapons in Phoenix USC use separate animated images for impact effects allowing for a colorful and easy way to tell what weapons are impacting a ship or other object. It will be in the 'early' alpha demo. - Rich -

Hi, It is a sad thing that this forum will be closing according to Polix ( http://www.subspace.co/topic/27611-subspaceco-eol-october-31st/ ). You can follow Phoenix USC's progress at phoenixusc.com or you can follow here. You can also see the progress of the alpha and beta downloads here. I will try to have a special early alpha demo of Phoenix USC out by mid October if I can so that you can test drive the game engine and client, basically a preview of what is to come. It will be a special 'early' alpha demo aimed at the community here. It would be earlier then I had planned to release an alpha demo but given the circumstances here I thought it might be a good thing to do. I would encourage you to register on the phoenixusc.com forum and keep up to date on Phoenix USC's developments as well as gain access to the up coming demo. Personally, I would like to thank Polix for his support of Phoenix USC. He provided a forum here (sorta got me started) and has been encouraging thought. I will miss him here and his wonderful support of Subspace/Continuum. Truly a man worth including in Subspaces history. Regards, - Rich -

^Thanks @all I will be posting new videos to vimeo.com for now. Google/YouTube IMHO has just totally lost it and is now driving away 1000's of content providers. So I have setup a vimeo account here and new videos will be posted there. The same video from above is posted there and for me it plays with better quality and vimeo will allow you to buffer the entire video (unlike YouTube) which is great for slower connection. - Rich -

Hi, I have posted a video showing off the latest interface features, chat, IRC chat, ships and more. It views best at 720p and you can get a good look at the ships and tiled background as well as the interfaces. I had to record this on the server (client code being worked on) so ship explosions are not shown, but aside from that it is a good snapshot of development progress. Currently working on ship and buy systems. Changes to Phoenix site design, check it out ( http://www.phoenixusc.com ) Thanks for supporting Phoenix USC. - Rich -

and here: http://www.indiedb.com/games/phoenix-universe-of-space-combat/news/phoenix-usc-new-background-effects-interfaces-and-more

Also a good update here: http://www.phoenixusc.com/board/showthread.php?tid=227

Just as soon as I can. Still lots to do, but I am close.

Hi, Here are a couple of images of the map using a tiled image background which just works great for parallax'ing. Combined with the PD art space station the illusion of parallax'ing and movement is 'spot on'. You can also get a look at the HUD setup with radar as part of the HUD. The radar can be un-docked from the HUD as a free floating resizable window. HUD also folds to be smaller. Just a little update. - Rich -

Hi, Here are a couple of images of the ship/resource buy system interfaces in development. As you can see the GUI system is working well and is very capable. Basically where I am headed is a buy system that relies on limited classes of resources that include matching objects. So, a weapons class of "Guns" would include cannons, lasers and so on. The interface also doubles as an inventory of purchased items and a way of selecting them. - Rich -

@JoWie I was reading over that pdf link and this sounds very similar to the way I am approaching this: I essentially do the same thing, using a state buffer that records 'key state' variables for every frame ( 16.66ms frame time ) for 1500ms. The leading state (least delay or past time) is rendered to the screen. This state buffer is used to calculate any corrections based on past 'slices' of frame state. It appears to me that we are closer in design then not. Anyway I will read through the rest of it. Interesting read. Which has crossed my mind but only briefly. - Rich -

Hi, The server uses a state buffer that includes velocity, position, angle, turn speed and time stamp. This buffer is only used in rolling back to a previous state using the time stamp and resetting the above variables to the a past state. But, this buffer is in addition to the actors 'object' general state that includes all of the variables like energy, weapons, ship, fire delay and really all of the variable associated with a map as the server plays/process it's own copy of the map and is really the only state that matters. So if a client actor fires a weapon at remote actor the server is going to make the call on if it was hit or not despite what you may see on a particular client. It does this by using the above method where it receives a client actors packet, rolls back to the position when the packet was sent and then processes past moves/options/commands immediately (up to the the current server state time stamp). While processing these moves/options/commands it factors in collision, resources use (wepaons, bombs, warp, so on) and updates any state variables. At this point the server also limits a players action based on the client actors server state. If a client actor for example is firing a weapon and is out of sync for some reason or is cheating (say unlimited weapons fire) the server will not let it fire more then the rate predetermined by the weapons specifications, the client may send lots of fire commands but the server will ignore them and only fire the weapon as expected. This also applies to any other possible command issued by a client actor. I will be adding some packet checking to make sure packets forwarded to other server connected clients are clean and valid which will also help. Additionally the server also makes the call on a kill, energy state and more by sending updates to the client. In the case of an energy state the server sill let the clients calculate it between server updates, so the energy states for actors on on a client or the client actor itself will all be server controlled. In the case of a kill the client will wait for a kill command from the server before a actor is destroyed. I should also note that the clients also look for cheating and sync errors by also limiting remote actors in a similar way. Since the best performance is going to be to immediately forward packets to clients connected to the server the clients will also check to see if a remote actor is for example firing a weapon at a given predetermined rate of fire in the same way the server does. Possible because the clients and server use the same code to run the game. For out-of-order, missing or malformed packets the server is ignoring them for now, but this will change here soon. The best reason for handling them is for a better simulation mainly when it comes to weapons and hits/kills. Positioning is not as effected but if packet loss gets excessive will be a problem. Generally the server is ahead of the clients and can correct or account for some packet loss information. So, this is where I am at now hooking the remote actors and managing them. As it stands now player 'A' would be able to fire the weapon. I will probably deal with this by expanding the state buffer and comparing past actor states, but I am not sure yet. The solutions i have researched involve lagging the client actor by a given time (similar to trailing state) and having the server process client actors from the past. This would work in this scenario but at a cost to latency performance. But, I am working on it now and experimenting with a few different methods. My overriding concern is latency performance so I am trying to solve this without resorting to past state reconciliation. In general an authoritative server is difficult to implement in a twitch style inertia based game like PUSC or SS. Because the clients 'do not' send position or velocity data it can be difficult to accurately reflect actor states especially when server correcting a client actors position (with no snap back). But aside from a few little issues the model I have in place works well and does prevent cheating. One of the last issues to deal with is the above. - Rich -

Aww. The 'trailing' state is handled via a stack or state buffer ( circular buffer) that records some game state "snapshot" information up to 1.5 seconds of past states. When a client sends a packet of moves/commands the server uses a time stamp included in the packet to look through the state buffer and reset the current client actors state (server side, state buffer includes position, velocity and more) to the state at that time stamp and replays commands/moves through to the current server state. The remaining commands/moves (if any) get played out in real time and a verification packet is then sent from the server to the client. The client uses a similar state buffer to apply the server verification (which includes position and velocity) and will reset the clients actor state, replay moves, apply some interpolation (if needed) and finally include any state corrections into the state buffer. It actually is not a great deal of trouble to get going and with a one to one exchange of packets the method allows for fairly low bandwidth as the system only sends a server correction every one second outside of the exchange. - Rich -