[web] Architecture for a MUD in Flash?
Hi,
I've been toying around with the idea of developing what I'm calling a "graphical MUD." So, it would be played within a browser. Instead of having text messages display information and the user type in commands, I would use simple graphics to represent environment, monsters, loot, etc. and the user could click on them to perform different actions. I would like to do this using Flash. However, I was over at Adobe and I've come across Flash, Flex, ColdFusion, etc. I'm new to web development, so I'm not sure how to decide which combination of these technologies I should be using.
I know I will need a a database backend to store the worlds, maps, user accounts and inventories. However, I'm not sure what to use as a server and what it would serve up to users' browsers, so I'm not sure how to start my research.
I'd appreciate any insights into how to approach this project.
Thanks!
You can do this easily, and keep the idea of mud, by using html into displaying, php on the logical part, and mysql on the database backend.
Think of it as a more advanced "kingsofchaos.com" or "darkthrone.com" game.
I had once several classes and scripts for completing one, which would be similar to a mud, by exploring rooms, and fighting, but i never did finish it.
you can start learning almost anything related to web development on www.w3schools.com.
Think of it as a more advanced "kingsofchaos.com" or "darkthrone.com" game.
I had once several classes and scripts for completing one, which would be similar to a mud, by exploring rooms, and fighting, but i never did finish it.
you can start learning almost anything related to web development on www.w3schools.com.
Sounds like you're getting in a bit over your head. Do you have (game) programming experience? Every day someone here asks about how to start a new MMORPG - while you stand out as being more reasonable in asking about a graphical MUD and suggesting you've done some research, I don't think you appreciate quite how big a task this is.
If you're new to Flash, you're going to have to set a month or two aside to learn that, to get it to a state where you're able to make a decent game with that - and that's all without even starting on the server. Alternatives to Flash might include a Java applet or a dedicated browser plugin - each also requiring a similar amount of time to get up to speed on a graphical client. You have to decide what data is sent to the players, and what format you send it in. Typically this would be a proprietary binary format of your own devising. You will have to write code in Flash/Java/whatever to decode this, and then alter the local game state accordingly. Obviously you also need to decide how to send data back to the server.
On the server side, the typical language chosen is C++, though Java will work well, as will Python, Ruby, C, C#, and many others. This program performs the game loop, processing input from each individual player, updating the world, and sending back the results. You have to write the code for sending and receiving client data here, and deciding how that affects the world. Behind all that, you will probably want a database - something like MySQL or SQLite are good choices for beginners - and will need to decide upon a database schema, and write the access code between your server and the database.
When you write a graphical MUD, or MMORPG as the new crowd call them, you have to bear in mind that you're typically writing 2 games rather than 1, and each of those covers the whole range of game development disciplines. It's a tough job. Make sure you know what you're letting yourself in for.
If you're new to Flash, you're going to have to set a month or two aside to learn that, to get it to a state where you're able to make a decent game with that - and that's all without even starting on the server. Alternatives to Flash might include a Java applet or a dedicated browser plugin - each also requiring a similar amount of time to get up to speed on a graphical client. You have to decide what data is sent to the players, and what format you send it in. Typically this would be a proprietary binary format of your own devising. You will have to write code in Flash/Java/whatever to decode this, and then alter the local game state accordingly. Obviously you also need to decide how to send data back to the server.
On the server side, the typical language chosen is C++, though Java will work well, as will Python, Ruby, C, C#, and many others. This program performs the game loop, processing input from each individual player, updating the world, and sending back the results. You have to write the code for sending and receiving client data here, and deciding how that affects the world. Behind all that, you will probably want a database - something like MySQL or SQLite are good choices for beginners - and will need to decide upon a database schema, and write the access code between your server and the database.
When you write a graphical MUD, or MMORPG as the new crowd call them, you have to bear in mind that you're typically writing 2 games rather than 1, and each of those covers the whole range of game development disciplines. It's a tough job. Make sure you know what you're letting yourself in for.
Thank you both for the pointers and the reminder about humbleness when approaching a project.
Actually, I'm interested in building the tinkeriest of tinker toys here. So, no 3D models, no particle engines, no terrain generation. Everything will be 2-D boxes and circles and labels, with some buttons on them you can click. This was actually more an investigation of web development, rather than an attempt to build a WoW killer.
I'll dive in on Flash, since that seems to be the best way into learning this. But, if you any recommendations on how to research a game server for producing the relevant Flash files (or a simpler approach, since I'm using only a fraction of Flash's capabilities), I would appreciate it.
Actually, I'm interested in building the tinkeriest of tinker toys here. So, no 3D models, no particle engines, no terrain generation. Everything will be 2-D boxes and circles and labels, with some buttons on them you can click. This was actually more an investigation of web development, rather than an attempt to build a WoW killer.
I'll dive in on Flash, since that seems to be the best way into learning this. But, if you any recommendations on how to research a game server for producing the relevant Flash files (or a simpler approach, since I'm using only a fraction of Flash's capabilities), I would appreciate it.
I was going to mention this above but didn't, but it appears I must - don't be fooled into thinking that simpler graphics makes your game a lot easier to make. It doesn't! Graphics are hard, but with modern libraries it's usually no more difficult to render a model at a given position than it is to render a 2D graphic at a given position. You still have networking, databases, input, artificial intelligence, and your 2D graphics to worry about, half of that duplicated across two programs and written in 2 different languages.
Your server application won't "produce relevant Flash files". The server application stands separate from your Flash application, and they send messages between the two to keep the Flash client in sync with the server. The fact that the client is done in Flash will have little effect on how you create the server. As long as both are capable of opening a connection to the other then the implementation at each end doesn't matter. Incidentally, don't even bother looking at web development information for your server, eg. Flex or ColdFusion, because it isn't really relevant - your server application isn't going to be a web site and the way in which you use it will be very different.
Your server application won't "produce relevant Flash files". The server application stands separate from your Flash application, and they send messages between the two to keep the Flash client in sync with the server. The fact that the client is done in Flash will have little effect on how you create the server. As long as both are capable of opening a connection to the other then the implementation at each end doesn't matter. Incidentally, don't even bother looking at web development information for your server, eg. Flex or ColdFusion, because it isn't really relevant - your server application isn't going to be a web site and the way in which you use it will be very different.
Quote:Original post by Kylotan
I was going to mention this above but didn't, but it appears I must - don't be fooled into thinking that simpler graphics makes your game a lot easier to make. It doesn't! Graphics are hard, but with modern libraries it's usually no more difficult to render a model at a given position than it is to render a 2D graphic at a given position. You still have networking, databases, input, artificial intelligence, and your 2D graphics to worry about, half of that duplicated across two programs and written in 2 different languages.
Your server application won't "produce relevant Flash files". The server application stands separate from your Flash application, and they send messages between the two to keep the Flash client in sync with the server. The fact that the client is done in Flash will have little effect on how you create the server. As long as both are capable of opening a connection to the other then the implementation at each end doesn't matter. Incidentally, don't even bother looking at web development information for your server, eg. Flex or ColdFusion, because it isn't really relevant - your server application isn't going to be a web site and the way in which you use it will be very different.
with flash it is definitly an option to write the server backend in php/asp and use the XML class in flash to load data.
to send data you can simply load a php/asp page and send the data as parameters.
i.e : http://mydomain.com/perform.php?command=walk&arg1=w etc.
retrieving data can also be done by loading a php/asp xmlpage.
its not very efficient in terms of bandwidth but its reasonably easy and should be sufficient for a small mud. (50-100 players shouldn't be a big problem).
ofcourse this would require a semi turn-based aproach where a script is executed on the server at regular intervals to manage combat, npc movement etc. (on a linux server you could use crontab to schedule updates).
the main problem with an aproach like this is that your server can't send data to the client unless the client requests said information. (thus you might need to prevent people from performing lots of actions in a short amount of time).
if you on the other hand use proper socket based communications you get alot more flexibility as to when to send and recieve data. (but its also a bit more complex).
I did this just as a test project, never really followed through with it, mostly due to the host I was using at the time didn't support java.
But I made the server in java(5.0 standard edition), and just used actionscript's built in XMLSocket to pass data between the client and the server, it was ridiculously easy. Then again I just used plain text for the commands and didn't have anything overly complex. Really no reason not to tinker with it
But I made the server in java(5.0 standard edition), and just used actionscript's built in XMLSocket to pass data between the client and the server, it was ridiculously easy. Then again I just used plain text for the commands and didn't have anything overly complex. Really no reason not to tinker with it
Quote:Original post by SimonForsman
with flash it is definitly an option to write the server backend in php/asp and use the XML class in flash to load data.
to send data you can simply load a php/asp page and send the data as parameters.
i.e : http://mydomain.com/perform.php?command=walk&arg1=w etc.
retrieving data can also be done by loading a php/asp xmlpage.
its not very efficient in terms of bandwidth but its reasonably easy and should be sufficient for a small mud. (50-100 players shouldn't be a big problem).
ofcourse this would require a semi turn-based aproach where a script is executed on the server at regular intervals to manage combat, npc movement etc. (on a linux server you could use crontab to schedule updates).
the main problem with an aproach like this is that your server can't send data to the client unless the client requests said information. (thus you might need to prevent people from performing lots of actions in a short amount of time).
In other words, you have to create a hack to ensure the system gets polled on a regular basis, and another hack to push data to the player (as they will require lots of that, if this MUD is like any other). To add insult to injury you're stuck with one of the maintenance nightmares that are the server-side scripting languages mentioned above.
It's not worth it - go with a programming language more suited to the task, and set up a long-running process as almost all other similar games do.
I agree- don't use HTTP, because it doesn't support server-push (without major hackery) and therefore it isn't terribly suitable for something like a MUD.
This doesn't mean you can't write the server in PHP, but it means you'll want to use a socket instead of HTTP, so you can't use (e.g.) Apache.
The server process will at least need to keep track of connected players and which socket belongs to whom (in addition to gameplay considerations)
Mark
This doesn't mean you can't write the server in PHP, but it means you'll want to use a socket instead of HTTP, so you can't use (e.g.) Apache.
The server process will at least need to keep track of connected players and which socket belongs to whom (in addition to gameplay considerations)
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement