What are you working on? (Game Making Thread)
- Thread starter Ellie
- Start date
Been working on the client/server stuff for battle world, at the moment I've been doing the display system for the dedicated server.
I have a good architecture for how it all fits together too, I'm making the game client as dumb as possible and the server pulling all the heavy lifting with a command system communicating for them both.
There is a Client.dll and Server.dll, the normal game is an EXE that loads up both Client.dll and Server.dll and starts a local server for single player games, a second dedicated server EXE will only load Server.dll and prepares a console for input/output (Which is non-blocking).
This is a weird design for an RPG game, I plan to make it as modular as I can so I think this is the right way to do any kind of game.
The server will hold the state for all entities, including players, and those entities can be in 5 states: Menu, Field, Battle, Over-world and Mini-game, the client will just wait for graphical information from the server and display it through the graphics engine (Which will also be modular, at the moment I am using Irrlicht, but if I keep the render path dumb enough I can make it portable to any other graphics engine and modders could potentially code their own graphics engine for displaying the game world.
I have a good architecture for how it all fits together too, I'm making the game client as dumb as possible and the server pulling all the heavy lifting with a command system communicating for them both.
There is a Client.dll and Server.dll, the normal game is an EXE that loads up both Client.dll and Server.dll and starts a local server for single player games, a second dedicated server EXE will only load Server.dll and prepares a console for input/output (Which is non-blocking).
This is a weird design for an RPG game, I plan to make it as modular as I can so I think this is the right way to do any kind of game.
The server will hold the state for all entities, including players, and those entities can be in 5 states: Menu, Field, Battle, Over-world and Mini-game, the client will just wait for graphical information from the server and display it through the graphics engine (Which will also be modular, at the moment I am using Irrlicht, but if I keep the render path dumb enough I can make it portable to any other graphics engine and modders could potentially code their own graphics engine for displaying the game world.
Well I haven't even touched my game in ages now, and since moving to a new SSD, the data for my game decided it didn't want to work and I get thrown errors for silly little things like opening the menu, only on my game though, fresh projects work fine... so it's a case of building it from the ground up, but I have zero motivation right now, guess this is another project I get really into, then quit... or I could turn it into something different, maybe use Construct 2 or something, we'll see, but for now, nothing seems to be happening.
rey meustrus
Sponsor
@Xilef: Your strategy is great for preventing cheating, but it will come at a performance penalty. Remember that when you talk about "heavy lifting" on the server, you're talking about a single system handling commands for every client. There are ways to make the "single" system actually be several, even a whole building of servers masquerading as one, but you will have unavoidable situations where many clients are interacting with each other and that interaction has to be tracked by one system. So you're going to want your server to be as lean as possible.
Besides the scaling problem, there's also a latency problem where you don't want the client to have to sit out every network hiccup before letting the player keep going. Many situations can be calculated solely by the client, and in those situations it can greatly improve performance if the client is actually running its own server functions to "predict" what the server is going to tell it to do. The idea is not that the client takes over the calculations, but that it anticipates what they should be until the server tells it. At that point the client should override what it predicted. But having the prediction avoids stuttering from the constant stream of inevitable network hiccups.
Besides the scaling problem, there's also a latency problem where you don't want the client to have to sit out every network hiccup before letting the player keep going. Many situations can be calculated solely by the client, and in those situations it can greatly improve performance if the client is actually running its own server functions to "predict" what the server is going to tell it to do. The idea is not that the client takes over the calculations, but that it anticipates what they should be until the server tells it. At that point the client should override what it predicted. But having the prediction avoids stuttering from the constant stream of inevitable network hiccups.
The biggest slowdown is updating the state of all clients to every client, what I'm doing is having the what each client can see be recorded on server based on where they are on the map, so you end up getting only field positions of those clients that are visible from you updated, I've actually done a lot of studying for client : server model in games and after making an online multiplayer FPS last year as a university project I'm confident I can get the client-side prediction working fine.
I would like to release my networking engine separately someday as a library to further develop it.
I would like to release my networking engine separately someday as a library to further develop it.
Long time no see folks. I've been busy with my school works and normal life stuff.
I found out the way to use RGSS3 in RMXP via using RMVXA's RGS301.dll and Game.exe,
(Which also requires whole RPG Module Re-Define and Tilemap Script)
And i am testing its performance and compatibility.
( I didn't made the idea, I found it on google so don't misunderstand :-/ )
I torture-tested RMXP(/w RGSS3) and found out these facts :
* All tested under 40 FPS
Emitting Particles
Man, this RGSS3's performance is brutally amazing so far. It is obvious that it's accelerated by DX7.
( In contrast, RMXP uses crappy GDI+ which isn't even a engine )
But i still need to test compatibility with scripts since i found out applying this method to previous RMXP projects
gave me a shit soup of bug and errors.
I found out the way to use RGSS3 in RMXP via using RMVXA's RGS301.dll and Game.exe,
(Which also requires whole RPG Module Re-Define and Tilemap Script)
And i am testing its performance and compatibility.
( I didn't made the idea, I found it on google so don't misunderstand :-/ )
I torture-tested RMXP(/w RGSS3) and found out these facts :
* All tested under 40 FPS
Emitting Particles
- Emit 475 Particles per second : No Lags
Emit 775 Particles per second : 15~20 Frames Drop
Emitting 475 Particles/sec in 60 FPS will cause 25~30 Frames drop
- 50 Events : No Lags
70 Events : No Lags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
170 Events : No Real Time Lags, 5~7 Frame Drop When initializing the Scene_Map
190 Events : 0~1 Frame Drops, 7~10 Frame Drop When initializing the Scene_Map
200 Events : 5~10 Frame Drops, 20~30 Frame Drop When initializing the Scene_Map
Man, this RGSS3's performance is brutally amazing so far. It is obvious that it's accelerated by DX7.
( In contrast, RMXP uses crappy GDI+ which isn't even a engine )
But i still need to test compatibility with scripts since i found out applying this method to previous RMXP projects
gave me a shit soup of bug and errors.
It would be good if someone could write up a tested experiment to show how good RGSS3 is, that might convince more people to move over.DJ":1zmhue71 said:
And GDI+ is closer to being an engine that DX7 is, DX7 is a graphics API standard with implementations for Windows as the DirectX driver, GDI+ is a graphics API for software rendering, so neither of which are engines.
On top of that, if the graphics rendering is handled in the DLL, then in theory we can write a hook to expose an OpenGL rendering path that would allow us to do some VERY fantastic effects in RPG Maker, along with an even faster render time, even multi-threading could be added.......Getting some ideas right now!
Must...Refrain from...Touching RPG Maker...
Xilef":1vxokemg said:
Didn't knew some facts that you've said. I only thought the GDI+ is such a sucker on performance.
Sadly I am not really good at programming yet to making something that can hook into that dll or something...
Ah, And i am also working on reformation of RPGXP RTP musics. I used do it before too,
But this time i am making full reforms in better quality.
Here are samples :
001-Battle01
002-Battle02
003-Battle03
004-Battle04
005-Boss01
Yeah if you have a killer CPU and a terrible GPU (Or none at all) then GDI+ could in theory be faster than hardware accelerated graphics.DJ":36cl39vs said:
Also, I just took a peak inside the RGSS301 DLL file and interestingly it doesn't touch DirectX at all for graphics, it still has GDI+ routines being called, so it looks like that RGSS301 is not actually using DirectX 7 to render, perhaps it is a requirement for audio playback or controller input methods, but it looks like there is no mention of DirectX APIs whatsoever. Or it could be that DirectX is delay-loaded, my tools are reporting that one unknown library is delay loaded.
I really want to write a wrapper DLL and start experimenting on hooking RGSS! If I could make a hooking DLL it could make it much easier (And faster) to write new Ruby modules in C.
EDIT: I woke up early this morning to code up a test DLL hooking system, I currently have a DLL in between the Game.exe and RGSS301.dll which creates a console window and forwards the calls that Game.exe makes to the normal RGSS301.dll, so this idea works, so this would be a good way to add network capabilities into RPG Maker
EDIT2: It's very cool that I am running my own code between RPG Maker's engine, at the moment I have my own file io library doing some debug logging and reading the Game.ini to get the target RGSS dll to hook with (I added a field "Hook", might rename this to Library2 or similar)
Oh, Yeah. I know that one too. And as far as i know, GDI+ can't take advantage of multi-core processors, So It depends on Clock speed.Xilef":14r4ptub said:
I once had PC with 2.4 Ghz Pentium 4 Prescott Single Core CPU, It was quite horrible to run RMXP on there.
Later i got I5 2.3 Ghz (+Turbo-boost) CPU & GeForce GTS450 GPU, But i found out that it didn't made RMXP run faster or anything.
Now I use my laptop with I7 2.3 Ghz(+Turbo-boost / Hyperthreading) Mobile CPU & GeForce GT 640M GPU, Still same.
Really? My video capture program detects it as DX7 application and acutally enables DX Capturing Functions.Xilef":14r4ptub said:
But you could be right, Since it still has horrible performance compared to other Tools that use DX9 Accelerated Graphics (ex : Construct Classic).
It would be my and everyone's pleasure if you find something out to make this thing better and easier.
The DX7 API is notably slower than DX9, so that wouldn't be explaining anything, however I once made an application that did hardware accelerated screen flipping but still used software rendering, I wouldn't be surprised if VXAce is doing this same, but I could be wrong and it could be using DX7 after all.
I updated my last post with some progress, this is all very early hackery and I might abandon this as I have other (Way more important) projects to do, in short I've got a hook between RGSS301.dll and Game.exe so it's set up to do some analysis, I might document my findings and let the next person continue with it though (RPG Maker really isn't in my interests anymore).
If someone were to document the RGSS methods/classes/functions basically any of the custom Ruby code, then I think I'd be able to write a new renderer in OpenGL, from what I can see right now it's very possible but what I'd be doing in the end is re-writing the RGSS301.dll, essentially removing the RGSS interpreter out of RPG Maker and shoving in a clean-room custom one, hey from what I've done so far it looks like we can even replace the scripting system with a totally different language like Lua or AngelScript.
Has no-one seriously investigated this before? I literally woke up at 5am, coded for 2 hours and already things look pretty simple from here on
I updated my last post with some progress, this is all very early hackery and I might abandon this as I have other (Way more important) projects to do, in short I've got a hook between RGSS301.dll and Game.exe so it's set up to do some analysis, I might document my findings and let the next person continue with it though (RPG Maker really isn't in my interests anymore).
If someone were to document the RGSS methods/classes/functions basically any of the custom Ruby code, then I think I'd be able to write a new renderer in OpenGL, from what I can see right now it's very possible but what I'd be doing in the end is re-writing the RGSS301.dll, essentially removing the RGSS interpreter out of RPG Maker and shoving in a clean-room custom one, hey from what I've done so far it looks like we can even replace the scripting system with a totally different language like Lua or AngelScript.
Has no-one seriously investigated this before? I literally woke up at 5am, coded for 2 hours and already things look pretty simple from here on
Xilef":u6tnb9q4 said:
That sounds very promising. Well still it's up to you to continue on or pass it to other.
Previously vgvgf had ARGSS project which is idea to switch the renderer to SDL,
But i didn't saw any updates for ages and it doesn't seem to usable yet.
Sadly, Most of these kind of projects don't really seem progress steadily.
Developers abandon it in middle, I think. (Not always tough.)
But changing the language doesn't really sounds nice to me, Since that quite sounds like
we have to learn that language again. However, If that grants more performance than i'd hit it.
And about OpenGL, I don't know much about it but does that grants better performance than DX9?
Just curious. (Still sounds better than GDI+ though)
I'm not going to work on this as a project, it's just some brief experiments and some ideas.
OpenGL is like DirectX, it's a graphics API for rendering, it tends to perform better if the implementation is good, it's also cross-platform so if we go nuts we can make native OS X and Linux binaries for RPG Maker games pretty easily if an open source RGSS exists.
Yeah I remember the ARGSS, I remember thinking how cool it was, now I'm looking at this stuff and thinking how easy it would be to do this, in-fact it looks like ARGSS code is out on the internet:
http://sourceforge.net/p/argss/code/HEA ... trunk/src/
If I wanted to re-write the RGSS module I'd start there (Personally I'd read the code and do a clean-room implementation, it looks like vgvf was beginning to go after fantastic features rather than a simple re-implementation).
Make it modular would be a better way too, have it so the module doesn't do everything but has hooks to let others add modules onto it.
Yeah it sounds like it would be a fun project, but a waste of time. Reading vgvf's stuff makes it look very easy, although I disagree with some of the choices he made, so I'd go for a clean-room approach and writing a squeaky-clean and simple replacement DLL before expanding it to allow additional modules to be added (Like command console, networking, Steam APIs, additional scripting languages).
The thought of being able to extend the features of RGSS is cool, we could do stuff like add a Ruby multi-threading class or mouse-input, even 3D graphics seems possible after looking at how this goes together. Oh man, shaders in RPG Maker would be awesome.
Looks like someone documented the RGSS functions (They created a replacement engine for RPG Maker in Ruby)
https://github.com/zh99998/OpenRGSS
Not to mention, trebor 777 also made an SDL Ruby RPG Maker interpreter viewtopic.php?t=15391
Good luck to anyone who attempts to take up the challenge.
OpenGL is like DirectX, it's a graphics API for rendering, it tends to perform better if the implementation is good, it's also cross-platform so if we go nuts we can make native OS X and Linux binaries for RPG Maker games pretty easily if an open source RGSS exists.
Yeah I remember the ARGSS, I remember thinking how cool it was, now I'm looking at this stuff and thinking how easy it would be to do this, in-fact it looks like ARGSS code is out on the internet:
http://sourceforge.net/p/argss/code/HEA ... trunk/src/
If I wanted to re-write the RGSS module I'd start there (Personally I'd read the code and do a clean-room implementation, it looks like vgvf was beginning to go after fantastic features rather than a simple re-implementation).
Make it modular would be a better way too, have it so the module doesn't do everything but has hooks to let others add modules onto it.
Yeah it sounds like it would be a fun project, but a waste of time. Reading vgvf's stuff makes it look very easy, although I disagree with some of the choices he made, so I'd go for a clean-room approach and writing a squeaky-clean and simple replacement DLL before expanding it to allow additional modules to be added (Like command console, networking, Steam APIs, additional scripting languages).
The thought of being able to extend the features of RGSS is cool, we could do stuff like add a Ruby multi-threading class or mouse-input, even 3D graphics seems possible after looking at how this goes together. Oh man, shaders in RPG Maker would be awesome.
Looks like someone documented the RGSS functions (They created a replacement engine for RPG Maker in Ruby)
https://github.com/zh99998/OpenRGSS
Not to mention, trebor 777 also made an SDL Ruby RPG Maker interpreter viewtopic.php?t=15391
Good luck to anyone who attempts to take up the challenge.
Xilef":24toh37d said:
I got OpenRGSS in my hands and they said "just install with rubygem : $ gem install openrgss" But i have no idea how should i do this.
I never tapped myself into a real Ruby (I only know RGSS scripts..), So i just don't know anything.. Can you give me any guide please?