Vidiot_X

@Avast Right on. As far as the "who-what-where" on me I have been involved with computers for 25+ years starting with coding my first app on a Timex Sinclair circa 1980's. I love to hang out in DSB and you can find me there as Vidiot_X. My experience in programming covers C,C++, BlitzMax, Monkey, HTMl5 and Java, plus more. I'm writing Phoenix SS really because I love to play Continum/SubSpace and it has been a notion of mine to right my own epic multiplayer space shooter game. @Cheese Well, not really. All of the part data is loaded into memory. Parts are the basic building blocks of a map. When the parts are loaded the image data they contain is stored into video ram. So you may have placed a thousand copies of a 'wall' part (for example) in a map, all of those copies use the one part image stored in video ram. I will document a fuller explanation how this all works later. It can be a little difficult to explain/understand. - Rich -

@Avast, Most of what your requesting should be doable. The basic outline on the way the map engine works is it loads a list of parts which include a tile image, collision data, angle, blending, color data and more for each part. When you place a part in the map editor the part data is 'transferred' to the map and once placed the part is definable and it's attributes can be altered. This link (http://www.subspace....tors-and-parts/) covers the map sector model which should be large enough for very large maps with ten's of thousands of tiles derived from a list of parts. It's important to note that each part in a map is linked to a list of pats that are used to make the map, so even though you may have thousands of parts in a map things like image data are referenced to this part list which means memory is used efficiently. So a map of ten thousand parts (or tiles if you prefer) uses roughly the same memory as a map with 1 part given the size of the sector layout. As far as how many parts you can have, there is really no limit other then video memory. I'll be outlining this all when I have the time but be assured the Phoenix SS frame work will be flexible, scalable and efficient. - EDIT - I should add that I do not foresee a problem with lag and map parts. The server will have a copy of the map and only look trough the part collision data (and other data) that is very near a player or bullet which limits the range and thus the sum or parts to check. The way I planed to layout the server framework is to translate the 'player-object' position from the server to the client. The client will interpolate the gaps in data because of lag. I'm still working this all out.

@JoWie You may have discussed this here: http://www.subspace.co/topic/25940-server-and-client-design/ . I'll check it out. @XO-MANOWAR Thanks - Go EZ's

priitK - I would love to talk with him about encryption. @Avast Phoenix SS will allow you to have the same game play you have now in SubSpace and a lot more (See the Phoenix SS - Wiki). My overall goals are to make it flexible, scalable and easy to use. So with a combination of scripting and the map editor it will be easy to construct maps with all kinds of map parts with unique properties. I am still working on the scripting aspects now but basically I envision the map editor loading a list of scripts the a user could add/delete as needed. Scripts might do things like "one way walls". Also these are not server scripts but scripts that run within Phoenix's framework allowing access to things like collision or the map engine. I am working on scripting now and I'll let everyone know more when I have something solid. - Rich -

Phoenix USC is a game 'inspired' by subspace. In many ways it will be the same as SubSpace but other ways much different. The overriding goal is to keep and enhance the game play aspects of SubSpace and combine that with "out of the box" tools, such as a map editor and other tools. As well as, adding features and graphic capabilities more inline with today's game play. In addition users will be able to define Phoenix USC to fit there needs through scripting and the map editor, allowing custom games to be made. All of this under proven game play. Phoenix SS will also be multi-platform initially available on Windows, Linux and Mac, but also available to other platforms (IOS, Android and more) over time. When I first considered starting this project I came to the conclusion that while SubSpace is still awesome trying to update it would ultimately leave me wanting. The computing and networking worlds have change quite a bit since Subspaces inception and the best approach was to write a whole new game, server, client and more. My intent is to keep this game 'free' to play. Phoenix USC will only survive through strong community involvement IMHO. Regards, Richard Betson RedEyeWare www.phoenixusc.com

@Resol "Right on man! I really want to see the video where there are other people flying around and blowing up!" So do I. But, It will be a bit before that happens. After the next release I'll start to code networking and then we can start to get some game play in. An auto zoom feature/option seems like a cool Idea. I was also thinking of adding a zoom-toggle option were you could preset 2-3 levels of zoom and hit a key to toggle through them. I would also add that screen rotation is an option and that the standard non-screen rotation is the default. I'm looking at an option to rotate the map and not the background. But I'm not sure I like it that way. On the other hand I like screen rotation so I will probably include it in the next release to get everyone's opinion. @All Phoenix SS is at about 8000+ lines of code right now and should end up at 12k-15k when finished. The version numbers for the client and editor indicate how far along I feel things are. So Alpha version .5 is about half way to beta. The distinction between Alpha and Beta is that Beta includes all of the frameworks, documentation and media to play the game, essentially the game is near completion and testing is done to find bugs or make small improvements. Alpha (where we are at now) means the game is still being defined and in flux. The next version will be Alpha .5 for both the map editor and the client. Thanks, - Rich -

Thanks, I like the rotation mode:) But, as you can see in the second half of the video standard non-rotation mode is there too. - Rich -

http://www.youtube.com/watch?v=AhObNL5dkW4 Hi, This a video of the new map I've been working on. It also shows the new background type I am working on. Recorded in 800 x 600 windowed mode. - Rich -

Hi, I think it will be possible to use a background image and have it move when the ship is moved. I am experimenting with adjusting the view-port for an image and moving it to render that portion to the background. It seems to be working great, yielding a "very pleasing" z-ordered effect when combined with the other map parts. The caveat is that using the background in such away will limit the size/area of map but I'm still experimenting. - Rich -

Hi, I've added a static background option which I think looks pretty sweet with the right backdrop. Instead of a moving tiled image background (stars), a static image is scaled up to fit the screen as a backdrop. I am looking into ways of making it a semi-static backdrop that moves slightly when the ship does. I have also made a change to screen rotation to lock the background on/off. This means if the background rotation lock is off the background will 'not' rotate, leaving the rest of the map to rotate. This may be a more pleasing way to use screen rotation for some. - Rich -

Hi, @Corey - Yes I do plan to keep it simple making a fair amount of map making simple point and click. I hope you will find it's design easy to use. In a few weeks I hope to have it available so you can let me know what you think. It will still be alpha but you will be able to layout and save a map. @Resol - I do indeed plan to have lots of features, most will be simple to use in the map editor. For example my next addition is a ship editor and then an FX editor. But I also plan to add an additional layer of features in the use of LUA scripting which should allow access to make some modifications of the game. This is something I will look into and add toward the end of alpha development. - Rich -

Map Editor: Map Editor - Parts Editor I have been working on the map editor and hopefully today will have the part editing section in place. Part editing allows you to add/change collision and other aspects of map parts like z-order, alpha, blend and more. The basic premise is you load an image (wall, floor, etc) and add collision bounding lines to it as well as z-order, alpha, blend and what-not. It should be a very easy process. Once you have the part setup you save and add to the current parts catalog. IMHO the map editor is the key to success (aside form networking) for Phoenix SS (project name), so I am trying to make it is easy to use as possible. Although I will include scripting at some point I feel that the average user should be able to build a map with little effort. The same could be said for running a server, but that's another story. I've included some pic's of the editor and the new map which is setup to play on most systems. It looks as if I will add some way to limit detail, viewing only certain parts of a map for better performance; for example an option to 'not' display the floor if your graphic card can't handle it. Off to code, - Rich - - EDIT - You might notice the grid lines on the image above. The grid system is fully adjustable to any size grid a user would need. In this case the grid was set to 128 x 128 and the parts are mostly 64 x 64 tiles. In addition the system will snap the part to the grid pattern and can be set to snap to 'x' or 'x and y'. When laying out this map I needed to place tiles at different grid patterns, mostly 32 x 32, but sometimes that needed to be changed to accommodate an accurate placement of a part. For example placing the flooring which are 128 x 128. Adjusting the grid pattern to 8x8 made for easy, accurate placement. The upshot is that the grid system is flexible enough to handle non-uniformed part sizes. Also, a user can zoom the view in and out and still be able place parts accurately via the grid system. Additionally the user can also have multiple sub-views of a map with independent scaled views , making it easy to jump to different areas of a map. - Rich -

Phoenix SS will include a windowed mode in the next release. It actually is working out quite well with the zoom feature and looks as if it will be a good option for lower performance systems as the user can lower the total display area. In addition I have also added real-time resolution change to full-screen or windowed modes. Users can also use shift+return to toggle between windowed and full-screen modes. I am also adding a "Flip" delay hack to help smooth out windowed mode and have reworked tweening (delta frame rate timing) for smooth operation below 60 fps. I have split all the map data into arrays instead of a class which has lowered overhead and up'ed performance. The map system is now based on a sector and sector parts structure where, for example,one could construct a map with a grid of 64 x 64 sectors with each sector covering a display area of 2048 pixels wide by 1024 pixels in height. Each sector holds up to 300 parts. I may add a second array to group these sector grids/chunks for very large maps, but not sure on this. I have also been reworking the map editor and getting it up to a point it can be used for map development. I have reworked the grid system to be flexible enough as well as work with the map and collision frameworks. Plus lots of other tweaks and additions. it seems to be working well and should be good enough to start making maps. I am also making new map parts and writing a small app to easily add line segment collision data to those parts. I will migrate this app into the map editor soon. I have also written another small app to import 3D "X" or "3DS" meshes of ships (or what ever) and light, image and record ship turn angles into an animated image. It actually works great and in 'rotation mode' the ship looks really cool when turning. So, I still have a few weeks of coding before the next release. I need to finish building all the parts and add collision data. Lots of little fixes and some z-order issues to solve (nothing big) and then a stability release of the client and editor. Then I will start to work on the server and client side networking. Once I hit that point Phoenix SS will be at mid alpha stage, which will be cool. So that whats going on. - Rich -

Thanks. Lot's going on right now. I am firming up the new map and collision frameworks right now. Still a lot to do here but well on the way. I am also bringing the level/map editor back into the mix and getting that roughed out enough so I can construct map. This is essential for me to accurately test collision as each part used in map construction includes collision data (line segments). So, I am making map parts at the moment. I have also added a animated image for the ship which gives the effect of it pivoting in a turn. I used a DX mesh and another language to light and image the ship so it looks pretty convincing, especially in rotating screen mode. Here is a peek at the new map parts. It will end up looking sort of like a DSB Death Star if I get it right. Construction is a breeze with the map editor even at this alpha stage. Lot's to do;) - Rich -

^That's exactly what I thought as well... lol BTW, I have successfully enable real-time resolution change. So, not only can you switch to full-screen/windowed on the fly but change resolutions as well. Ding! - Rich -

Hi, I am adding windowed mode to Phoenix SS. I now have the video drivers (DX/OpenGL) working well and will be including a windowed mode in the next release. It actually is working out quite well with the zoom feature and looks as if it will be a good option for lower performance systems as the user can lower the total display area. In addition I should/will be able to allow the user to switch to full screen mode at anytime. The only caveat might be that you have to keep the same resolution as the window, but it should also be possible to switch resolution at anytime, I am working that out right now. I am also looking at adding a menu system that will work in both windowed and full screen modes which in my humble opinion will make it a lot easier for first time users to access game functions. - Rich - Here is a pic of windowed Phoenix SS:

@Cheese Chunks, OK I like that. Three levels should not be a problem but I am going to start out at 2 I think. @All I have been working on some compatibility issues with Nvida cards. But making progress on the optimizations. I maybe dropping DX-7 support but only if it becomes necessary. - Rich -

Hi all, I am optimizing the mapping sections of code for better speed and performance. Basically the map for Phoenix SS breaks down to sectors and parts. Each sector can contain a number of parts (images and other data). So for example I could have a sector grid of 64 x 64, each sector would be 1024 pixels in width and height and hold up to 300 parts. This system would be very scalable and could render very large maps with low over head. In fact I could add additional layer and have several blocks of grids making galactic size maps. Parts are a collection of images and other data like collision. Using the editor you can place parts in any sector you would like. When you save the map the editor will sort all the parts into a sector grid as described above. BTW, I have the map editor tied back in and working, yea. I am also looking at two levels of z-order for ships to be on. For example I could have sections of the map where players travel up a ramp or over a bridge to play on a second playing field. So you might be battling it out under a bridge while other players are fighting on the bridge above you. From your point of view the bridge would be semitransparent along with the other players. So I've already got some of this coded and I thought I would see how everyone feels about this design. Now is the time to make any suggestions. On a side note I've also been working out the networking design and that's coming along well. But it will be a month or two before I have it going. The biggest issue is forming a prediction model that works well for latency. But some of the simulations are starting to gel. Edit- Here is a pic of my attempt at making map part images. I am playing with lighting here using pre-rendered part images. Soon I will have a complete part set and the walls will fit together better. = Rich =

LOL ^no sleep;)

If your on Google Plus you can find me here: https://plus.google.com/111116177023306684673/posts =Rich=

Hi, I have been discussing server client design with the community and believe I've hit upon a design that will work for this project. I am now in the process of modifying all the frameworks to accommodate the new server client design and optimizing. This will take a little time but will be worth the effort. One optimization is modifying the player and bullet classes to better manage memory which is important to networking. Right now every player bullet is its own object and this is just to overhead intensive. I am also now optimizing to include LUA scripting which will allow the user to use the methods/functions with in the game to construct levels. LUA scripting is used in many games and might be familiar to some. So the upshot here is there is some reworking of code to-do. =Rich=

Hi, OK, reading over that Unreal doc, if I'm understanding all this the servers in charge. Basically it breaks down like this *The server sends relevant data (velocity, rotation, spawn points, etc) to the client which takes that data and uses the same functions as the server to fill in the gaps in data (for example position) due to delta timing and other conditions. *The server sends data about other player/clients as needed, based on their position in the game and there priority to said client. For example if player is viewable to the receiving client. *The Client uses said data to approximate a players movement/position using the same logic/functions as the server perhaps slightly modified for better approximation and performance. *The client then updates its game state which is generally considered an approximation but accurate enough. *The client sends it's relevant data to the server which in turn updates it's game state and passes on relevant data as indicated above. This is a basic outline of how I'm understanding this. The server holds the only valid game state and the clients approximate everything based on what the server has sent them. The whole system relies on the server selectively sending out game state data based on priority and delta timing restrictions. As I'm beginning to grasp this I can really see the advantages in security and low latency. I have to say SubSpace is closer to this kind of server client scheme then I would have thought. There are some issues I can anticipate for example zooming the client view out. This would reveal possibly too many players and effect latency. Perhaps limiting zoom would be a fix. I've read over everyone's comments and some of you are very close to this type of server client scheme. So, I'm cool with this design and believe its the way to go. =Rich=

WOW, It awesome to see all the discussion here. I'm going to respond to all of this soon, there's a lot to digest. For now some of you might want to check out this link: http://udn.epicgames.com/Three/NetworkingOverview.html I've only read through a part of it but it's a very Interesting read on the game Unreal and it's server/client design. This was suggested to me by the guy who owns the company that makes my programming language. He's a smart guy and indicated this might be a way to go. Back soon, =Rich=

Cool! Looks good. L8r, =Rich=

Hi JoWie, Thank you for the thorough outline:) Originally I had planed to implement a 'specialized relay' style of server where the serve simply passes on the client data. In my case (much as you described) ship movement would be sent to the server and relayed to clients as a location (999,999) and bullets/bombs would be sent as a location plus the velocity (DX,DY) only once. I had planned to use each client to monitor collision of bullets/bombs and report any collisions pertaining to that client to the server which would in turn pass that on to other clients. This immediately brought into mind security issues with the client. As you point out SubSpaces's current client (Continuum) addressed these issues in artful ways but still, it's not ideal. It does however offload much of the computational workload onto the clients which I believe is a plus. So, this brings me back to your original suggestion of a 'thin' client and a server controlled environment whereby the server handles collision and other environmental game interactions. As we've discussed this removes most of the security issues from the client onto the server. I guess at this point I will (as suggested) workup some simulations of this kind of server scheme which is what I had planed to do. One plus is that the clients would be able to run almost any system as their doing very little calculations. This arrangement does have an appeal that I like, but may in the end not be practical. Simulations will be helpful in determining this. The idea of a billing server (account server) is interesting and along with a 'list' server would offload some of the workload from the game server. Linking several game servers to allow sever arena areas to 'out scale' also seems appealing. The networking library I'm considering using does indeed have serialization and allows me to send packets (UDP) which include Byte's, Integers, Floats or Strings. So there should be no problem in communication even across platforms. The library does not include encryption but I think this kind of library is available and can easily be included. So at this point I will have to invest some time in simulating different server and client designs to assess there viability. I really would like to design this to meet the communities needs and wants, so your input has been most valuable. Thanks, =Rich=