Sign In Register

How can we help you today?

Start a new topic

GameData service missing features

Hi GS Support,


As you introduced GameData service and the runtime collection became obsolete, we miss lots of features, which slows development and maybe forces us to use different backend.


Geo features were mentioned here: - Geospatial queries with radius, which we use to determine location of places/players around the world.

GetItem() method in cloud code - Currently it supports only search by Id, what if I want to use some custom field as it is in findOne()? This one can be workarounded by queryItems(), but in my opinion, this is ineffective.

Random id when creating new item - You need to specify id, would be nice to have another method without id parameter, so it will generate random one as Mongo did that before, this also can be workarounded and pray that random generator is random enough + add few checks, another ineffective one.

Update queries - Why I would fetch the whole document to make single value change and push the whole document in? In runtime collections I could type update query to change it without fetching whole document, this would be cool to have it.

Atomicity - When two players changed single document, Mongo locked it and then unlock and executed next query. However the persistor with withVersionCheck() only returns false, there should be more documentation how it behaves... if it handles itself (waits), or this should be looped in some cycle - again fetch data, make changes etc... until it will return true.

Fetch only needed fields - In Mongo query, you can specify which fields to return, this was great feature.

Yes, I know some of them are mirror, but I definitely like the effectivity I can achieve and have more control etc...


Hopefully next release will extend this new api as the idea is not bad, but the api feels kinda unfinished.




14 people like this idea

I feel grateful to be grandfathered in the old system. I keep looking at the new system to see how easy it would be to port over...

  1. It's not portable (For recycling code between new games if the old game was using nosql).
  2. It seems to lack features upon being released.
  3. It doesn't seem very intuitive by comparison.
  4. It's an internal structure that makes Googling very difficult to find answers.

If this was truly for new users, don't forget about the old, too! The new system feels like a serious downgrade.

If the primary reason is performance, perhaps halt the deprecation and allow nosql in new projects with an edited fair use agreement to use projections whenever necessary (which I read that is lacking in the new system, anyway). If you have a bloaty json doc but you only pull a single field from it, the overhead is significantly lower, among other forms of optimized mongo'ing :)

4 people like this
Dylan, the worst part of GameDataService is that it's not having better performance. I have profiled it and compared the same basic operations (create empty doc, update a doc) and found GDS is 5-8x slower than Mongo. When I contacted support and showed them screenshots of the profiler and my code, they had nothing to say. They wont explain why its slower or reveal their architecture. I'm waiting to see over the next month or two what happens when AWS fully integrates them and what features they add. I am seriously reconsidering my choice of using GameSparks. Their messaging features and authentication stuff is hard to beat tho. I hope they can sort out their data persistence because it's so critical to any serious game.

3 people like this

Drew, looking forward to seeing continued feedback from you and others. I'm one of the new users Dylan mentioned and don't exactly find the current setup intuitive, ie, no count / length for a data type; I'd assumed this was for performance reasons.

I'd previously tried PlayFab and found while it was step into it wouldn't scale for even some of the simpler features i was trying to implement (like a global marketplace). I've only been playing with GameSparks for a couple of days and am finding it (seemingly) much more powerful + flexible, I'd assumed with the usability tradeoff. If your performance tests are showing worse numbers that is a bit troubling... what conditions / operations were you testing?

Dear support, in your previous answer you did not mention if the Geo features (geo spatial indexes) are going to be implemented soon or not. This is a major break point for us that prevents from switching to the (new) Game Data Types feature.

Can you give feedback on the missing features in this ticket when we can expect some improvements ?

I don't know if it's been said before, but the entire GDS API looks like a subset of Amazon's DynamoDB. I get this sense from the notations used for data typing, index limitations, and other little bits here and there. Amazon's acquisition may or may not be coincidental to that integration. At very least, it was probably seen as a cost management decision for the original team.

If any of that is true, DynamoDB offers very little in the way of built-in aggregate functions and there are no geospatial data types.

Since there have been no blog posts since last July and the Twitter feed is essentially a recycled loop of tutorial links, I'm guessing very few resources have been applied to GS since acquisition. As with many aspects of the game data API it looks like we're left to roll our own solution with an incomplete framework.

Login to post a comment