Announcement from AWS: Their own game engine

[Baaleos]

https://aws.amazon.com/blogs/aws/lumberyard-amazon-gamelift-twitch-for-games-on-aws/

Amazon has released their own Game Engine leveraging their AWS cloud services for 'supposedly' enhanced MMO possibilities.

The software to create games is Free, with no limitation (besides some licensing terms around redistribution of the engine source code)
You don't even have to use AWS to play or create the games.

I am going to be trying this out.

If its easy enough to use, a City of Heroes clone in the cloud would be nice.

[nicoliy]

Oh how I wish I had gone into game development instead of the finance world. This looks like fun to toy with (I don't believe I have the skills to one-man make a game though). Should be cool to see what people come up with.

[Codewalker]

It's not targeted at MMOs. From the description, the server component is for:

"You can use it to host many different types of shared, connected, regularly-synchronized games including first-person shooters, survival &  sandbox games, racing games, sports games, and MOBA (multiplayer Online Battlefield Arena) games."

i.e. things that feature a large number of independent gaming sessions with small groups that do not need to interact with each other, except possibly to update a leaderboard afterward. Which makes sense, because the AWS architecture is massively parallel and based on "best effort" replication that is not necessarily always up to date. It's designed for that sort of thing, not for a persistent shared-world MMO that needs to be completely synchronized between all players at all times.

[Baaleos]

Given that it has only been released today, I'd say its full limitations have not been properly explored by the community.
Gaming communities and developers often find unique creative ways to use game engines in ways that were not advertised.

Amazon would be shooting themselves in the foot if they made an engine that was designed to be capped at 4-5 concurrent players, given that they only make money off the hosting of the server architecture (if at all).
They would surely want to leave it uncapped, so you can scale it as large as you want - so they get more money.
More players => More Server resources required => More cash for Amazon.

Even if it is capped at a figure - they don't say how many that figure is - it could be 64.
64 Players in a 3D game universe with everyone dressed as superheroes is still more City of Heroes than we currently have. (With exception to Paragon Chat and Icon)

[Codewalker]

Oh, I don't think it's a hard cap, just that you'll find (much like anything else you run on AWS) your players automatically talking to different game servers based on locality, and that the synchronization of your data store isn't always as timely as you'd like.

[Baaleos]

It's not targeted at MMOs. From the description, the server component is for:

"You can use it to host many different types of shared, connected, regularly-synchronized games including first-person shooters, survival &  sandbox games, racing games, sports games, and MOBA (multiplayer Online Battlefield Arena) games."

i.e. things that feature a large number of independent gaming sessions with small groups that do not need to interact with each other, except possibly to update a leaderboard afterward. Which makes sense, because the AWS architecture is massively parallel and based on "best effort" replication that is not necessarily always up to date. It's designed for that sort of thing, not for a persistent shared-world MMO that needs to be completely synchronized between all players at all times.

https://aws.amazon.com/lumberyard/

This page suggests that the multiplayer component of the engine is elastic supporting as many players as your willing to host (and can afford to host)

https://aws.amazon.com/gamelift/

Amazon GameLift enables you to easily scale your game from a few players to millions, so you can use it from your first beta test during development to public launch and beyond. Amazon GameLift utilizes Amazon EC2, which provides a truly elastic computing environment. You can provision one, hundreds, or even thousands of server instances simultaneously.

Millions of players, and not being an MMO?

Think its too early to be assuming the worst.
No one here as tried the engine yet, so why assume it cannot handle MMO development?

[blacksly]

Oh, I don't think it's a hard cap, just that you'll find (much like anything else you run on AWS) your players automatically talking to different game servers based on locality, and that the synchronization of your data store isn't always as timely as you'd like.

I wonder if it would be reasonably applicable for a heavily instance-based game, much like CoH was, with street-sweeping having become a very minor part of the game. If all combat and such actions is going to be handled in a relatively small-scale group, it should be possible to scale the lower-information interactions such as chatting, market, team organization, etc., a lot higher than if you have to worry about character location and combat interaction.

[Codewalker]

I'm assuming we're both using the term "MMO" as shorthand for "MMORPG", as in the traditional shared-world environment with character progression, teaming, quest-like plot driven objectives, consistently seeing the same people if you're playing on the same shard, etc.

If you're instead using 'MMO' to mean anything with lots of players, then we're talking past each other, so nevermind.

This page suggests that the multiplayer component of the engine is elastic supporting as many players as your willing to host (and can afford to host)

It doesn't say you can have all those players sharing a single, consistent world. The implication that it can't easily do that comes from the list of game types given as examples; all of which involve short, relatively small multiplayer sessions logically disconnected from each other except by a matchmaking system.

Millions of players, and not being an MMO?

Yes, that's what a MOBA is. League of Legends has millions of players, but you only ever see the ones you end up in a match with, which are usually those with a skill rating close to yours. There is no running around socializing with random people that you aren't already in a match with (or have on your friends list).

Some first person shooters have millions of players and are not MMOs. A few recent ones have vaguely MMO-ish aspects (Destiny), but are not a full MMO in the sense that most people expect when they hear the term.

Sandbox games (a la minecraft) have millions of players, but do not feature a shared world. Instead, multiplayer consists of one person hosting a world and others visiting it in a transient fashion.

Think its too early to be assuming the worst.
No one here as tried the engine yet, so why assume it cannot handle MMO development?

How is believing that it's designed for what the information page says it's designed for assuming the worst? I'm sure it'll be great for small studios wanting to jump on the MOBA bandwagon without a huge server investment. If it turns out to be cost effective, we could see some very interesting indie development as a result.

But why assume that it can handle MMO development when that's the one type of game that was excluded from the otherwise very specific list?

[Codewalker]

Also, I never said that it was impossible. Just that what most people think of as an MMO is probably not the best fit for something built on AWS and would take considerable effort to make work acceptably. For example:

I wonder if it would be reasonably applicable for a heavily instance-based game, much like CoH was, with street-sweeping having become a very minor part of the game. If all combat and such actions is going to be handled in a relatively small-scale group, it should be possible to scale the lower-information interactions such as chatting, market, team organization, etc., a lot higher than if you have to worry about character location and combat interaction.

That's something I was thinking about (and have been thinking about anyway for other reasons). Yes, that is one way that a COH-like game could work on a highly distributed architecture. But you'd be mostly limited to teaming with people you've friended or found through other means.

If you did away with street sweeping and turned the exterior zones into lobby areas, then the instances themselves would fall within the parameters of something like this, and are quite similar to how COH handled instances anyway. You'd probably lose the ability to reliably find people in the outside world unless you're explicitly teamed with them, as non-teamed players would randomly be distributed to available zone instances.

Server shards aren't really a solution for that, as the whole point of AWS is to spin up instances dynamically as needed to handle the load. But perhaps some sort of creative player affinity system could make it so you usually end up seeing the same people with similar play habits.

[Arcana]

Also, I never said that it was impossible. Just that what most people think of as an MMO is probably not the best fit for something built on AWS and would take considerable effort to make work acceptably.

Lumberyard uses EC2 instances to power its "servers" (from my read of documentation it calls these "fleets").  A fleet would be comparable, I believe, to a mapserver instance.  If you're willing to spin up C4.8xlarge instances for your mapservers, I think you could make a CoH-like game in Lumberyard: CoH's mapservers, even for the shared zones, I don't think were substantially bigger.  And the persistence data wasn't stored on anything especially zippy: Amazon's Mongo would probably work fine.

I *think*, although I haven't explored deeply enough, that how you host on EC2 is dependent on your own game's architecture.  You could make CoH-like "server shards" each managed by a permanent EC2 instance, and then spin up other "fleets" to handle smaller instances automatically.  Things like global chat would also be implemented (I presume) on dedicated EC2 instances.

[Baaleos]

It says elsewhere in the documentation that by using the engine, you are not tied in a contract to 'having' to use EC2.
If you have your own servers, you can use those - the only limitation they enforce is that you cannot use their engine, and then host on a cloud provider such as Rackspace.
So you could potentially run it locally on your home computer.


Q. If I build a single-player game that uses no cloud connectivity, do I have to pay to use the engine?
No, in this case you would pay us nothing.

Q. Do I need an AWS account to use Lumberyard?
No, but by downloading or using Lumberyard, you agree to the AWS Customer Agreement and Lumberyard Service Terms. If you want to use Amazon GameLift or Lumberyard's Cloud Canvas to build connected gameplay features, you or someone from your game team needs to register for an AWS account and provision services to your account.

Q. Do I have to run my game on AWS?
No. If you own and operate your own private servers, you do not need to use AWS. You also don't need to use AWS if your game does not use any servers. For example, if you release a free-standing single‐player or local-only multiplayer game, you pay us nothing.

Q. Is there a surcharge or other additional fee over and above AWS service rates for Lumberyard customers?
No.

Q. How do I authorize my team of developers to use Cloud Canvas and AWS via the Lumberyard Editor?
To enable team members to access AWS through Cloud Canvas, you first need to create an IAM user for your team members and generate access keys and secret keys. Your team members can to enter these keys in the Lumberyard Editor's Permissions and Deployment menu. For more information, please see the Cloud Canvas and IAM documentation.

Q. Can I grant certain team members permissions or restrictions to access specific AWS services in Cloud Canvas?
Yes, Cloud Canvas lets you configure permissions so your development, test, and release resources can have different access restrictions. Cloud Canvas creates AWS IAM Managed Policies, which can be used to grant access to the AWS IAM Users and Groups you choose. You can customize the permissions by editing your Cloud Canvas configuration in the Lumberyard Editor and update the user and group assignments in the AWS Management Console as needed.

Q. Which AWS services are available in Cloud Canvas?
Cloud Canvas enables you to use DynamoDB, S3, Cognito, SQS, SNS, and Lambda via the Lumberyard Flow Graph visual scripting tool.

[Surelle]

Even if it isn't necessarily set up the way MMORPGs really require to run correctly, it does open up interesting possibilities for minor alterations or pushing the scope of what's possible, both for Paragon Chat and for Lumberyard.   :)

[Baaleos]

I personally would just like to see how easy it is to make a game where I can run around and fly.
It being the CryEngine (a derivitive of it) - it has some beautiful graphic possibilities.

I wish I was good at 3d modelling, would love to see Paragon City or Rogue Isles in CryEngine.

Multiplayer would be a nice bonus, MMO would be great, but even if it was capped at 40-60 players per game server, I think session based multiplayer is still better than no multiplayer.