mr_j936

2 GB of ram and dual core is what I am expecting for that kind of money, my friend uses gogrid for most of his online stuff and he trusts them a lot. I'm inclined to go with that. I am not worried about the actual game size as I am worried about how many players might potentially be on it... given my 0 experience in hosting a game, I find it difficult to predict/estimate server usage pattern. I'm making it on android phones as an app. It might get better visibility, competition is slightly less fierce, and you get the benefit of writing native code that can do its own calculations and store its own graphics, saving you server energy(of course you'll be checking with the server before every action, but not necessarily checking every time the player clicks his inventory to remember what item he has... etc) anyway I should start coding it already :D talk is cheap.

I don't know all. In fact as I mentioned I never made a game before so I don't know anything :P which is why I am here discussing and learning and I thank you for the valuable info. The thing is just that I want to make a small game (it has always been my dream :P) and I cannot afford to pay for than 70$ a month for a server and I was checking to see any way that I can squeeze every dollar from that :P

My friend plays Ogame, he tells me that if he invites players, he gets premium whenever they buy premium(like 5% of what his friends bought) and so he actually encourages his friends to pay... There are many things one can do to boost game visibility, make a mobile version of it, or at least make an app that is no more than a browser that opens your game on the phone(which is 3 lines of code to make) at least your name shows up on the mobile market and you increase your visibility...

DB for writes is fine if you have 50 to 100 online, but if it gets more than that you have to take the gamble, you still have sql, but sql would be a backup, a little behind what is actually going on. You really believe twitter and facebook store every single thing on hard drive when it comes out? They take a gamble to save billions, sure some data might be lost, as long as it is nothing very vital and backups are not very old, nothing bad will really happen...

I know it's old, but I also noticed it was a sticky, so I figured it's ok... And I don't have much expertise in databases and memcache, I am talking out of pure research. But I have read that writes on DB are a major bottleneck and that you would be making like 20 writes per second at best, while memcached can do thousands. And in a game, the user might change the same variable several times in under 10 min(lets say we were keeping track of his life and he attacks 2 players within 10 min etc...) I ran some basic tests on memcached with php, I was very impressed with the way it can modify data and the speed of it. I never considered any other language than php... Guess I should look into that. I thought java as a language was too slow and heavy to be used to run a game server.

Question, why not write and update data into memcache, and use the sql database as a back end backup? What I was thinking was, do everything in memcached, and backup data to sql on an hourly or semi hourly basis (one giant query is better than a million small ones) worst case scenario server crashes players lose an hour of their game, on the other the game will handle more players more smoothly and would save server costs. Premium related actions can be handled purely by sql so that money would not be in jeopardy. I also think if the game is for example an RPG game, and you only keep active players data in memcached, you might be able to fit the whole active part of the database in your memory, if each player is worth 100 KB of data, and you have 1000 players active at one time... so um yeah, I hope to get a reply on this.