Vidiot_X

12-20-2010 I tried to make a video for above, but the background fx are just not coming through. So I will post a new client release (I wanted to wait for collision) in a day or two. The level editor now also supports the zoom feature. This so rocks for editing a map. This coupled with multiple sub views (each with independent zoom) should make editing large world/maps a breeze. The multilayer-ed backgrounds are forcing me to consider (they really tax some video cards) lower resolutions then 1280 x 720. Since they are not 16:9 but 4:3 I am adding scaling that will support these lower resolution so they display right. Look for in this next release. On separate note I have been invited to become a beat tester for the language (BlitMAX/BRL) I currently use. They are developing a new language that will really expand the options for this project. Also having the inside support and access is a big plus. I can not comment on the new language but you all know that. Look for the client update with Zoom and Multilayer-ed backgrounds.

The large version rocks. I like the ship flying over the ground with clouds. I am designing Phoenix SS to be able to support something just like that. Taking the game from just space to the surface of a planet and space. So it's cool to see that. I have after reliability and quality have envisioned a system that can scale well. Take adding zoom to the map view. The "back end" of Phoenix SS is a collection of engines that support the applications (client,server,level editor). So when I add a feature to these engines they become available to all of the other applications. The zoom feature carries right through to the level editor, which is way cool. My point is that starting on footing of scalability really opens up the possibilities for this project and your animation got me thinking of some that think SubSpace should be locked in space. -end rant lol Any way I love to see this kind of stuff. Thanks. Richard R Betson aka. Vidiot_X

Very cool! I really have not thought much about this. SubSpace's scrolling intro is dated and "Flat". Some interesting ideas there. Giving the large version a look now.

12-19-210 I have added multiple background layers. Phoenix SS is now able to display the background tiled images (stars and alike) in multiple Z-ordered layers. This means you can have each layer moving at different speeds and alpha transparency's. This renders a really cool parallaxing (depth) background. This is in addition to other layers of objects like the sun, planets and wall/floor's. It's really starting to look pretty cool. Generally you won't be able to get to cray with the background layers as they tax the video card, but you should be able to use at least 2-3 on most maps. I have updated the level editor so all you have to do is place a background image in an empty part of the map. It is then automatically rendered as a background layer. I'll try to post a video clip of it soon. I do not plan to release another update until I have collision firmly in place (coming very soon) so enjoy the video clips of Phoenix SS's progress for now. Richard Betson Aka. Vidiot_X

12-15-2010 Here is a little video clip of the new zoom feature. http://www.youtube.com/watch?v=STlep9edyuU

Hello all, I have decided to start a work log on this project. For now I will keep it casual. 12-14-2010 Since the last release of the client (A.25d) I have been working on world scaling. This is a feature I had long wanted in SubSpace. So I now have map scaling in, just like zooming in or out (*In Real Time). I totally love it. Just imagine being able to zoom out for that wide field of view. So I am going through all my code now adjusting for world scale incorporation. I had always planned to do this but I still have a few bugs to fix during this change. Another reason to include world scaling is special FX. I would like have multiple planes of play. For example a ramp for jumping or a bridge. Alpha (transparency) will allow me to create areas of the map where multiple planes of play are occurring at the same point (x,y) on the map. Should be way cool. More to follow... Richard Betson aka. Vidiot_X

"While it's good to keep security in mind, don't try to do too much at once." Right on. Laying out your server/client scheme is the first step. This alone when done correctly can reduce hacking and cheating. Structure, Low data rate and and over all networking quality are my current quest. I am doing quite a bit of research on these, which is another first step. Yes; I have an object oriented model. Everything is pretty much an object from the map to the player. Even the "Bullets/Ordinance" all are separate objects. It does make it very easy to network and deal with security issues. Richard Betson aka. Vidiot_X

Right on, Follow this thread: http://www.blitzmax.com/Community/posts.php?topic=92828 Most of the networking packages I'm looking at take care of this sorta thing (malformed packets if I get you right) including security/flood and alike. I am looking hard a Raknet which is widely used and solid, but hard to code with. The cool part is as long as the game is "free use" ( FMOD License ) it supports voice over IP which would totally rock in a SubSpace style game. I want this! Richard Betson aka. Vidiot_X

I am totally with you on this... Hacking is one of those things you will have to deal with on an on-going-basis. Take satellite TV. First for C-Band they came out with videocipher 1 (encryption) which no one could break. They hacked it. Then Videocipher 2. They hacked it. The same for Dish and DirectTV, and these guys are huge. Lots of R&D cash. Even Sony after spending millions on coming up with a way to prevent copying audio CD's found it self hacked. The hack was carefully taking an ink pen and blacking out the most outer track. Millions of dollars in R&D thwarted by an ink pen. It will make you laugh. My point is I intend to make the system as secure as possible; but it will be hacked. Once I have good security scheme in place I will put it out there and see what happens. This why it's good to have as long a beta testing period as you can. By simply having it out there hackers can't resist (well most). I am not up to specs on the best approach to provide security within this game. The good news is that I have access to those who know all about this kind of thing. I have done a little research into SupSpace's history and I am aware of the security issues of the past. But as I recall the system was not very secure to begin with. There is nothing more annoying then someone blasting with unlimited thor's. Be assured that I am prepared for the security issues that will arise, squash them and move on. In fact I am looking at this now in the way the client and server will work together. Determining how much control the client will have. For example even though the client is assigned a ship with a particular weapon, they are not active until the sever sends a release code (encrypted) each time the ship is spawned. Meaning every time your ship is destroyed, your weapons are dead until verified and then sent a release code. If your client is somehow hacked and is trying to use a weapon outside your class or exceeds your class limits your banned. In the case of specials like thor's similar constraints are put into place. This is just one example, but I hope you can see that already thing about it. Richard Betson aka. Vidiot_X

Interesting, I have not decided yet on which approach to take on map scripting. Many professional games use LUA (http://www.lua.org/about.html) which basically allows me to "hook into" the functions within my own code. It also allows data to be passed to and from the script. This would enable a very robust scripting language allowing the user a great deal of control and flexibility. But, on the other hand I have to consider security. We would not want others to change the map, in an effort to cheat on the client side. So maybe I'll have the option to save from the level editor a script version and then also a publish version that will be encrypted. In today's world of protected memory this might be overkill, But in my mind security is important. It's cool though to see some script that everyone might be used to already as a base for the future. I tend to take on these issues as I need to deal with them. So it will be a little while before I actually deal with standardizing a scripting language. But It's good to have a discussion about it now, as well as security issues. Richard Betson aka.Vidiot_X

Cool, For now you can add parts to the level editor by editing (use notepad or such) this file: parts1.lst It's a little tricky but all you really need to do is copy the last 5 lines in the file and add them to the end. The last 5 lines will look like this: floor5.png Pipe Floor 2 0.8 3 0 and what they mean: ------------------ File name of image: floor5.png Field name of image: Pipe Floor 2 Alpha or Transparency: 0.8 Blend Style Number: 3 Z-Order or Layer order: 0 Settings/ranges --------------- Field name of image: Needs to be unique. Different from the other parts. Alpha range: 0.0 - 1.0 Blend : 3= Masked Blend (keep this set to 3) Z-Order: Use 0 (zero) for floor and 210 for walls So just copy the last 5 lines and add the them to the end (no empty lines between). You do this for as many parts as you need. Try to keep the map parts at 128 x 128 pixels or smaller. This may mean breaking up larger images into smaller pieces. If this is not clear just let me know. I'll see what I can do in the short term to make this easier, but it won't be long before I add collision and then the level editor will take care of this for you. Richard Betson aka. Vidiot_X

I'm assuming your talking about the player/ship slightly moving off center. You can adjust the offset in this file (for the ship/player): swift.dyn Change the field "elas_bounce#=8.8" to 1.1 . Don't go below 1.0 or your screen will wildly move back and forth. This should keep the player/ship pretty much dead center. Within this file and "bullet.dyn" you can make other changes to speed, gravity and more. So go ahead a play with these settings and see what you can do. You should probably make a copy of the original files before attempting. As to graphics, there a little rough but I'm hoping that as development continues myself and others will come up with some "Bitch'n" graphics. "overall, astounding progress. thumbs up! " Thanks! Richard Betson aka. Vidiot_X

It's Finally Here! This is really a client/server but I have disabled all the net code for now. I am reworking this. The game client uses all of the systems engines with the exception of collision, which is disabled while I work on the level editor. Each of the bullets are independently controlled by the physics engine. This means when collision is enabled each bullet will bounce off objects with full physics control (friction, speed, etc ). Some other features not seen but in place are camera shake; the screen shakes when you ship hits an object. Simple listener server and client networking code. Effects like repel and bombs. And more... You should be able to use the Phoenix SS level editor to create new maps and run them in this client. See the readme html about this. Be sure to report issues to the forum link listed above and not my email. I expect to have a networking version out within 90 days of this release. Check out my web site for pics: http://redeyeware.zxq.net/ Richard Betson SubSpace Nick: Vidiot_XPhoenix_ss_client_alpha_25d.zip

Attached is the latest version of the Phoenix SS level editor. Improvements made to stability and compatibility with it's client. You can now run the levels you create in the client posted in this forum. Richard Betson aka. Vidiot_X Phoenix_Level_Editor_Alpha3.zip

That jump is in the video capture process and possibly net delay. I have timing code in place that handles lag (frame drop) by keeping track of how many frames have dropped and then updates the physics, collision and map engines to account for the frame loss. Be assured that all will run smoothly. Richard Betson aka. Vidiot_X

Yes! Humming right along. Richard Betson aka. Vidiot_X

Essentially every object will be independent; meaning that you will be able to assign a value 0.0 - 1.0 that will let you adjust that objects rate of movement. Even the background (which is a 512 x 512 image tiled) will have an independent rate of movement. This will allow as many layers of movement you need as well as layers of depth (Z-Order). It will be cool to see what maps get created with all the cool parallax'ing . @All ===== I have posted a higher resolution video above. Still getting used to all of this video encoding stuff. <_< Go to to video link above to see the new video. Thanks Richard Betson aka. Vidiot_X

**** New Higher Resolution Video Now **** ***************************************** Here is a video of the Phoenix SS client/server in action.: http://www.youtube.com/watch?v=WH_hkTN7RL4 ^Right click on video and select Watch on YouTube for full screen. Full Screen image of the game here: http://redeyeware.zxq.net/Pheonix_SS_Client_Server_Alpha%203.html This video shows off the inertia physics (movement) as well as networking performance and map engine performance. There are two ships in this video a "client ship" and a "server ship". The client ship is the one that will actually get the screen scrolling. The Phoenix SS client/server, are in one application for now that can be either run as server or a client. But this may change in the future, breaking out the server into it's own application. One interesting note is that the frame rate (FPS) and networking timing code are working great. I was blown away that I could have the client running at half the frame rate (during video capture of client) of the server and still be able to smoothly play. The video capture about halved the performance of the client but the timing code handled it great. <_< Also threw in some original music to liven the demo up. Check it out! Richard Betson aka. Vidiot_X

@jabjabjab "what is the logo going to look like? " I was just discussing this today. I have know Idea. But, it sounds like you might. <_< I am going to need some help on game art work at some point, so I'll look you up then. But I do need a logo, especially for a web site. @All Look for a "topic" with a link to a video of the game client/server in action. Should be up tonight. Uploading right now. Richard Betson aka.Vidiot_X

Purge, Well I'll be. I will take care to responsibly moderate and manage this forum. If I can I'll have a copy of the client/server (no collision) out tomorrow in celebration. What a nice surprise. Thnaks. Richard Betson aka. Vidiot_X

Here is the latest image of the game client/server. http://redeyeware.zxq.net/Pheonix_SS_Client_Server_Alpha%203.html Now starting to get a parallax effect with all the layers moving. Alpha blending is working nicely. L8r, Richard Betson aka. Vidiot_X

Btw: I am sure most of you have used the arrow keys to move around the map, but I don't think I spelled that out in the doc. I'll add it up top.

@Bak Although off topic, Most of the source code is proprietary and as such has future use and value to me. In my experience is it is best to "license" a project then to "Gift" a project. The physics, collision and map engines are useful for other commercial projects so this requires retaining ownership. Licensing a project has the appeal of retaining control/ownership and providing a project like the above free long term support. I can then release the source code with it's license conditions and restrictions in place. By reading your comments here and reviewing your web page I would guess your a supporter of "open source code". I am as well; but I have to consider the options for this project and future projects based on my professional assessment. So, this (and other reasons) is why I prefer to delay release of source code. Hang in there @Cheese, Don't sweat it I've been programing long enough to know what to expect. L8r, Richard Betson aka. Vidiot_X

I am using BlitzMAX (www.blitzmax.com) which is a C++ friendly development language. It is an OOP style language. It is very useful for rapid development. I plan to release the source code at some time. For now I feel it best to keep it under control until near final / final release. I do not expect many will be coding in BlitzMAX anyway, but I am open to further discussion. @All Client/Server test should begin sometime next month (Dec). At that time the editor will be able to function fully enough to create parts and collision information. You be able to make a map and then run it in the client/serve application as well as limited online play. The basic framework of the game systems (networking, physics and other engines) will be in place. Once I have a working game system (level editor and client/server) I would like to discuss what to do with it. My goal is to remake SubSpace. Keep the good and add to it. I am fairly sure most of you don't know me, which is why I am kind-of waiting until I have a working game system before I ask everyone to get involved. I am sure some of you have seen others developing, come and go. So I would like to impress upon you my seriousness by delivering "the goods". Anyway... Quentsions on the editor? L8r, Richard Betson aka. Vidiot_X

New game client/server image. Now starting to get a parallax effect with all the layers moving. Alpha blending is working nicely. Here: http://redeyeware.zxq.net/Pheonix_SS_Client_Server_Alpha%203.html Release: Phoenix SS (working name) Level Editor Alpha.3 (Windows only) I have attached a copy of the level editor in this thread. More information about the editor can be found here: http://forums.ssgn.net/index.php?showtopic=25083 All you need to do is follow the instructions in the help.html file. You can also just unzip the zip file and run the exe file. The help file is displayed when the editor runs. This should give you an idea of what I am up to. Please remember this is just the rough outline. Let me know what you think of it. BTW: Use the "ARROW" Keys to move around the map. Forgot to mention that in the doc. Richard R Betson aka. Vidiot_X