next »

[Snowdrama]

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.

Granted, Minecraft Prevents you from manually changing the location of the "install" a quick fix is to add a Steam-esk feature, add a options menu that allows the exe to "Delete Local game data" Removing all but the Launcher exe.

[technogothica]

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.

No problem, I'm going to follow Cellulose recommendation of using the user's Application Data directory.

It's actually a good approach, up to a point. I does have its shortcomings, and I intend to address those in the future. For now I'm concentrating on what you guys want/need right now.

[JobLeonard]

Granted, Minecraft Prevents you from manually changing the location of the "install" a quick fix is to add a Steam-esk feature, add a options menu that allows the exe to "Delete Local game data" Removing all but the Launcher exe.

Having never felt the urge to uninstall Minecraft, I did not realise this

For now I'm concentrating on what you guys want/need right now.

For the record: I'd like to point out again that I'm not a developer, just an end-user chiming in with ideas on the subject. When it comes to wants and needs of the actual developers, their opinions should weigh stronger than mine.

[technogothica]

If the game doesn't use the registry, or do other things like create shortcuts, then uninstall is as easy as deleting the folder containing the game files.

Of course, you need to know what you are doing. Particularly since the Application Data directory is hidden by default. And Microsoft recommends against such approaches in their user interaction guidelines. Not all users are egg heads like us.

[technogothica]

When it comes to wants and needs of the actual developers, their opinions should weigh stronger than mine.

Actually, the opinions of the end user are far more important, because you guys are the ones that suffer from bad design decisions. If you're not happy, we're not happy

[JobLeonard]

Well, then I hope more end-users chime in, because otherwise if you follow my advice and it turns out to be horrible, it's all my fault 

[technogothica]

Well, then I hope more end-users chime in...

I hope so too

...because otherwise if you follow my advice and it turns out to be horrible, it's all my fault 

He he, don't worry If a user recommendation sounds like a bad idea, that's usually the point when the developer starts to take liberties with the design. As long as we know what you want, and we can see a better way of doing it, it'll all work out

[_Tommo_]

Still, the "launcher" thing is cool and everything, but having something that looks like the real game, has to be downloaded and mantained ON TOP on the game itself, to me is very confusing to the end user.

Minecraft can get away with this because the whole thing is really lightweight and trasparent - some kb for a launcher that never changes.

Having a complex program using Qt/Chromium/Webkit/Whatever, or anything more complex than a simple downloader looks very wrong to me.
I think this was going in the right direction at start, with simple goals, one language and no dependencies - now it's a bit becoming a programmer playground. And that's never fine.

Anyway, for an end user perspective, the most awesomest thing would be putting the launcher in a website: you visit it, you get/update the last version of the game, then you play.
Without even knowing from where it came, or where it is installed locally.
Too bad it would require an heavy-weight access to the client PC...

[JobLeonard]

I think you're misreading the situation a bit: the goal is still the same as in the beginning (which is pretty much what you described), right now the guys that would like to take a stab at programming this are discussing how to do this, and are trying out different things to see what would work. I'm sure one solid easily modified cross-platform launcher will come out of all of this experimenting in the end.

Also, I don't see how from an interface perspective the Minecraft launcher is different from the launchers of a lot of heavyweight games. Granted, I haven't been playing much games lately, but Neverwinter Nights for example had a launcher with an update feature. How is that different from the Minecraft launcher to the end user?

And I think installing/uninstalling from the browser, with everything else hidden, while not actually running the game in the browser would make a lot of people paranoid. I'm not sure if that actually would be the ultimate approach.

[technogothica]

Having a complex program using Qt/Chromium/Webkit/Whatever, or anything more complex than a simple downloader looks very wrong to me. I think this was going in the right direction at start, with simple goals, one language and no dependencies - now it's a bit becoming a programmer playground. And that's never fine.

Not to worry. In my experience the fastest way to get a solution is to just start working on it.

If we design three (or more) separate programs in isolation, then compare notes at the end, we'll get there a lot faster. If we sit around debating the merits of one approach over the other, we'll never get anything done.

I'm not concerning myself with portability. My windows prototype is 90% complete. In the process, I've seen many opportunities for portability, but also many hidden "gotchas" that I wouldn't have thought of. That proves in my mind that Cellulose's original vision of separate programs for each platform is the correct one.

I'm eagerly anticipating what the other guys come up with and how they address certain platform-specific issues. I'm sure we will be able to find a pattern common to all versions that will allow us to produce a unified code base.

I agree with you on the Qt/Chromium/Webkit/Whatever issue. That said, I still think there is value in at least giving it a try, provided those that do have the time to work on it. One thing that has become clear to me while following this thread is that one size doesn't necessarily fit all.

Anyway, for an end user perspective, the most awesomest thing would be putting the launcher in a website: you visit it, you get/update the last version of the game, then you play.
Without even knowing from where it came, or where it is installed locally.
Too bad it would require an heavy-weight access to the client PC...

The problem is, that's exactly how malware works. I'm sure I'm not alone when I say that most users will probably dislike that approach on the grounds of security. Plus, the security protections that are already present in today's browsers make that a complicated feat of programming.

[Evan Balster]

Technogothica:  It sounds like you're doing good work.  You are awesome. 


I have a thought about uninstallation: what if there's a specific return code that the game can give back to the launcher which causes it to delete game files?  That way, assuming the launcher idles while the game runs, an uninstall control can be present right in the game.

(We'd need to make sure it wasn't a common return code like 0xC0000005 or 0xDEADBEEF or something)

[technogothica]

Technogothica:  It sounds like you're doing good work.  You are awesome. 

Thanks 

I have a thought about uninstallation: what if there's a specific return code that the game can give back to the launcher which causes it to delete game files?  That way, assuming the launcher idles while the game runs, an uninstall control can be present right in the game.

(We'd need to make sure it wasn't a common return code like 0xC0000005 or 0xDEADBEEF or something)

I would probably favor in the other direction. The game itself shouldn't be controlling uninstall, the installer/updater itself should be interacting with the user to manage that.

Of course, that brings us back to the issue of making it into a full installer. If we want the updater to be a real installer, then it should really register itself with the Add/Remove programs list (good citizen and all that).

On a more portable level, the updater could support an --uninstall command line option that causes it to delete local files.

[Evan Balster]

Hmm.  If the updater *is* the uninstaller then that means it'll need to show a dialog every time it runs.

To clarify what I was saying about the return code, imagine the game menu had a button "uninstall game" which, after the user confirmed that choice, called exit(12345).  The launcher, which was synchronously executing the game, would detect the game's return code.  If that code happened to be 12345, the launcher would erase all game data before terminating.  If run again, it would re-install the game.


One other possibility is that the updater could *create* an uninstaller program in the same folder as itself when run, but that could be a bit annoying for desktops.

Either way a command line option is probably a good idea.

[ஒழுக்கின்மை (Paul Eres)]

(if you want this to work with game maker games you may want to do it differently, because, as far as i know, game maker has no way to exit with return codes, although it does have a way to read the command line options)

[technogothica]

Hmm.  If the updater *is* the uninstaller then that means it'll need to show a dialog every time it runs.

Quite so!

To clarify what I was saying about the return code, imagine the game menu had a button "uninstall game" which, after the user confirmed that choice, called exit(12345).  The launcher, which was synchronously executing the game, would detect the game's return code.  If that code happened to be 12345, the launcher would erase all game data before terminating.  If run again, it would re-install the game.

It's certainly doable, though from a user perspective I'm not comfortable with it.

A side issue is the "visibility" of the installation. A proper windows installer will do a bunch of things like adding shortcuts to the start menu and desktop which provide visual cues that the game is installed. Those things are removed on uninstall. The Add/Remove Programs control panel is also the preferred method of managing software installations.

Contrast to the launcher/updater approach where the game itself provides an option to trigger the uninstall. Since the files are stored in the user's hidden Application Data directory, and there are no icons on the start menu or desktop, how does a regular user know whether the game is installed or not? If you run the launcher again, it automatically installs the game again, so unless the user is carefully monitoring disk usage, nothing has really changed from from their point of view.

Bonus chatter: I hate installers that put icons on the desktop without user prompting. Are you listening Adobe?

One other possibility is that the updater could *create* an uninstaller program in the same folder as itself when run, but that could be a bit annoying for desktops.

Yes. An uninstaller could be put into the Application Data directory, provided the user is able to access it via a shortcut, or otherwise run through the launcher.

Which brings us back full circle to showing a dialog every time it runs.

[technogothica]

(if you want this to work with game maker games you may want to do it differently, because, as far as i know, game maker has no way to exit with return codes, although it does have a way to read the command line options)

Yes!!! Excellent point! If anyone else out there is using Game Maker or RPG Maker, or Flash, or whatever else we haven't thought of, please post your thoughts!

[Rob Lach]

it makes complete sense that the updater should handle installing/uninstalling.

Generally I see this gaining the largest acceptance if you don't have to change your game code one bit, so forget about exit codes and the like.

Also I think you guys will need to standardize the publishing end. It'd be annoying if for instance the linux version takes a file manifest and the mac version taps a webapp which checks checksums and the windows version needs an xml that you need to change.

The way I'd do it is all you need to publish is an http server with a seperate folder for each version (ie mac, win). In each folder is a simple list of relative filepaths and their md5 hashes. Everytime the loader runs it creates a local version of that file, downloads the server one, and then you can do a line by line diff to see if the server version is different. If it is, just download it.

The all you would need is a small program the developer would need to run to generate that manifest file. You could easily just add it to your post-compile toolchain. It would make having distributed testers a snap since you could just have them always pulling from your latest build.

Also releasing games would be nice with these loaders since you can release just the updater and it'll always pull the latest version.

[Evan Balster]

What you described, other than making use of manifest files, is more or less the plan already, as covered in previous posts.

Can the config text (URLs and such) be encoded in the manifest?  What about an icon?  I haven't ever used one.

[Rob Lach]

Also a real simple customization option without having to implement web browsers and stuff like that would be just to have an image canvas that displays a info.png. Just have the loader resize to accommodate that image and the developer could put whatever info/graphics/etc on that image they want. They could update that image along with anything else when they release updates.

Maybe also include a button to open a info.txt in the users preferred text editor so you could publish more in-depth release notes/instructions.

[Rob Lach]

What you described, other than making use of manifest files, is more or less the plan already, as covered in previous posts.

Can the config text (URLs and such) be encoded in the manifest?  What about an icon?  I haven't ever used one.

Heh, that's what I gathered.

The "manifest" files I'm talking about will be defined by you guys so whatever you want can be included. I wasn't referring to assembly manifests or java manifests or whatever. I was using the straight up definition as "list of things included", for instance a shipping manifest. Apologies for lack of clarification.