next »

[OneMoreGo]

For your scale I'd ditch the database and just keep everything in memory, then serialize to disk every 30 minutes or hour.

Sounds a bit scary   An in memory table/db maybe - i'd still definately use some form of database though. If you don't then when you get to the point where you HAVE to have proper storage, then you have to write code that can normalise all your variously created data structures (that were created without thought for how they would be stored). Serialising object graphs is haaard.

[Gregg Williams]

Mono will likely run it just fine.

Quite possible, but afaik .net isn't fully supported by Mono. I think there are issues with Windows-specific features and Microsoft being patent-jerks.

If C# was a properly free language I would probably use it instead of Java, but Microsoft are huge jerks with a terrible track record.

C# is a open language. .net framework though isn't. Yeah there's some windows specific stuff that doesn't work under mono, but nothing that I know of that you would be using in a console app mmorpg server.

[Dacke]

C# is.. sort of free/standardized. The infrastructure/runtime isn't. The .Net (standard)library isn't.

Microsoft has patents that could shut down Mono if they wanted to. They have also declared themselves enemies of GNU/Linux and are notorious for being jerks about it. I don't trust them with my cross-platform needs for one second.

[Gregg Williams]

C# is.. sort of free/standardized. The infrastructure/runtime isn't. The .Net (standard)library isn't.

Microsoft has patents that could shut down Mono if they wanted to. They have also declared themselves enemies of GNU/Linux and are notorious for being jerks about it. I don't trust them with my cross-platform needs for one second.

Yeah it's true, though plenty of people have used mono for years without problem as well. Even the darling of indie devs Unity uses mono.

For your scale I'd ditch the database and just keep everything in memory, then serialize to disk every 30 minutes or hour.

Sounds a bit scary  An in memory table/db maybe - i'd still definately use some form of database though. If you don't then when you get to the point where you HAVE to have proper storage, then you have to write code that can normalise all your variously created data structures (that were created without thought for how they would be stored). Serialising object graphs is haaard.

Hmm binary serialization is easy, but yes it takes some planning, just like a proper database does. I guess your mileage may vary.

[Dacke]

Yeah it's true, though plenty of people have used mono for years without problem as well. Even the darling of indie devs Unity uses mono.

There does seem to be a lack of understanding among indies about the dangers of using proprietary platforms.

Indie darling: Microsoft XNA
Status: No longer developed and can't be forked. Only proper support for Windows 7 and lower.

Indie cross-platform darling: Adobe Flash
Status: Dropped Linux support, can't be forked
(edit: To be fair, the old Flash player still works well and Chrome has built-in Flash that works on Linux.)

[kamac]

Owh, it seems that one of my questions have been left unspotted, perhaps?

I have no expierience with setting up mySQL by yourself on windows. Is MySQL Server Community Edition fine? Or is there something more... lightweight?

[Chromanoid]

Yes, just install it with the installer.

At least for a prototype you should use some premade stuff maybe PaaS/SaaS.

Some links (relevance for you in this order):
http://www.smartfoxserver.com/
http://playerio.com/
http://cloud.exitgames.com/
http://www.scalify.com
http://www.muchdifferent.com/?page=game-unitypark-products-ulink
http://www.heroengine.com/
http://www.nettention.com

There are also some game maker kind of applications (sry no links in my favs).

Some nice open source java stuff:
Type safe database interaction:
http://www.jooq.org/
Lightweight DB especially for prototyping:
http://www.h2database.com
ORM
http://www.eclipse.org/eclipselink/
http://www.hibernate.org/
Some caches beside memcache:
http://www.jboss.org/infinispan/
http://www.hazelcast.com/
http://ehcache.org/
Networking framework especially nice for games (afaik java only):
https://code.google.com/p/kryonet/
Serialization (kryo has its own):
https://code.google.com/p/protostuff/
Non blocking network library:
http://netty.io/
Game Entity Framework:
http://gamadu.com/artemis/

Some knowledge:
http://www.gdcvault.com/play/1013848/MMO-101-Building-Disney-s
http://www.gdcvault.com/play/1013842/Scalability-for-Social-Games-YOVILLE
http://www.gdcvault.com/play/1014546/Message-Queuing-on-a-Large
http://www.erlang-factory.com/conference/ErlangUserConference2010/speakers/DavidAlmroth
http://www.bigworldtech.com/docs/2009_bigworld_ibm_server_whitepaper.pdf
http://twvideo01.ubm-us.net/o1/vault/gdcchina10/Slides/Online-CCP%20Games-kristjan%20Valur%20Jonsson-101204.pptx
http://twvideo01.ubm-us.net/o1/vault/gdceurope2011/slides/Matthias_Rudy_ProgrammingTrack_InsideTibiaArchitecture.pdf

[eigenbom]

I didn't realise you were using ActionScript. Why not code your server in Haxe then (to keep the syntax between the two similar)? Haxe has the Object<->SQL stuff and RPC to get you started.

[Chromanoid]

Ah me, too.

You should look at http://player.io for the prototype (if this thing is still running after the yahoo takeover).
Also look at least once at SmartFoxServer, it is heavily used and optimized for Flash games (AFAIR the older version supports server side action script extensions).

[doihaveto]

1) I need a prototype to be done within 11 days, then I can spend as long as I want on it
2) I should/need to learn Erlang (job), and have 17 days for that

...

And if not Erlang, then what? I could pick some language I know and all, but my main language is C++. It's tough to code a server with C++, and I have to make it work for linux and windows ...

Here's what I would do if I were you:

1. Start with an existing game server, and get the "basic game" standing up like that, which should take much less than 11 days. SmartFox Server is good enough for prototyping (http://www.smartfoxserver.com/products/sfsPro). The advantage is that an existing game server will already have implemented things like socket connections, user login, a model of "rooms" where people can move, etc. - and you implement your own game logic on top of that. If you go with SFS, those game logic extensions can be written in Java, Python, and something resembling Actionscript.

2. Once you have a working game server you can fall back on, you can consider rewriting one yourself. I'm not sure you'll have to (it might be easier to just stick to SFS). But if you do, pick a language with automatic memory management, and safety features like array bounds checking. Just please don't do it in C++. Debugging memory-corruption-related crashes in a server environment is really not fun.

I would personally write one in Java, because I know it well, using the Netty networking library (very high perf) for the networking bits. But really any high level language will work...

I have no expierience with setting up mySQL by yourself on windows. Is MySQL Server Community Edition fine? Or is there something more... lightweight?

As far as SQL databases go, MySQL is pretty lightweight!   The Windows edition of MySQL is actually quite good, just get the official installer, and have it set up everything for you. There should be GUI manager that comes with it, which you can use to set up tables etc.

How about it?

[Gregg Williams]

2. Once you have a working game server you can fall back on, you can consider rewriting one yourself. I'm not sure you'll have to (it might be easier to just stick to SFS). But if you do, pick a language with automatic memory management, and safety features like array bounds checking. Just please don't do it in C++. Debugging memory-corruption-related crashes in a server environment is really not fun.

I would second this. I'm doing a scalable architecture in M.I.N.T currently and am doing it in C/C++ and its a pain. I really wish I could have used something like .NET for it, but I wanted to avoid having to duplicate tons of logic into two different languages, and I wanted to be able to have a thin client for SP. Thus since the client is being done in C/C++ so is the server. Or at least the game server portion, logic servers, and other junk the SP portion of the game doesn't need to care about might get done in a different language.

[kamac]

I didn't realise you were using ActionScript. Why not code your server in Haxe then (to keep the syntax between the two similar)? Haxe has the Object<->SQL stuff and RPC to get you started.

I find AIR quite good, and I am using starling with it (hardware acceleration). Also, I need to learn AIR for that coming-up job of mine, so I thought that this might be another good opportunity.

doihaveto, but I've already decided that I would code it within Go.. Same goes for Gregg, I am not coding server in C++.

Also, SFS is no way out - what if I find myself not capable of writing server from scratch? Will I just leave what I did? Their licenses appear dumb to me - pay for how many users are connected. Jesus.

SmartFoxServer Basic
100 users - €200.00
500 users - €400.00
Unlimited - €800.00

I'm not going to pay that €200.00 if I decide to stick with SFS, since I simply cannot afford it.

[CowBoyDan]

My advice, for a first pass do all your communication via http using json to transfer data.  Have the client post updates or poll every 1/3 to 1/6 of a second.  Not ideal, but it will get you to a playable game a lot faster.  You can always swap out http for a socket level communication later (main draw back of using http is you have to make a request to the server to get data, it can't just push updates to you, but hey, it works for google docs even with a dozen people editing a doc at once)

You can write your "server" in anything you want, I would pick something that is quick and easy to connect to a db and handle web request (you will be using post style request)

For a really dirty quick first pass you could write your server in php (a lamp stack is super easy on linux) and store all your data in the db (you won't be able to keep anything in memory between request).  You could use an in memory db as persistent memory behind php for instance.  In general I don't advocate php as a programming language, but it gets you from web request to db in a dozen lines of code, and if all you are doing is storing the users current requested action and returning an a status (their health, what they see, etc) it wouldn't be too bad.

Regardless of language choice, you could design your "world logic" to operate outside of the game/web server and connect almost as a player would, in this way the software that the user is making request to only keeps track of state, and all actions (actually moving, attacking, etc) would be triggered from a monitoring process.  To help make sense of this, when a player sends the message "move right" you dont move the player right, you store that the player wants to move right, then when the world logic loop hits it will move the player right.  You can treat the world logic as a regular game loop.

Mysql is an ok choice, personally I like postgresql

                    [in-memory-db or cache]
                           ^
                           |
[players] --------->  [game-web-server]  ------> [db]
                            ^
                            |
                     [world-logic-program]

OR the world-logic-program could talk directly to the in-memory-db or cache

so players post/poll game-web-server giving their current input/commands and it returns the current world state, the world logic program (ie game loop) polls the memory/cache and does its game loop stuff.  Each piece is loosely coupled and can be swapped out for something better when needed.

[mychii]

Okay, desktop game, Flash. I'll make it simple for you, is it turn based game, or real-time action (like FPS/action RPG)?

Turn based game:
You can use HTTP based connection. Its slower (~64 - 300 ms) response, but it is definitely not a problem for turn based game. You can use PHP, Node.js, Java, whatever web framework are available around.

Real-time action game:
You have to use TCP/IP socket, which you must NOT use HTTP. I suggest Java/C++ with TCP socket as your server in this case. The speed varies and starts from ~7 ms depends on the location. This is what you need when Players have to hit their enemies instantly. This one is far harder than above, but there are libraries/tutorials available to make TCP connection between Flash to TCP-able servers.

Both still require 4 servers if you have a server scaling in mind of your architecture: Socket(if TCP)/web (if HTTP) server, cache server (optional), database server, and game server. It can be in one real server if you're just doing a prototype.
You probably need one more as CDN to deliver your asset bundles as the asset grows, but it is completely optional because you're doing a prototype, player simply stream/download the client-side program.

In case you're wondering:
Socket/web server: handle traffic. This is the one who'll tell that the server is either full or not.
cache server (optional): handle traffic as well (if you know PHP, this is the replacement of its internal-session management). I don't think it is actually required for games because usually game is not stateless, unless you're doing turn based game like Mafia Wars.
Game server: Of course, the one that handles the game; monster spawn timer, AI, players in a map, etc.
Database server: Where all long-life data stored; position of players, player items, monster list for client-side sync, etc.
CDN server: Where all your assets are placed where the user can update. (You know, when you play MMORPG, the one that usually loads new updates on their launcher).

When you do this, and your prototype is ready, it's very easy to scale. By the way, you need load balancer when servers are more than one for each.

About the database selection, let me give you a clue. Use RDBMS (MySQL, MS-SQL, etc.) when you need persistent/sensitive data that you're able to track. This is usually account ID, credit cards, and more. If you don't care what's inside the data and you depend on queries instead of individual data, use NoSQL (like MongoDB). This is usually chat, battle log, etc.
Those who already in the market uses both or only RDBMS (because they're so old I guess..).

[kamac]

Those might be good advices, but I have no time to get into them now. Trying to get a proper grasp of Go now - which, by the way, doesn't come in easy. There are nearly 0 examples on the internet about specific, basic things (you won't find them on their site - no way). To learn it's functions I must crawl around their package reference, which is taking quite a lot of time.

@EDIT

As of now, this topic has 1024 views. Celebrate.

[Dacke]

If you're struggling with Go just use something else. You'll still get done faster if you use something you feel comfortable with. Personally I found Go very easy to learn, but since it's a relatively new language examples are pretty scarce.

[kamac]

I've got what I wanted already
It takes time, but in the end it turns out to be easy.

[eigenbom]

hey kamac, I'd be quite interested in what you ended up using (packages, serialisation method, etc), once you get it all working.

[kamac]

If I get it all working

For now I am building up the logging in system with Go. Almost done. (though, I support multiple characters per account, so it's not that easy)

[Dacke]

You can add multiple character support later. You need to keep things simple if you're going to make it in time.

simplify, man