next »

[eclectocrat]

A warning about the python+qt concept is it seems like it will tend to produce very big binaries just for the updater. However it still sounds really useful as a way of getting a rapid prototype together.

One thing I never quite got. Do you really need a gui as complicated as qt? If you need lots of stuff like displaying webpages and patch notes then sure, but if all you do is throw up an "UPDATING..." progress bar at startup sometime then integrating qt might be more work than just making simple OS-specific gui window things.

Agreed. That's why I'm using the standard Tkinter distro. It's totally suitable for basic dialog boxes and such. The GUI code so far is about 25 lines or so and will work on X/OSX/Windows and just about every OS written in the past 20 years. I'm going for compatibility.

For a project like this, limiting scope is pretty easy. The requirements are well defined, and QT's GUI is overkill X10. That being said, if it was a QT based project then it'd also access QT's libraries for HTTP, filesystem, md5 hash, etc. Doing each of those portably isn't exactly difficult, but it's tedious and unnecessary.

[Triplefox]

Another suggestion: XULRunner. This is perhaps an even bigger sledgehammer than QT.

It actually sounds very attractive if a fancy GUI is wanted later. I used it to build a standalone Chatzilla on Win32 and the resulting uncompressed footprint is 1.49MB - better than Python and competitive with most cross-platform toolkits. And we can code most of the app in JS. And if anything's missing for the networking or file management side of things -- create a shared lib for ctypes or a plugin for XPCOM. That might be a deal-breaker if nobody's willing, but it also looks way easier than maintaining a full stack for every OS.

https://developer.mozilla.org/en/XUL_Reference
https://developer.mozilla.org/en/XUL_controls
https://developer.mozilla.org/en/XUL_School/Local_Storage
https://developer.mozilla.org/en/JavaScript_code_modules/ctypes.jsm
https://developer.mozilla.org/en/js-ctypes/Using_js-ctypes
https://developer.mozilla.org/en/XUL_School/XPCOM_Objects

[mcc]

Another suggestion: XULRunner. This is perhaps an even bigger sledgehammer than QT.

It actually sounds very attractive if a fancy GUI is wanted later. I used it to build a standalone Chatzilla on Win32 and the resulting uncompressed footprint is 1.49MB - better than Python and competitive with most cross-platform toolkits. And we can code most of the app in JS. And if anything's missing for the networking or file management side of things -- create a shared lib for ctypes or a plugin for XPCOM. That might be a deal-breaker if nobody's willing, but it also looks way easier than maintaining a full stack for every OS.

https://developer.mozilla.org/en/XUL_Reference
https://developer.mozilla.org/en/XUL_controls
https://developer.mozilla.org/en/XUL_School/Local_Storage
https://developer.mozilla.org/en/JavaScript_code_modules/ctypes.jsm
https://developer.mozilla.org/en/js-ctypes/Using_js-ctypes
https://developer.mozilla.org/en/XUL_School/XPCOM_Objects

This brings to mind something I wondered when I first heard Cellulose's proposal. How hard would it be to just adapt the Firefox auto updater into a standalone thing?

[Evan Balster]

Maybe not very hard, but it's an unknown that could turn into a deep well if we're wrong.  And, as evidenced by progress, it's not a difficult thing to make from scratch.


Incidentally, I'm very amused (but not disapproving!) of how we're attacking this problem in a very programmerly way -- using favorite technologies and debating the virtues of each for the purposes of a simple problem.

Keep up the good work, all.

[technogothica]

Incidentally, I'm very amused (but not disapproving!) of how we're attacking this problem in a very programmerly way -- using favorite technologies and debating the virtues of each for the purposes of a simple problem.

I think it's awesome what we're doing here guys.

I think XUL is a great idea too. If anyone knows how to make it work, please do so! Also, don't be afraid to chime in with other ideas. Use your strengths! Divide and conquer!

[Christian Knudsen]

Just chiming in with my moral support for this project!

Quick question though: When updating, the launcher will always download the latest full version of the program package, correct? It would be nice if you could just have it download the files that were changed since the latest version, but that would of course also require that you define the update procedure from versions that are older than the previous version.

[technogothica]

Quick question though: When updating, the launcher will always download the latest full version of the program package, correct? It would be nice if you could just have it download the files that were changed since the latest version, but that would of course also require that you define the update procedure from versions that are older than the previous version.

Agreed. I'm using MD5 hashes for that reason. The updater hashes the local files and compares the hash strings against the ones listed in the version info text file. If the hashes are different, then the file on the server must be different, so it is downloaded. If the hashes match, the file is the same so no download required.

[Klaim]

I've been thinking about all this:

 1. The most efficient way to provide a user-customizable interface would be by using an html display. Better : an embedded browser, allowing (like for MineCraft and my own game) to get the last informations from a server. Then the whole interface would be a "canvas" with a web page in it. A default page would be provided if the user don't have one.
 2. 1) suggest that it would not be a tiny binary. However, depending on the game's size, it might not be a problem. In my own case, I already use a library embedding Chromium (Awesomimum/Navi) si I'm alreay ready to use it as it's a shared library.
  There are other ways to play a web page (with some javascript engine) but I'm not sure of the cost.
 3. About the configuration informations, there have to be a way to write the configuration in a file (xml,yaml, json, ini, whatever) once the configuration have been setup by the user. Then the application will be able to read it on launch.
 4. One important feature : the updated have to be able to autoupdate, and should do it as it's very first action.
 5. I'm thinking that most of us could have different needs for an auto updater. So I thinkk I'll just follow what you guys will do, but still plan for my own updater, and try to separate it from my game enough to make it usable if it's generic enough for others. That mean that maybe I'll help on code here, maybe not, but anyway we'll be able to try things differently and see what works or not. I'm not yet at the point it's necessary for the updater to be setup so I'll wait some months to start my own and will check regularly here see if what you do fits my needs. 

[Evan Balster]

Klaim-


Regarding what you say there, just a few points:

- The html display might as well be something in the game itself if the autoupdater is typically invisible.

- The configuration options could be embedded into a Linux or Windows binary by appending the data onto the end; it's a well-known trick and avoids confusing non-tech-savvy users with compressed archives.

- A binary autoupdater would be unable to autoupdate itself on Windows without the aid of an external program or process.  (as far as I understand)  Furthermore, one sufficiently simple in scope will likely be robust enough never to need updating.  Hence my insistence on feature-minimalism.


However, if what you're talking about is to be a separate project, the more power to you.



Technogothica-

If you haven't learned about it yet, Windows stores the application data folder's name in an environment variable "APPDATA".  On Windows Vista (with mintty bash) I get this:

Code:

Evan@Hal-III ~
$ echo $APPDATA
C:\Users\Evan\AppData\Roaming

[Klaim]

- The html display might as well be something in the game itself if the autoupdater is typically invisible.

Depends : if the updater is downloadable alone, then it have to be separate. If it's in the game, like for Minecraft, that suppose that the game is 1 exe only. If it have dlls and they are not meant to be linked while the application is running, then it's a problem.

Personally I would prefer a stand alone executable updater separate from the game : if I make a flash game, I still can use the stand alone updater for it, while if it's a library or something similar I'll have to use a similar language or some language binding that is hell.

Provide a customizable executable for the updater and people will modify it's configuration at will for their games.

- The configuration options could be embedded into a Linux or Windows binary by appending the data onto the end; it's a well-known trick and avoids confusing non-tech-savvy users with compressed archives.

What are you talking about? I don't understand at all what you mean.

I'm talking about options like the game's resolution or some effects to activate or deactivate or buttons configuration. If you want to communicate with the game, without knowing how the game is made, you'de better put this kind of configuration in a text file, whatever the text format.

If the updater is in the game then yes it's not a problem, but then you have the problem of the language...

- A binary autoupdater would be unable to autoupdate itself on Windows without the aid of an external program or process.  (as far as I understand)  Furthermore, one sufficiently simple in scope will likely be robust enough never to need updating.  Hence my insistence on feature-minimalism.

What? How do you think MMOGames does their updater's updates? Of course it's possible: until you setup some very specific code inside your executable, an executable can be launched as many time as the user wants. For a lot of games, using the resources of the hardware makes impossible to launch it twice, but it just crash.

However, if what you're talking about is to be a separate project, the more power to you.

It was random thought but as I said I think I'll make my own implementation and it will be helpful for both.

[Evan Balster]

Minecraft's updater/launcher is actually separate from the game code; while Minecraft's updater is native, the game itself is java, and all its compiled code is downloaded to an application data directory.  That updater is incapable of replacing itself.  The updater being worked on here will work the same way; it'll be a separate binary which can be configured with a web address for the actual game, along with other descriptive data such as the game's name and an icon.  (I was talking about launcher configuration rather than game configuration.)  The config data (other than the icon) can be appended to the updater/launcher binary so it's still one file and will be maximally trivial to use, not requiring a zip archive or similar.

As for the Windows thing, Windows puts a lock on an executable file when it's in use, and that lock is both difficult and dangerous to remove, as the OS is liable to continue loading information from it while it runs (as I understand) -- hence, a binary autoupdater cannot safely replace itself and should be kept separate from anything that will need updating.

Anyway, just clarifying.  Good luck with your implementation.

[technogothica]

If you haven't learned about it yet, Windows stores the application data folder's name in an environment variable "APPDATA".

No worries In C/C++ I use SHGetFolderPath(CSIDL_APPDATA)

Incidentally, it occurred to me that in most cases the game will be installed in the Program Files folder, or some other user-specified location. This means that, depending on how the game was installed, the registry might be required to find out where to put the downloaded game files. Also, on Vista and higher, it will require UAC privilege elevation to write to the Program Files folder.

I'm not worrying about those things right now - I'm just reading and writing to the current working directory.

The configuration options could be embedded into a Linux or Windows binary by appending the data onto the end; it's a well-known trick and avoids confusing non-tech-savvy users with compressed archives.

While working on this it occurred to me that a large portion of the configuration could be put in the version information file on the server. This could include the command line string to actually launch the program once updated. This has the added benefit of being able to change that information for each update.

The only thing that absolutely needs to be stored in the launcher is the URL of the version information file, and any minor cosmetic stuff like title bar text.

[Tycho Brahe]

Has anybody suggested using FTGL for user interface stuff yet? I've just started using it, and it seems pretty good!

It's pretty easy to get going with, plus it's pretty lightweight, as in, you include individual headers for all the widgets you need. It's also cross-platform.

so yeah.

[technogothica]

It was random thought but as I said I think I'll make my own implementation and it will be helpful for both.

I say go for it Klaim Everyone wants something different from their installer/updater. The insight gained from each version will be valuable to all.

[technogothica]

Has anybody suggested using FTGL for user interface stuff yet? I've just started using it, and it seems pretty good!

I'm a bit confused. As I understand it, FTGL is a font rendering library for OpenGL. Or am I missing something?

[Tycho Brahe]

Oops, I meant FLTK, an easy mistake to make 


I need some sleep

[Evan Balster]

Technogothica - to avoid UAC complications, we can always just install the game in the appdata folder.  Again, this is Minecraft's solution to the problem.  The drawback is that it's difficult for the user to locate the files manually, though (other than uninstalling the game) I can't think of many reasons why they might need to.

Offloading the command line string to the server also sounds good, as long as it won't break the program when there's no internet connection.  Saving it in the installed game's location would be necessary.


14113 - Again, GUI libraries are likely overkill if we have anyone with platform API experience; in all likelihood we'll just have a little progress bar when updating, a few snatches of status text, a configured title (the name of the game) and a name for the install location (eg, "mygame", which would be C:/Users/Administrator/AppData/roaming/.mygame" on windows, "~/.mygame" on Linux, something similar on OS X)

Also, DLL dependencies under Windows or Linux (to a lesser extent) are a killer.

[Tycho Brahe]

Ah- thats a good point. I've only been using it on linux, so I'm not really aware of any dlls, but it probably has them

[technogothica]

Offloading the command line string to the server also sounds good, as long as it won't break the program when there's no internet connection.  Saving it in the installed game's location would be necessary.

Good point

[JobLeonard]

Incidentally, it occurred to me that in most cases the game will be installed in the Program Files folder, or some other user-specified location. This means that, depending on how the game was installed, the registry might be required to find out where to put the downloaded game files. Also, on Vista and higher, it will require UAC privilege elevation to write to the Program Files folder.

Is it really necessary to have an installer for this application? One of the things I like about Minecraft is that you just download one program and run it, no admin passwords required. I like portable apps, although I suppose the downside is that regular users wouldn't know where the actual data is saved, making uninstalling a hassle.