RPG Maker MV MMO Dev Kit

[Ellie]

I intend to make some scripts for RPG Maker MV when it comes out. I'll be making a game with them, but I want to also publish them to the community for folks to use. I would appreciate some input and suggestions if you have any.

Basically it is the MV version of Netplay+, although it will be a much more polished, but basic, system. It will be more like a kit than a game - you'll use systems in it however you need to in your game.

I know that this is a big promise to make. As this shall form the basis of my own game though, know that if I fail, my game fails too.

Some caveats:

- There will not be live player sprites on the screen. This is very resource intensive.
- This will not be a full MMORPG system in many people's eyes.
- You will need to be willing to learn a little bit of PHP and Javascript.

This system is based on the proven backbone of Afar, which, like it or not, has been online for the past five years and basically works.

Current planned features
Subject to change

• Login and register system (secure, encrypted)
• Server-stored save file
• SimPvP Combat: play an AI controlled version of any real player
• Co-operative events
• In-game chat, powered by IRC (may not be possible, depending on the engine)
-> if not, general in-game chat
• In-game bulletin boards / forums / messaging system
• Wiki-based online manual within the game
• Social media integration
• NPC renditions of real players: though you won't see a player's movements live, you will still see them roaming the map they are in, and you will be able to interact with them: message them, fight them (sim)
• Auction house system
• Automatic game updates

All of this is doable in RPG Maker XP, with a lot of work. I have the system working. RPG Maker MV however will make it easier, faster, and more secure. It's almost built for online gaming.

 

[Ellie]

Thinking about it, a lot of it is going to end up being tutorial based, not script based. Some concepts, such as co-operative events, require more of an explanation than handing it out ready made (because I'm not here to make your game for you, and every game needs to be different!)

So some of this will take the form of a detailed explanation of how to create and use global switches and variables, and how these can form multiplayer elements.

There is an element of risk with this: some processing will be server-side, some will be client-side. The client-side is hackable. You will not be able to create a truly secure MMORPG with RPG Maker. You can however eliminate a lot of problems and then live with the fact that it will be possible to cheat with some effort, in the same way you can with any RPG Maker game. But not entirely, as a lot of processing is done server-side.

 

[Desecration]

I think this is a pretty great idea, glad to see somebody else looking into doing this with MV. Especially somebody with so much previous experience in online game development. I'm quite curious as to why you think that having other player sprites on the screen would be too resource intensive? I don't see it being that much of an issue. Also surely you could develop an authoritative server and use that to validate anything the client sends across and reduce the possibility for hacking?

I'll be keeping an eye on this to see how you get on. Good luck with it

 

[Ellie]

Thanks.

I could do everything server side, but I feel like at that point it shouldn't use RPG Maker, and I would be making people's games for them.

Player sprites is resource intensive because each individual player has to keep sending and receiving their coordinates, which change very often. The software then has to account for the delay and work out their paths and such.

 

[Desecration]

Yeah that's a fair comment, I guess if somebody really wanted to go to that much trouble to hack something they'd probably figure a way out to do it regardless.

On the topic of player sprites being resource intensive I don't think its that much extra information to send and receive assuming you chose the basic approach of storing a player's X and Y coordinates that would only be an extra 8 bytes to send and receive per player (not accounting for any buffer data). This wouldn't need to be sent every frame either, it would only need to be sent when the position is updated. As for calculating paths that might be a little bit more resource intense as you say but I'm not sure it would be significant.

 

[Marked]

On the topic of player sprites being resource intensive I don't think its that much extra information to send and receive assuming you chose the basic approach of storing a player's X and Y coordinates that would only be an extra 8 bytes to send and receive per player (not accounting for any buffer data). This wouldn't need to be sent every frame either, it would only need to be sent when the position is updated. As for calculating paths that might be a little bit more resource intense as you say but I'm not sure it would be significant.

It certainly isn't about the size of the data being sent/received, it's about how resource intensive it is to send and receive each time. I think you're right in that it needs to be triggered when something changes. Because the other option is to send a request and receive a return basically every second, and that would be extremely resource intensive, especially if more and more users are active on the screen.

Since hearing that MV will JS and be portable to HTML5, I have been thinking about creating a system similar to this as well. Not so much a dev kit for distribution, but as a personal project. My original thinking is for the game to run in the browser through HTML5 where it can use a local connection to a MySQL database. The trouble with remote DB connections is that they are slow, especially on a shared server. But the thing with browser based games is that you have download it each time. I think most of these types of games just have users download the files locally, then connect to a datasource?

I'm also thinking that web sockets could be utilized for sending and receiving data. Pusher (https://pusher.com/) can be used for free to a certain limit, so that would be good for testing.

 

[Desecration]

I mean sending and receiving packets isn't particularly resource intensive, at least not from what I've seen in my (limited) networking experience. There would definitely be ways to optimize the data sent and received, this is a topic that has been pretty heavily covered over the years so there are a lot of techniques that could be used to maximize efficiency. Assuming that there is a maximum number of players per map you could in theory know the absolute most data being handled for players and then work out the other performance issues from there.

I think the issue with using a local database is that it leaves it open to manipulation far more easily than a remote one, it would also be a significant overhead for each player to have to download the game database. Remote connections may not be the fastest but this again is something that can be optimized, having the server handle saving/loading to/from the database would be one way to minimize problems. As far as my understanding goes most games of this nature use a centralized database that the server is connected to and issue commands to it from the that, rather than from the client.

Web sockets would definitely be required although which specific library being used would depend totally on which suits the needs of the system architecture best.

 

[Ellie]

The issue I have is that all my plans thus far have been based on Ajax, not sockets. It would mean building a separate server system just to run player coordinates. That poses a few problems - one of them being from a game maker's perspective: many web hosts out there won't allow that type of server to be run - but will allow Ajax and HTML5 games. (It's a grey area.) That adds costs.

Ajax is a state based system. You send a request to the server and get a response back, and build your game's state from there. (That's basically what I do in Afar, but I hadn't learned how to Ajax at that point).

Player coordinates however require the server to act on its own, without the client requesting things - the server sees that a player has moved and sends out its coordinates to all players. That would require a different system to the PHP/Ajax based one I've been using unfortunately.

But maybe that's a hint that I'm using the wrong system!

 

[Desecration]

Yeah I may have been slightly off when I was reading the first post, I had assumed that sockets would be used and there'd be a constant stream of data between client and server rather than state based events triggering data transfer. I see what you mean with the web hosts having issue with that type of server running, fortunately you can rent an Amazon EC2 box for very little cost which would be more than capable of running something like this without issue. (EC2 boxes being my first suggestion because I've used them in the past, there are many more services that provide the same capabilities)

Are you planning on doing this development as part of a community project Wyatt or are you planning on keeping it as a personal project? I'd be quite interested to see if something like this could be developed in true open-source fashion by the community.

 

[Ellie]

I am making a game, and then will release each bit to the public as soon as that bit is working.

A lot of it will be tutorial/explanation rather than plug and play though.

 

[Marked]

I hope you keep us updated in this topic. We are both going to attempt to do the same thing, perhaps down the track there is room to collaborate. I am an experienced web developer and have built applications with web sockets before, but I'm not sure what to expect with MV and how easy it's going to be achieve what we're trying to achieve. I am currently researching the best frameworks to utilize for this. I have already found a nice little tutorial on multi-player games using websockets to update coordinates and keeping resources low. Now just gotta wait 'till release day :biggrin:

 

[Ellie]

Just to be a little vague and over the top, HTML5/JS is the engine that RuneScape is now played in. Everything is possible.

 

[Marked]

Yeah, I don't think we should get bogged down in the suitably of JS/HTML5 for games. Especially a 2D RPG. I've just a look inside MV and the JS and I'm slightly excited, mainly because it's basically an advanced front-end website, the whole thing. To me that means flexibility, and I'm already familiar with this sort of code. I'm uploading now to my server to see if the HTML5 app runs :biggrin: But it's 340MB without adding anything.

EDIT: here's my HTML5 MV test http://gdunlimited.net/mvtest/

 

[Ellie]

218mb of that is graphics - easily replaced. Another 175mb is audio - again, easily replaced.

 

[Inukinator]

I was thinking, a way to make this work is to use php to generate a json file from mysql queries, and then display them in plain text, which the client then reads, and have another php file that recieve post data from javascript which then is used to post the data in the mysql table.

 

[Ellie]

That's essentially what Ajax does - it's a way of javascript sending a request to a PHP file with GET or POST variables and then getting plain text back.

The way I have set it up, you call a function like:

var x = ajax('action', 'PARAMETERS');

and x is then set to what the server sends back, in plain text.

For example an action might be "get_player_name".

var player_name = ajax('get_player_name', 'player_id=4');

and player_name would be set to whatever http://url/action.php?action=get_player_name&player_id=4 would return.

Everything is then based on this simple system. File server end you have a file called action.php which looks like this loosely:

// action.php



switch($_GET['action'])

{

  case 'get_player_name':

    $user_id = clean($_GET['player_id'], 'int'); // YOU MUST CLEAN ALL $_GET DATA BEFORE USING

    // IF YOU DO NOT KNOW HOW OR WHY, YOU NEED TO READ UP ON PHP SECURITY

    // I WILL PROVIDE SOME TUTORIALS

    $return_string = get_player_name($user_id);

    echo $return_string;

    break;

  case 'other_action':

    break;

}

 

[Ellie]

Taken from rm web:

Perhaps this question just shows a failure of my limited imagination, but what functionality does going multiplayer add if the other players aren't updated and interacted with in real time? What is the purpose of having them in-game at all if interactions are "ghosted"?

There's tons you can do multiplayer without necessarily seeing the other players live. Some functions I plan to create:

Trading

- Player to player trading: you send them a request, they send it back with their offer, you accept or decline
- Global auction house (similar to Grand Exchange in RuneScape or Black Lion Trading Company in Guild Wars)

Communication

- Chat
- Private messaging and other communication

Co-operatively created world

- Enemy unit sizes and town occupation based on what the average player is doing
- Quests open up if people are generally "winning" against certain monster groupings
- Gates and battle objectives that requre a set number of global wins to break through (say 1,000 people need to beat x monster)

Simulation

- Player vs Simulated Player battles (you fight an AI, but the AI gets the player's stats and traits from the global database)
- NPCs that are based on actual players and discuss their actions and achievements in an NPCey kind of context

Leaderboards

- Player stats compared against one another
- Competitions

Multi-user dungeons

Just because you can't see the other player live doesn't mean they can't co-operate with you in a dungeon. This will be a tough one to work out, mind, but I think it can be done.

Guilds/Groups

- Multi-user guilds and groups with their own leaderboards, chat systems, goals and guild houses

 

[Marked]

So you don't plan to show other players updated in real time?

 

[Inukinator]

A way to do the mud element, without seeing eachother live, is to make it so when one has completed a quest, another quest is opened for another player? or shared items, and when one door is opened in the party, that exact door is opened for everyone else!

 

[Ellie]

Makes sense. Would be quite easy to do, too - having events and switches that aren't local, but aren't global either - but are unique to a party or guild.