But I dont have a current gen console :(
While this is ontopic the starting topic was just about listing achievement suggestions, maybe this could be split. On the topic of the server side, any suggestion?
Server:
Server can be a web server or a console application. Personally I prefer web server. Second, it can work with ansi or utf-8, I rather go utf-8 but its easier on web servers, i recall its not that simple on c++. Going utf-8 allows the server to send text messages in other languages if that was ever necessary.
Communication with Server - Services:
For all the services, each transaction blocks the emulator program and waits 60? seconds, the emulator shows a window so the player can choose to start offline mode at any time. If the initial 60 seconds are up the transaction is cancelled and a new one begins for 61 seconds (and so on add 1 second until it passes or the user goes offline).
a. Registration. Done through the website, your average registration... The user chooses a login and password, these can be anything allowed (ansi/utf8?) and will be used only for login purposes. They also choose a username, which will be used for anything displayed, the username is limited to at least one alphabet letter and followed by numbers [a-zA-Z]+[0-9]*(this cool?).
b. Login. Required: login, password, controller. The login and password can be anything allowed (ansi/utf8?), user's fault if they go with weird characters and at some point they arent understood correctly.
The server validates, tempbans the IP for incremental time starting with a day after about 10? failed attempts during the same hour?. Tempban severity reduces with time as well so as not to destroy unlucky dynamic ip users.
Answer:
- F# where # is the number of failed attempts remaining, if it reaches 0 the user was supposedly banned. The emulator should let the user know about this number.
- T if the user is/was tempbanned, the time will not be sent. Repeated attempts to login after this should increase the length of the tempban ala Diablo 2. The emulator should remind the user about this: a messagebox, load the browser pointing to an official page explaining the case and/or just block the submit button.
- B if the user is/was banned and as such their request was not heard. Block the submit button since this is useless.
- S the login was successful. Following the first char there will be extra values, ini style (unless you wanna go JSON) with whatever else should be sent at login. The first value is the player's name, followed by the session id, and time required between pings in seconds, for example other value could be a message with the number of failed attempts on the account since last login.
c. Ping. Requires: session id. The emulator sends a ping, and the server verifies it. If it was sent too late the session will be over already, if it was sent (way) too early the server will raise a flag. you are supposed to send the ping early but not way too much (1.5 minutes before?)
Answer:
- S if its fine.
- F#, it works like the login, so there can be a couple mis-pings due to changing windows clock. The server sends this in case the ping was sent early. The emulator has to catch this and in case this keeps decreasing let the user know.
- O if the ping failed but didnt make the server angry (session over), the emulator has to forcibly pause and ask to login again before resuming or going offline (or retry automatically or whatever), if it just pauses this counts against the player if the lua scripts are taking this into account, the emu coders could blacken the screen and not do an ingame pause though.
c. Game loaded. Requires: game identifier, sessionid.
Answer:
- F if the game doesnt exist on the database.
- S followed by the achievement ids and CRC of their scripts followed by achievement values comma separated (integer list)
d. Obtain achievements script. Just download it from the web server.
The script contains the achievement name, description image urls etc.
e. Send game data to server. The client sends data to the server by request of the achievements script, the server accepts it and executes its own verification script to validate and decide whether to unlock or not the achievement. its up to the achievements coder to keep this complex enough so that it can't be cheated so easily (do not send 0 or 1 and have the server unlock if it is 1...), send memory addresses and have the server calculate the stuff on its own if possible otherwise send some addresses to check consistency.
The server updates achievement value and sends its results.
Answer: list of achievements changed and a return value for each (technically you just return an integer, that's what gets stored on the database, but returning something else opens for whatever else, do i keep it simple?).
Ideas, this can be done with this spec as is:
- Off to On achievement. Technically it can go the other way too but this should be avoided unless its something creative as it encourages stealing passwords :D
- Bronze Silver Gold state for achievement, as you progress the achievement improves.
- Leaderboard achievement, (ie. top ten at X) as I'm not ruling out the verification script could access databases. Returning the leaderboard table would not be possible just by returning an integer though. Also remember leaderboards brings cheaters.
- Personal Record type achievement, like leaderboard but you compete against yourself, it can be done with an integer but you'll probably want more?
- The progress of one achievement changing another for whatever reason? (that another's script may or not modify its own value).
- Different looks/animations for achievements, the script decides what to do after all.
Basically its free for all, but of course the ones that get added to an official release get moderated before so its all cool.
Emulator side:
Achievements window: Among whatever else allows login (login, password, controller), shows achievements for current game (standard size images), allows to reset an achievement, allows to select offline mode (which allows to use custom scripts), allows to check "automatic sign in", and remember me, and stuff like that.
Reset achievement. This is not serverside, the client can reset an achievement to its initial value (lasts during their session) so that they dont have to create a new account just to get the achievement animation again. The emulator and script know however so it shouldn't send data to the server until its time to actually update the value, be good coders and dont have the verification script reset the achievement if you miss this, and also save some bandwidth. This doesn't reset the server (at least not directly), or people could steal passwords just for this.
Actually..., only allow this while playing offline, yeah that would work.
My personal take on Offline mode vs online, there are two ways to define offline mode, to me offline mode doesn't count for server achievements, offline means not logged in. It uses values stored on your pc or whatever that's up to the script and emulator. That eases my reset suggestion too.
Then again the script/emu can always save the values that triggered the achievement and send when it gets online. So offline mode could be that, a user logged playing a script with no client side validation that allows to play offline after(or without) logging in.
Vulnerabilities:
If the player researches or the coder leaves the values required easy to see they can simulate a connection and submit the correct values, the only possible block against that is the verification script which can remain hidden, but against correct values it shouldn't be able to figure it out.
Leaderboard type achievements would be subject to this. This is big enough that I don't think modifying the emulator or what not would be warranted for the cheater. At least, a cheater cant crack all achievements on the system at once, they have to crack them one by one.
Counter Measures:
- Avoid programming leaderboards. Do Personal Records instead.
- Do not allow offline mode? that way you can hide the values you want (since your script won't do validation client side).
- Make sure your code handles gracefully the case where an achievement value degrades instead of improves (due to coding error, hacking, etc), technically it should be ignored, unless you are 100% sure you want it happening...
