I need to create a Cross-platform game, with simple 2d tile graphic with high scalability. think of it as a social four-in-a-row game with a BIG playfield. The only functions in game should be to expand your tiles, change color/upload picture that will be the textures of your tiles.

Message to other "players", and some expand ratio( ex. get one more tile that every 24h)

It should also have functionality like zynga games in the sense of Facebook,ios easy to join/Use it everywhere.

The essential part of this game/app is that its as easy as possible to join, You can see/play it on as many devices as possible, you can view/scroll a very big 2d map of player tiles.

My resources:

Me: ( Wich is nothing) Html,CSS, Javascript, a very little bit of python, excellent coffee maker.

Since this is a marketing project/game for a friends larger company I have a 25k$ budget for hiring etc.

Questions:

How hard is this to accomplish?

What languages should you stitch together for optimal performance/accessability? ( game engines? )

What knowledge base should I consider in my hiring?

Is this project to big for my resources/budget?

I would love to be apart( and learn ) as much as I can in the creational process and have some kind of grasp about the budget needed before starting to talk money with some software engineer who uses alot of fancy words..

The Companys/mine location is Sweden, Gothenburg if that mathers.

Sorry for the long/vague question!

Thank you so much for any answers!

Sounds like a fairly simple task relative to other game projects out there.

HTML, CSS, JavaScript and PHP should be enough to make this work.

The project can probably be accomplished on a $25k budget. You will have to think about graphics design and marketing as well though.

I might have misunderstood something, but this sounds like a game that you can create during a Ludum Dare, lol.

Thanks for the fast answer diventurer!

Maybe this is the wrong forum and maybe you can think of this more like a big artwork with options to change position..

On of the essential thing is that every player is on the same map, Could PHP/javascript ( or python? ) handle this?

If i want to make it cross-platform and IOS native app aswell could you "wrapp" this app/game/map in a obj-c shell?

to see the canvas in realtime in the app?

So for hiring iam looking for a PHP proffesionel with maybe some background in obejctive-c?

Thanks again for the answer!!

There are a few big, unanswered questions here:

1) How long should this game operate for? Days? Months? Years?
2) How many players will issue "moves" in the game at the same time? dozens? hundreds? tens of thousands?
3) How much hosting cost is acceptable once the game is up and running, for how long?

There are also game implementation questions, like what to do when someone joins but then doesn't come back and leaves part of the field dead, or how to deal with the inevitable child porn and mass murder pictures that will be uploaded, and on and on -- but those are game design / operation questions, not technical questions.

For any reasonable amount of adoption, you can likely build this with a single data store -- Cassandra, Redis, or even something custom in-core if you have good developers for that -- probably not.

You can then build player-servers using something simple like PHP or Node.js (node.js makes it easy to also use socket.io for real-time updates.) Each of these talk to the in-core back-end to confirm/deny a move request, as well as separately deal with tying people to facebook when they sign up.

The GUI should be built in HTML and CSS for sure, although you have to pay really close attention to high-performance HTML/CSS layout rules. Some of the deep CSS and jQuery things you can get away with on a static web page, would kill a project like this.

You will also want a CDN of some sort for your uploaded pictures -- a big filer/file-server/gallery on the storage side, and then a simple immutable URL scheme that you cache through the CDN. (CloudFlare, CloudFront, Akamai, etc.)

Host it all on Amazon AWS/ECC if you want to be able to add player servers in a hurry if the game takes off. The central-datastore is a limit to scalability, though, so make sure to benchmark how hard you can push it, and come up with some mitigation idea if you really think this will have FarmVille-style adoption.

Thanks for a very thorough answer!!

1. Years hopefully

2. Maybe tens of thousands ( But you will not have, its more that you gain a new space to upload to.) This company will give 1euro to sharity per login for the first 5000 people joining.

3. don't know the acceptable cost but 1000$ per month maybe is this to little?

I am looking for a Cassandra or Redis programmer then?

when joined your "space" will always belong to you. And no one can overwrite it without your consent. Maybe its easier to think of it as and artwork.

The last thing is that they would like it ios adaptive from the beginning..

Thank you so much for answering! saved me a couple of hours of googling and afterwards not being sure if i found what i was looking for!

Cassandra and Redis are back-end tools; you're not looking for a programmer for them specifically -- what you're looking for is a web back-end programmer with experience in those kinds of tools.

Note that, depending on the data model and game rules, maybe some totally different kind of database back-end would be better -- we can't know without having all the requirements and rules. Thus, a developer with experience in multiple tools (I'd start with Cassandra, MySQL, memcached, perhaps HBase) will be able to choose the right back-end, and be able to cost out what it'll take for various lifetimes and adoption rates. Microsoft SQL Server and Oracle and DB/2 are all unlikely to be good matches, for cost reasons, though. They are for enterprise systems, not low-cost gaming systems.

If you want to be able to collaborate with the developer, focusing on Node.js as the server technology might make sense, although it's likely more important that you find an experienced developer with a wide skill set, who knows how to trade off the requirements you have, than any one particular technology.

Also, the most important thing to think about is keeping the number of database queries per operation low. If a new user joining generates more than a handful database operations, and an existing user making a "move" generates more than one or two, you're probably doing it wrong. A small number of queries is what's needed to make sure you can scale to large amounts of customers with a single back-end database.