Advertisement Jump to content
  • Advertisement

graveyard filla

  • Content Count

  • Joined

  • Last visited

Community Reputation

605 Good

About graveyard filla

  • Rank

Personal Information

  • Interests
  1. graveyard filla

    User login system for mobile.

    Have you thought about just using an API for this? Amazon has Cognito (OK) and Google has Firebase (better), and then there's GameSparks (GREAT, if their platform is a good fit for you). Authentication is a lot more complicated than you might think, especially doing it in a proven & secure way. Drew
  2. damn. Well said. Will think about this and process it some more. I have heard horror stories about apps being pirated but maybe I'm thinking about this completely wrong. Thanks a million to you guys for your help! Drew
  3. Someone being able to play the game without paying for the IAP assets "For example, you could pre install all cards, but make the client "dumb" and just send selections to the server, and then only show/animate based on instructions from the server. This would prevent against players "seeing the wrong thing" until players figure out how to write a fake server." This is a great idea and one that I have also thought of. The problem comes with how simple the 'game logic' is. It's basically just an animation player. Imagine a childrens card game where you could collect cards and then when you played them, a cool animation played. There's no interaction with game logic outside of maybe recording points and such for playing the card, there's no interaction with another player. The premise of the game is to come up with really cool 'decks' which have unique combinations of these animations and then share them with other people. "Regarding encrypting the assets against "ripping," know that tools exist to slurp textures and vertices out of the graphics card. Because the card needs to render to screen, that data need to ultimately be in decrypted form." Textures and models - OK. But what about animation files? I haven't read enough yet about tools which allow rips, I'm curious if they have the same thing for an FBX file thats sitting in memory. "Pays can also use screen video recorders to record the animations and enjoy them whenever they want." That's OK - as long as they paid for the one they want. The true engagement of the game comes from the social interaction with other players showing each other their pretty/fun 'decks'. "If you want to encrypt files on disk, there is nothing bad about that per session, but it won't stop a determined attacker. That being said, your actual problem will be getting people to find out about your game, and then care about your game, and then care enough to give you money. Asset ripping seems like a first world problem by comparison -- almost like free advertising..." True.. But I have heard horror stories about games having 3x as many downloads for the pirated version in the 3rd party app stores vs the actual paid versions...
  4. My concern is that since this is a mobile game available on IOS and Android, people will be able to make modifications to the binary and inject code which would allow them to bypass the IAP functionality, therefore gaining full access to the game without paying for anything. Of course, once they do this, they will put the modified app in the 3rd party pirated/app stores and make it free to download for anyone who wants it. My goal is to protect the IP and monetization of the game by only allowing users who actually paid to make use of the game in the way they are allowed. If the animation files are encrypted on disk, they won't be able to do anything with the game without connecting to the server and receiving the key. If the key is always sent Just In Time, the animation files will never be decrypted on disk. Through this, only users who paid will be able to use the game for the portion they paid for - until someone is smart enough to read the keys in memory or flush the decrypted animation files to disk. I appreciate your feedback a lot! I have thought the same thing about making the client a 'dumb terminal' and having the server run the actual game logic. I think that might be the solution, but I still think adding encryption and only allowing the assets to be downloaded after they pay may add an extra layer of protection without too great of a a cost. The reason being is because even if the client is dumb, I think the server logic isn't anything crazy hard to replicate due to the nature of the game. It's not very interactive. Imagine a card game you would play just to watch the visual effects of using the card, like for children to watch cool animations once they play the card. Since there's no actual interaction with the server, creating a server may not be that difficult for someone to do...
  5. hi,I am working on a "massive single player online game", whatever that means :). This will actually be a card game with 3d animations that you will play by yourself. The game will require an internet connection to play, as it will have a tightly integrated social system to drive engagement. I'd also like to have the server be authoritative for some basic stuff - since it's a single player game, I can't really be authoritative for much, since the game has no verifiable rules - the game allows players to just play cards and watch the animations with some local interactions/random effects. But at least I can do some basic sanity checks, such as "does this user have this card, and did they actually pay for it", "have they played this card already in this game", "have they played a card within the right time limit, as in has it been at least X seconds", etc... Just to clarify - the game doesn't actually have server-verifiable "rules" per se, it's not like Solitaire where I could simulate the game being played on the backend. The game just allows players to play cards and watch the animations on the screen. The "rules" are arbitrary and defined by the person playing the game, so there's nothing to verify in that regard. Since the game is single player and there are no server verifiable rules in the game I know that this will be easy to hack since a malicious and smart player could eventually build a proxy to respond to the calls on behalf of my game server and allow players to download pirated versions of the app in an app store with all of the IAP assets already in the build. I have an idea that I wanted to run past you guys about adding an additional layer on top of the basic sanity checks to protect the assets from being pirated. Basically - the game client will come bare bones and you won't be given any cards up front except for the "gifts" you receive as a new player. This means the graphics & animations won't be on the device until the moment you open that card in a pack you purchased. The server keeps track of what cards the player opened in the packs. Here's the trick now: the animation files themselves will be encrypted and the client won't be given the key. Then, when the game client goes to "play mode", he calls out to the server and says "I'm about to play a game using these 10 cards" - the server verifies he purchased those cards and then sends him the 10 seperate keys for those animation files. The game client would load the animations from disk, decrypt the files, and then throw away the key and never persist the decrypted animation files. In essense, the only way a malicious person could now obtain assets they don't own is some person would have to first attach a debugger to a mobile game client, find the keys in memory in the exact moment it's sent from the server, and then build a server proxy which would respond with those keys to anyone who downloads the pirated game. OR, they'd have to dump the decrypted animation files to disk - and then make the game logic jump over the decryption sequence (I'm not sure how hard that is to do). This feels sufficient enough for me that it would be a big enough barrier to prevent hacking at least to some reasonable extent. In addition, I could cycle the animation files + keys on a monthly basis if I really wanted to. Any thoughts on this? Is this just absolutely insane? Is there a better way? Is this just a waste of my time and I'm missing something obvious? I know that credit card processing companies have used similar methods (perhaps outdated) to store credit card numbers. I''ll still need to prove the concept by making sure this isn't too memory /CPU intensive on a mobile device (e.g. iPhone + Android). Thanks for any feedback!
  6. graveyard filla

    Web API for a turn based game?

    Thanks man.. I'm still going to build the UI using Unity so I will be sure to include the credentials in each header by default. The Auth Service will manage the account related tasks as well as generate unique, 1 time use 128bit tokens for the Master Server to use to 'hand off' authentication to the game/chat/matchmaking services.
  7. graveyard filla

    Web API for a turn based game?

    Does basic auth imply UI? I thought basic auth just meant header based, where as your example the creds are POSTed in the body. The advantage to using headers is that you can GET and POST, where as with body based, you would need to include auth inside whatever you were POSTing, so if you did want to POST actual data, you'd need a slightly more complciated body.. No?
  8. graveyard filla

    Web API for a turn based game?

    thanks hplus.. Is it OK from a security standpoint to re-authenticate for every single action when calling the HTTPS service for these actions? (e.g., no caching auth). I will probably use basic auth so that user can just use his username/password.
  9. graveyard filla

    Web API for a turn based game?

      hi hplus, I'm struggling to find much information about creating TLS connection in Unity. I'm now doubting that games implemented in Unity (at least in general) are using TLS at all. Maybe I have the wrong keyword, but googling around for 'TLS connections with Unity3d' brings up almost nothing. I want to make sure that my game is as secure as possible within reason. So my plan is to not do authentication on the actual Master Server or Game Servers, but instead create an HTTPS based 'AuthenticationService' for authenticating users in a completely seperate web application. My plan is to expose an endpoint on an ASP.NET MVC app which will accept the username/password, as well as allow users to create new accounts. Any time a user logs in, he will send in plain text his username/password to my AuthService, the AuthService will validate the user using Hashed/Salted PW (or maybe Scrypt, although need to learn more abbout that - as the Scrypt examples I saw did not expose the salt). AuthService will then Generate a 128bit unique number and send it to the client. Client will then drop connect and connect to the Master Server using his 128bit number. The MasterServer will call out to the AuthService to validate the 128bit number is valid. Once user is matched up to a game and connects to the GameServer, the same tokenID will be used to ensure the GameServer this is a valid connection. Anytime a user connections to another server (chat server, game server, disconnect from MasterServer and reconnects) he will continue to send that 128bit number on the initial handshake and those servers will each call out to the AuthService to make sure the ID is valid and not expired passed reasonable timeframe (still TBD..). Does this sound like a sane approach to you? Since I don't want to implement TLS on my game code, I think this should work OK.. The altnerative to using the AuthService in this manner is to I guess use the 'ticket' system you mentioned. I'm still not sure how that works though.... (userid:gameid:issuetime:hash(userid+gameid+issuetime+secret_key)) What is 'gameid' here? the unique ID of the game as in application title? or is a session ID that the auth service generates and stores? What is secret key? Do you have a good keyword for this scheme for me to google and learn more about?  Or should I juse use the system I described above? Do you think there will be any issues when I add new auth providers such as Facebook? Thank you again for your time!
  10. graveyard filla

    Thoughts on Amazon GameLift?

    hi Hodgman, thanks for the quick reply. Yes, I agree, the downside is that you're locked into AWS. *However*, even using EC2 OnDemand and creating my own 'intelligent provisioning engine' would still keep me locked into the AWS API to spin up and shut down instances, right? Since there's really a minimum amount of GameLift SDK code needed to get this up and running, I think the 'commitment' level is reasonably low. If AWS proved to be too expensive even with the dynamic provisioning, I could move to something like Digital Ocean and create my own smart provisioning (which was the other alternative I am considering)... Also, I agree, the downstream data cost sucks with AWS. Since I'm making a card game and not a shooter or action game, I think that it should be fine though. Although benchmarking tests would probably prove that better. Also - the other thing that drew me to GameLift is Amazon Aurora. Amazon Aurora is super bad ass, scalable SQL. Since as you pointed out, getting data out of Amazon is expensive, using something like Digital Ocean for the app servers with Aurora for DB servers would be silly since I'd be paying Amazon every time I ran a query. So with AWS you get super scalable SQL too... PS, I'm open to alternatives to GameLift if anyone has any. The other one already mentioned is Digital Ocean + home brew 'auto provisioning'. I also found GameSparks and PlayFab, but don't love either of them as GameSparks seems too locked down into their own proprietary server engine and PlayFab doesn't have great documentation on how to setup and use their Authoritative Server hosting. It also comes with a whole bunch of bloat I don't need personally (e.g. inventory tracking, player rewards, friends list)
  11. hey everyone, I've been researching hosting providers for a multiplayer card game I'm working on. Something that came up in my research was Amazon GameLift. It looks VERY bad ass for session based multiplayer games. In a nutshell, you use their SDK in your game client and server, and then upload your server binary to GameLift. You then set parameters for how much load a game server Instance should handle (e.g., say 50 players). It will magically spin up new servers to handle peak time loads and then spin them down after peak hours. This should not only keep costs lower than traditionally pre-paid/static hosting, but should in theory make the game "infinitely scalable" (well, at least the game/session server part). Anyone here using this already and have feedback? Any thoughts in general?
  12. graveyard filla

    Web API for a turn based game?

    thanks. I have to think about that hand-off more. I was thinking that the Web Server would generate a session ID (GUID) and encrypt that session ID. Then it could send it to the game server via a normal TCP message, and back to the client in as part of the response to a GET.
  13. graveyard filla

    Web API for a turn based game?

    thanks for the response! BTW, MVP target is iPhone and eventually Android + PC and potentially consoles way down the road if it sticks. We won't be targeting Web in Unity most likely. Do you see any holes in my idea of doing a 'hand off' from the web app to the stateful game server? Is there something obvious that I might be missing or does that transition seem viable?
  14. graveyard filla

    Web API for a turn based game?

    hi hplus! I don't know if you remember me or not.. I was a big time user of this forum a decade ago and learned A LOT from you personally here in the multiplayer forum. I have since been a developer in the business space and am now finally returning to games. I just wanted to say thank you for all the help you gave me all those years ago. It truly made an impact in my life. "Games where this works really well are games like Farmville or Backyard Monsters or such, where the player really is only doing their own thing, and the only need for the back-end is to validate what the player has done, record the state of started work/timers, and such." This sounds very much like the requirements of the MVP of my game. The client just needs to have an authoritative server to tell it which cards it owns, which decks it has, send it the resources for those decks, social aspects (friends lists, news feed, eventually it would have messaging), etc. Once the MVP is proven, we would add a 'VS' mode where 2 players could interact with each other in a turn-based way. Back in the day when I was learning about the architecture for MMOs here, I remember what you had told me about how it worked at the game you were building at that time, I think it was Second Life? You had told me the best architecture is to have distributed services. I have found that to be true in the business world as well. I was thinking that a good approach to tackling this problem is to start off with a simple web server, and then later, when 2 player VS mode was needed, expand into a TCP connection / stateful game server using some sort of methodology like RPCs or such. UDP wouldn't be needed here as the game is nowhere near real-time and there are no physics interactions in the game outside of animations and such which can be run client side as they don't impact the state of the game and so don't require server authorization. This approach seems like it would allow me to organically grow the application as needed as well as distribute the work to separate services which would hand over sessions to each other behind the scenes. The Web API could tell the stateful game server a session was coming his way and the clients could then connect with their session ID's to a warmed up game server. Do you think this approach would lead me to paint my self in a corner, or does it seem sane? I don't want to build a stateful game server from the beginning as it may be overkill. The MVP may not even take off, or it may take off in a different direction altogether and it seems easy enough to add stateful ness later. But, I've only been back in game development for 6 months now, and haven't done serious networking in a game yet since 10 years ago... Thanks again man!        
  15. Hi, Wow. I haven't been here in a long time, and it's crazy to see this forum still thriving and people like hplus still around helping people. I am working on a prototype for a multiplayer mobile card game using Unity. I'm trying to finalize some architecture decisions. I was thinking of building the server as a Web API (using ASP.NET MVC) and having the client basically just GET and POST when needing to communicate with the server. I was wondering if people are using WebAPIs in commercial games and how sane of an approach this seemed. Since the MVP will not even support interacting with other players in real-time, it seems like this is going to be the simplest solution rather than creating a state based game server. Later, when we started adding features like 2 players being able to play against each other, I was thinking we could add a stateful game server at that time. Then, when players wanted to play against each other, the web server would do a hand off to the stateful game server 'players with ID x,y and session Id Z want to begin a match'. The game client would then connect to the stateful game server which would now be warmed up and ready to manage that interaction. This would accomplish 2 goals, 1) allow me to build only the bare minimum needed for the given requirements at a time 2) organically grow the server side as requirements are added 3) reduce the load and complexity on the servers so that they have a minimal amount of responsibilities. The service that does game logic doesn't need to manage friends lists and players news feeds. Any feedback on this approach? Thanks for the input!
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!