We're archiving the forums and going read only! You'll be able to see old threads, but new topics and replies have been disabled.

Visit the Game Jolt community for new questions and conversations.


Hey Devs,

We've been rolling with Game API v1 for a while now. If you're not familiar with it, check it out here: http://gamejolt.com/developers/achievements-new/

Let's start thinking about Game API v2!

What do you want in an API that v1 currently isn't doing yet? How can we build on top of the v1 platform, making things better, cleaning things up, and implementing new features?

Note that the Achievements API will change to become the Game API. No longer will it be mainly about trophies and scores. It'll be about giving developers a great and stable platform to build out their future games on without worrying about the scalability of going from hundreds of players to hundreds of thousands.

What are your wants? What does your heart desire? How do I make you happy!?

Go!


## Current Ideas ##

Global Changes

Compressed data exchanges. For example, transferring a 16MB data storage item would take a while on slow connections.

Pagination between result sets with offsets and limits. (example: going through all the scores for a game)

Multiple commands in one call. Basically a /multi endpoint. Reduce network latency. Usefull when updating tons of data storage keys at time. Could be transactional.

Server Time

There needs to be a way to get the current server time.
http://gamejolt.com/community/forums/topics/date-and-time/1258/

Event Tracking

Allows you to gather stats and information on how people are using your games. Could be used to split test certain things in your game in real time, or allow you to push future updates to the game based on actual data of how your game is being used. Can also help weed out cheaters, I'd imagine.

Guest Accounts

This would allow any game to create a guest account to store stuff like trophies and scores. They would then at any point be able to sign up and claim these gained achievements for this new account on Game Jolt.

User Friendships

Allow devs to query users by friendships. Possibly allow users to make friends directly in games. There are a lot of possibilities with this one.

Scores

We currently don't allow them to see what rank they are in the leaderboard. Should maybe allow you to query any user to see their best score and what rank it is. That way it can tie in with friendships above.

Game Based Chat

Use the current GJ chat infrastructure to allow games to hook in and offer a public chat in their game. Could also allow multiple rooms for each game. Or direct messaging between players.

Geolocation

Offer a way to give location information for gamers. Should work on as many devices as possible. This should support trying to find other people close by to perhaps game with, etc. There would need to be permissions around this. User would have to explicitly allow a game to retrieve this info. Probably more useful for mobile games.

Social Integration

Allow devs to post on user's FB walls and twitter feeds. Should hook into the fact that we have their twitter and facebook accounts already. Permissions, permissions, of course!

Pub/sub

Allows real-time publishing of messages across channels between subscribers. This is being built out already, but sort of secret at the moment. Opens up the door to lots of things.

Registration

Users need to be able to sign up for Game Jolt through games. This is hard and needs to be thought out in depth. Should work with game libraries, by automatically attaching the game they signed up through to their Game Jolt account and allowing them to get notifications on new development and stuff through game news.

Matchmaking

Based on previous match scores, team up people that are similar in skill level.

Game Jolt Cloud

Data storage is great, but could be improved on. Stuff to think about: transactions, better querying support, better ways to update, maybe JSON objects rather than simple key/value.

Game Jolt Cloud Security

For global game storage security is an issue. Maybe we can allow certain rules on certain keys. So, you may have a "total_kills" value, and you can set rules such as, "Integer, never decrement, max increment at any time (10), call throttling by user (1/30 seconds) etc..."

Central Server

The whole idea of a Game API is to allow developers to not have to build out this infrastructure themselves, as it can be costly, hard to scale, hard to maintain, etc. However, for the games that require extra security, or perhaps for MMO type games that would need to have control of the game world, allow them to make a central server that all the clients talk to, which would then be funneled to Game Jolt. Also allows another layer of security. This would be for advanced users. Maybe we would only allow some people to do this? Don't want games to stop working in the future just because they couldn't keep their servers up.

## Suggested ##

Offsite ad-sharing **(from newt)
Microtransactions**(from new)


Page 1 of 77 replies.

over 12 years ago

Its not bad as is really.

I guess some monitzation would be nice. Possiblly addshare for off site.

Perhaps even some microtransactions.

Also I think some social networking might be a good idea, like "Tweet this", or post to Facebook.

over 12 years ago

You've already had a lot of great insight- you should really note all your ideas down before we state what's already been said

#emotions_dlg.tongue}" title="{#emotions_dlg.tongue}" />

over 12 years ago

User Registration will be great.

over 12 years ago

Some of those features are very interesting, tho these are primarily multiplayer features.

A couple of them are really heavy to implement, especially for different languages/tools. I hope you know what you're getting into, and that you have enough helping hands.

The only thing I wish is Linux-integration for the C/C++ interface but luckily erakko already provided a solution.

"... There would need to be permissions around this. User would have to explicitly allow a game to retrieve this info. ..."

Very important!

Last modified on August 24, 2014 by Maus @MausGames

over 12 years ago

@Maus Games:
We will do this API like we've done the previous. We will create a REST API that any game can access. It'll be up to the community to build the libraries that work with this API, though. The same goals still exist, as well. It should be simple enough to implement for any game that has the ability to do HTTP GET calls and MD5.

over 12 years ago

I honestly can't think of something else to add, all those ideas seems perfect.

over 12 years ago

Being able to fetch he current Game Jolt level and how much xp you need to level up would be interesting.

EDIT: I didn't know that Polan. I couldn't find that on the API page before. Sorry for the inconvenience.

Last modified on May 5, 2013 by (T)Bubba @Jesp

over 12 years ago

I may have missed it and it may already exist, but a testing environment would be great (cf PartnerNet at MS)

Being able to deploy and test your game on Gamejolt on a parallel environment (private and not visible to others, or maybe to other devs), achieve and remove trophies for this environment, enter values on leaderboards, all without affecting official "live" environment would be cool.

My 2 cents :-)

Arnaud.

over 12 years ago

Bubba we can already fetch user avatar.

over 12 years ago

Yeah this sounds awesome.

Pretty complete list, here, I think.

over 12 years ago

Before talking about adding feature, I'd share all the little things that annoyed me while writing the Unity wrapper.

I know when you sending the response (be it string, json, xml or dump), every value will be a string, but it'd be great if it somehow respect the value type expected. E.g the achieved variable of a returned trophy can return when the trophy was achieved by the user, or "false" if they haven't achieved it yet. This variable should only return true or false. Maybe add another one like achieved time if you really want to pass that variable.
With the same idea, primary for high score table should return true or false not 0 or 1.
It's not a big deal but still need to do some work around and casting to make it works.

Anyway, back on API 2. Everything looks good so far.
I definitely +1 the server time and the parallel environment Captain Nono is talking about.
I'll also take the opportunity to push my request again: http://gamejolt.com/community/forums/topics/request-reset-achievements/1454/

I also like the idea of event tracking but there is some analytics website arround there. Maybe it'd be great for GameJolt to focus on what can directly benefit the player. You'll probably do an awesome work but don't try to do too much either.

Last modified on February 27, 2014 by loicteixeira @loicteixeira

over 12 years ago

It would also be a great help, if you can retrieve the visible and secret value of trophies, and of course the order defined on the web interface. That way the whole trophy-system can be integrated more dynamically into a game. But it's just a nice-to-have feature, nothing mandatory.

Last modified on August 24, 2014 by Maus @MausGames

about 12 years ago

As I said in another thread, streamlined, yet colorable assets would be nice for the login gui and achievement popups.

Also, a bigger logo we can present the user so he can click on it to enter his credentials.

Last modified on August 2, 2013 by GothSeiDank @GothSeiDank

about 12 years ago

I read in the OP realtime comments, not sure if what I'm about to suggest is even possible, but what about updating variables online in realtime? This would be great for multiplayer, though I never really messed with the gj api so idk if something like this already exists.

about 12 years ago

Data Storage can be looked at as a way to update variables online in relative real time. That's already implemented in v1. Should check it out. It's pretty powerful! =]

almost 12 years ago

When displaying high scores in my game I have to make multiple API calls to get the top scores for multiple tables. It would be nice to have an option to send in multiple table IDs just like the fetch user commands.

An easy way for users to upload screenshots from our games and have them tied to our game's profile somehow would be great. My game lets you submit screenshots to Facebook, but it would be great to have the option to submit them here instead.

almost 12 years ago

The screenshot idea is excellent!

over 11 years ago

The ability to find the player's leaderboard rank is something I really need. Is there an eta on V2? I'm trying to decide whether or not I should wait for the new api to release my game. But anyway, everything on the list looks awesome. The only thing I can think to add would be to have some sort of "time played" mechanic.

about 11 years ago

Is this still coming at all? I understand it's probably a lot of work, but a "first release" with only some of the features would be nice too.

Last modified on June 25, 2014 by Florian van Strien @flori9

about 11 years ago

Yes! There's an API v1.2 queued up and almost ready. I planned to release it all this month, but then I got really busy with contract work. So, instead, expect it next month (July). Probably late in the month.

It'll be a subset of some of the changes that are planned for v2.

It'll be mostly backwards compatible, although there are a few things I need to do for security reasons that won't allow it to be a straight upgrade.

Either way, v1 will continue working.

about 11 years ago

Great! I'll be ready to update my GM:Studio API then (and maybe make it a bit easier to use at the same time).

Edit: Hopefully these security reasons don't include dropping MD5/SHA1? Because it's quite difficult to implement other hashing methods with many languages (including GameMaker: Studio).

Last modified on June 25, 2014 by Florian van Strien @flori9

about 11 years ago

Great looking forward to this! Can't wait to actually see the new version I've been hearing about, in working action! I will certainly have plenty of fun with this :)

about 11 years ago

Any idea when 1.2 will be ready?

about 11 years ago

Is there any plans of implementing a master server to the platform? The session system is almost an option, but fails to be utilizable because of the lack of possibilities to customize fields to inform server IP, map name and things like that.

Last modified on August 9, 2014 by Tab @Ascii1457

about 11 years ago

@Florian We're working on rewriting the whole Game API using nodejs. It'll provide a better base for this sort of thing, I think. Will try to start updating on the progress of that soon, though right now only about half a day per week is able to be set to working on it.

When that's done, v1.2 will be ready for release.

You can see the planned features that we have for it in the new documentation (though it's not fully set in stone yet): https://github.com/hworld/gj-doc-game-api/blob/master/v1.x/index.md

After that's all done v2 will start to be planned in the open with suggestions from everyone.

@Tab What sorts of things would you like a master server for? Maybe you could add a new forum topic about it so others can discuss.

about 11 years ago

Okay, I am certainly looking forward to it but do take your time. The current API is awesome enough that I can wait longer (and I do understand that you have other things to do!).

Would be great if you could share the progress on Tumblr or anywhere else so that we can see how it's going.

And what does it mean that version 1.2 will contain "user tracking features"?

about 11 years ago

Hmm, where did you hear about the "user tracking features"? In the v2 thread, or for v1.2?

about 11 years ago

Under Version History on https://github.com/hworld/gj-doc-game-api/blob/master/v1.x/sessions/index.md Sorry, should have been clear about that in my post earlier. Was just wondering what that meant.

about 11 years ago

Oh yeah, forgot to document it. It's a new endpoint to check to see if the user has an open session or not. I just put in the documentation for it here: https://github.com/hworld/gj-doc-game-api/tree/master/v1.x/sessions

I'm not fully happy with it. I think it should return the status of the user "active" or "idle" as well when the success is "true".

Would also be cool to have game-specific statuses in the future.