FreeGameDev

Hi,

I'd like to add Gamerzilla support to my engine, but I have questions (actually a lot, sorry). I hope dulsi or someone else can answer those, and please don't be mad if they seem stupid... thanks!

First, I've read main page and the developer page as well. My understanding is, you need a hubzilla server, configured for the game and its achievements, and then, the game should initiate a WebAPI request with a JSON telling the server if/when a gamer got one of those achievements. Is this correct?

If so, then I don't understand the purpose of the trophies json, mentioned on the developers page. Is this file a part of the server configuration (I guess it should be)? There are lots of paths in that file, are those referring to files on the server? And why there's a need for those, when the game is just supposed to notify the hubzilla server with a gamer/trophy/progress triplet?

About the library libGamerzilla, I have some questions too (mostly all local files related).

First, does it have dependencies? It says none, but I think it does depend on curl and jansson libraries at a minimum.

{l Code}: {l Select All Code}

GamerzillaStart(false, "save/");

What is this supposed to do, and what that "save/" directory is? My engine doesn't have such directory at all (it has separate saved games directories depending on the loaded game, there's no engine temp storage.)

{l Code}: {l Select All Code}

int game_id = GamerzillaSetGameFromFile("./gamerzilla/mygame.game", "./");

Again, what are those paths supposed to be? My engine can be compiled as WebAssembly, where these directories do not exists (there's no current working directory at all for WASM). Maybe you could hack a read-only ramdisk for WASM, but there's no way you can store files there permanently.

Going further, I've checked the source. This won't work for me either, because I have a cross-platform interface for accessing files; your Windows implementation does not work on my computer (it would need FindFirstFileW, FindNextFileW and _wstat64, _wfopen etc., because there are non-ASCII letters in my home path); the "getenv("HOME")" isn't portable and won't work (for example on Android my interface uses SDL_AndroidGetExternalStoragePath instead); and again, WASM does not have the concept of directories in the first place (it is simply not allowed to access the local file system, hence opendir is hijacked to access memory only).

Is there a way to eliminate the need for listing directories, creating files and providing my own a file open/read/close hook?

Or as an alternative, would it be possible to implement just the bare minimum of talking to the server about gained trophies, and nothing else? (No file related part at all, no curl, jansson dependencies. I also have my own portable tcp layer, and for WASM you must use the HTTP Request object, no low level access possible. curl not available for WASM in short.)

Thanks for your answers in advance,
bzt

bzt {l Wrote}:First, I've read main page and the developer page as well. My understanding is, you need a hubzilla server, configured for the game and its achievements, and then, the game should initiate a WebAPI request with a JSON telling the server if/when a gamer got one of those achievements. Is this correct?

If so, then I don't understand the purpose of the trophies json, mentioned on the developers page. Is this file a part of the server configuration (I guess it should be)? There are lots of paths in that file, are those referring to files on the server? And why there's a need for those, when the game is just supposed to notify the hubzilla server with a gamer/trophy/progress triplet?

Hubzilla is no longer needed. There is a ,net/react interface. (Of course if you don't want javascript, hubzilla might be necessary. I don't remember if that needs javascript.)

Trophies are not preregistered with the Gamerzilla server. Instead the first time someone connects to a server with a new game, it uploads the trophy list and images.

bzt {l Wrote}:First, does it have dependencies? It says none, but I think it does depend on curl and jansson libraries at a minimum.

curl and jansson are the only dependencies. I'll update the README to call that out.

*Bunch of questions about files*
LibGamerzilla was not designed with WebAssembly in mind. I don't really see how you could design it with WebAssembly. If I use site A for my gamerzilla instance, can the web assembly of site B connect to site A. I don't think that is allowed. I don't want people entering credentials into site B so it can do the connection. To support that you would want to authorize a token that is limited in what it can do which is not currently available in Gamerzilla.

LibGamerzilla expects that you would store a copy of the achievements locally. That is what the second parameter to GamerzillaStart is. Some developers will put it in the game directory. Others prefer a file in the home dot folders. (I prefer the later but LibGamerzilla does not require it.) It could be modified to allow you to not have local copy of achievements but that is not currently implemented.

There are hooks to override the reading of trophy list and images. This is used for the Godot implementation so that everything is packaged together. (It should be used for java as well but I haven't implemented that yet so you have the jar plus all the gamerzilla files.) It is the GamerzillaSetRead function.

getenv("HOME") is only used if you specify "~" in the directory path. The non ASCII letters in home path is an interesting issue. I assumed when you get them with getenv you would get UTF-8 and that would work with the file functions. Is this something you would use? Or does it not matter because of the WASM issues? I can look into how to fix it.

dulsi {l Wrote}:Trophies are not preregistered with the Gamerzilla server. Instead the first time someone connects to a server with a new game, it uploads the trophy list and images.

I see. This is pretty smart actually, thanks for the clearification!

dulsi {l Wrote}:curl and jansson are the only dependencies. I'll update the README to call that out.

Thanks! There's also a ".deps" file.

dulsi {l Wrote}:LibGamerzilla was not designed with WebAssembly in mind. I don't really see how you could design it with WebAssembly. If I use site A for my gamerzilla instance, can the web assembly of site B connect to site A. I don't think that is allowed.

Only if the server sends a special HTTP header allowing cross-site origin. But see my next answer too.

dulsi {l Wrote}:I don't want people entering credentials into site B so it can do the connection. To support that you would want to authorize a token that is limited in what it can do which is not currently available in Gamerzilla.

I agree, that would be an overkill. BTW I was thinking about something simpler, what if the WASM is downloaded from the same server where the Gamerzilla server runs. Then site A is simply the same as site B, no complications (to be honest, I wasn't thinking about separate site A and site B, but you're right, that's a perfectly valid use-case too).

dulsi {l Wrote}:LibGamerzilla expects that you would store a copy of the achievements locally. That is what the second parameter to GamerzillaStart is. Some developers will put it in the game directory. Others prefer a file in the home dot folders. (I prefer the later but LibGamerzilla does not require it.) It could be modified to allow you to not have local copy of achievements but that is not currently implemented.

Ah, I see, makes sense. For that the only solution available for WASM is the LocalStore interface (think about it like huge cookies, certainly not like files, much more like a permanent getenv/setenv interface). BTW I don't think you should implement all, a proper hook interface is more than enough, especially if one can disable the local copy simply by setting those hooks to NULL.

dulsi {l Wrote}:There are hooks to override the reading of trophy list and images. This is used for the Godot implementation so that everything is packaged together. (It should be used for java as well but I haven't implemented that yet so you have the jar plus all the gamerzilla files.) It is the GamerzillaSetRead function.

Nice! This sounds great! Only if there were similar functions for setting the local copy hooks.

dulsi {l Wrote}:getenv("HOME") is only used if you specify "~" in the directory path.

Yes, but on Android there's no such thing. You have to use a special function :-( (Which makes no sense, isn't that supposed to be a Linux under the hood?) Same with mingw (although under Win HOME is usually set, so no probs), but the proper way is to call "SHGetFolderPathW(HWND_DESKTOP, CSIDL_PROFILE, NULL, 0, homedir)" to get the user's home directory.

dulsi {l Wrote}:The non ASCII letters in home path is an interesting issue. I assumed when you get them with getenv you would get UTF-8 and that would work with the file functions.

Yes, that's how it's supposed to be, but unfortunately it isn't (and not just for getenv, with any path). For example "fopen("violá")" works on Linux, but always fail on mingw. You have to convert the path into an array of 16 bit characters, replace directory separators, and use "_wfopen(L"voliá")" (for some reason fopen converts directory separators on its own, but _wfopen doesn't, I have no clue why is that. There are other differences too, for example "remove" removes files and directories as per POSIX, but "_wremove" only works for files, not for directories, you'll need "_wrmdir" for that latter).

dulsi {l Wrote}:Is this something you would use?

Well, yes, there are lots of non-English Windows machines in the wild. Mine happens to be one. (Frankly I never use special characters in filenames, not even spaces, but thanks to MS, the localized version of "Documents and Settings" for example already has some. And people tend to use their own writing system for their usernames, like CJK or Cyrill, in which case localization workarounds with canonized paths do not work either, you have to use UTF-16. For example "C:\Users\Пётр Ильи́ч Чайко́вский", but I have seen paths like "C:¥Users¥宮崎 駿" too.)

dulsi {l Wrote}:Or does it not matter because of the WASM issues? I can look into how to fix it.

Take a look at my fopen implementation, maybe it helps! As you can see, opening a file with UTF-8 in a portable way isn't trivial sadly. (Note: I couldn't solve this for WASM, there only one file can be open at any given time, the one that the user drag'n'dropped, which is the game file. Hence all my fopen does with emscripten is setting the current offset to 0. Here the problem is, the game file can be several gigabytes in size, and all WASM APIs try to load the entire file into memory, which obviously won't work. I needed a method to only read parts of the file into memory, which adds an extra level of insanity...)

BTW, I was thinking how stable the WebAPI is? Is there a specification for it? What I mean by that, for example, would it be possible to write a drop-in-replacement of libgamerzilla in Javascript using HTTP requests only? I'm guessing if one could reproduce the same HTTP requests like the ones curl does in libgamerzilla, then that should just work, right? (With the server part left untouched.)

Thank you very much for you answers!
bzt

Slightly OT, but have you thought about contributing to Okapi? The libregaming.org community (mainly Armen) is working on a ContentDB fork (test instance here: https://games.armen138.com/ ) and that might be a good server to collect achievements as well.

Julius {l Wrote}:Slightly OT, but have you thought about contributing to Okapi?

No, because I did not know about it.

Julius {l Wrote}:The libregaming.org community (mainly Armen) is working on a ContentDB fork (test instance here: https://games.armen138.com/ ) and that might be a good server to collect achievements as well.

Thanks for the tip! My engine isn't game specific, users can create multiple games with the editor. I'm not against adding multiple achievement system options for them. Actually it's good if they have more options to choose from for their games! I'll look into Okapi too.

EDIT: hmmm, I'm a bit confused. I've read the API spec, but it doesn't look like it supports achievements or trophies. Do you have a better link maybe?

Cheers,
bzt

Not yet, I was actually asking Dulsi to maybe add Gamerzilla backend support to Okapi

Julius, is Okapi your project? If so, I have two suggestions:
1.) Could you add an "About" link and page, explaining what it actually is?
2.) The text (in the FAQ) mentions ContentDB, but it is actually a ContentDB fork, right? So it should not name itself ContentDB in the FAQ.

And some critique:
The pages look good with the dark theme. It's all nicely formatted.
And I like that they refuse non-free games.

Greetings
Peter

Julius {l Wrote}:Not yet, I was actually asking Dulsi to maybe add Gamerzilla backend support to Okapi

Oh, I see. There was no "addressed to" in your post, so I thought you are offering an alternative.

Anyway, if (or when) Okapi has an achievement system different to Gamerzilla, I'd gladly add that too! I'm planning to implement only the protocols, that the users can configure in the editor for their games to their liking.

Cheers,
bzt

No Okapi is a fork of the ContentDB system from Minetest and made by Armen138 (who is a member of this forum AFAIK). It is very much a work in progress, so some references to ContentDB remain. The idea is to have a Steam like website for FOSS games, likely to be hosted on libregaming.org.

Julius {l Wrote}:The idea is to have a Steam like website for FOSS games, likely to be hosted on libregaming.org.

I like the idea.
(I once said I think they should list non-free games, too. I changed my mind.)

Maybe add Patreon or similar?

Greetings
Peter

I agree, pretty good idea! I would choose libregaming.org for my games over itch.io any time, no brainer!

About non-free games, I think we should separate that into two sub-categories: non-free game as in not FOSS game (those are out of question, I agree), and non-free game as in the game is free per se, but has some non-libre assets (I think these might be ok to be included, because it's pretty rare that all the assets are libre too).

Cheers,
bzt

Yes the plan is to have anti-feature tags similar to f-droid.org for games that have non-libre assets and such.

bzt {l Wrote}:BTW, I was thinking how stable the WebAPI is? Is there a specification for it? What I mean by that, for example, would it be possible to write a drop-in-replacement of libgamerzilla in Javascript using HTTP requests only? I'm guessing if one could reproduce the same HTTP requests like the ones curl does in libgamerzilla, then that should just work, right? (With the server part left untouched.)

The WebAPI is not documented. It suffers from having been designed with Hubzilla's implementation. The dotnet version implemented the same API so I didn't have to make changes to libgamerzilla. It shouldn't be hard to do in javascript. I will see if I can document it in the nearish future.

As for Okapi, I haven't looked at it. I'm not sure if they would want to add support. Gamerzilla isn't restricted to open source games. I'm not interested in making it restrict the games allowed as that defeats the point of the system. I want a common achievement system for all games not one restricted to open source games. Someone could certainly run a system with that restriction but I'm not interested in doing that.

dulsi {l Wrote}:I want a common achievement system for all games not one restricted to open source games. Someone could certainly run a system with that restriction but I'm not interested in doing that.

I can understand that. But does it hurt if one server using Gamerzilla is restricted to open source games? I mean there can be other servers. (And every server is restricted in some way.)

Edit: I think the Gamerzilla software and a server using it are two distinct things. But maybe you want only ONE server for Gamerzilla?

Greetings
Peter