2.00 Core Player with level pack files, or keep the "one EXE = whole pack" model?

[namida]

Final decision: A single player EXE that loads data files; with a seperate (but all-in-one) editor.

So - some people have found the current model of each pack/game having its own seperate EXE convenient, and in some ways, it is.

However, there are also some downsides to this - a pack won't get updated to newer engine versions (or graphic set versions, etc) unless the creator actively chooses to make an update; to give an extreme example, GigaLems is still on NeoLemmix V1.30n-D. Having a single core player, with data files for a pack's levels, custom graphic sets, etc would significantly reduce this issue, as well as allowing settings to be shared between players more easily (although doing so is not out of the question with a one EXE = one game setup). Another advantage is that more of the related tools could be built into the main EXE, rather than having multiple seperate apps.

So essentially - would you prefer that NeoLemmix's current model is kept, or a move to something more similar to other engines where a single program is used and any games / packs for it are just addon data files? Just for the record - this will not mean that a pack will suddenly become hundreds of files. It'll still be one file per pack when distributed, but rather than that file being an EXE, it'll be a file which is loaded by a single NeoLemmix EXE.

[GigaLem]

I...dont know about this...

[Simon]

Hundreds of different files in a well-organzied tree.

This is still one file, which is called a directory.

Apart from running the game, you can then use normal tools which everone has on the data. This allows pack users to find mistakes when something breaks eventually.

With the binary blob, if one level gets updated, the designer must recompile the binary blob. Then he must upload the fat blob. Then others must download the fat blob instead of only one level. Graphic sets are inaccessible for other people.

-- Simon

[namida]

I'd be willing to support such a setup, but not to enforce usage of it. If someone wishes to distribute their graphic set, or level pack, or entire fangame as a single file, the option will be there to do so; in fact this would be the encouraged way of doing things (with a directory tree structure being more intended for the content creation side of things). I'm also considering having some kind of "read-only" mode for such files, though I'm yet to come up with anything more than vague ideas on exactly how this might be implemented. Perhaps furthering this, the option could be there for a game's creator to choose "everyone can take the graphic sets from this pack and use them (but not modify them), but the levels cannot be used in any way other than playing them".

This could potentially be especially important if I do indeed go for cross-platform; not every user is going to be savvy as to the differences between platforms, and anything that can be specified by the user (perhaps the filename of a music file) could therefore potentially break due to differences in valid characters or case-sensitivity in filenames.

[IchoTolot]

But one point needs to be mentioned about Core player with level pack files:

Let's not take the route: Change the active pack (out of plenty) in the options menu and have only one at a time active.

A Lemmini-type pack or even level browser would be the best solution here for this option. Packs are automatically recognized out of the folder and displayed in the menu browser.

[607]

I think I'd prefer needing two files: the player and the pack, instead of the player including the pack, as it is now.

[ccexplore]

It's worth pointing out that for Windows anyway, there is a facility called file association that is built specifically so that you can double-click on files and have the program associated with that type of file launch and automatically open that file for you.  This would potentially allow levelpaks to be distributed as just levelpaks but still have the convenience of a double-click launch.

Not sure how much it takes to implement this in Delphi (the language NeoLemmix is written in).  All you need is write a few entries into the registry, and the ability to parse the command line for the specified file.

[namida]

I'm not sure how to go about registering a file type, but I'm sure I can work it out. Actually making use of one when opened should be a very simple matter, although again, I don't know off-hand how to do it. But I'm very good at working out how to do things if need be.

[namida]

Oh wow, it seems opinions are very unanimous on this.

[GigaLem]

this does give me ideas for add-on ranks

[mobius]

having a single exe file is handy for distributing to people who just want to play the game and that's it. But for everyone else who wants to more easily edit and customize their own game, I'm gonna have to go with the other option. That's one thing I really liked about Lemmini and Lix; you can easily edit a graphic or sound file and just slip it into the proper folder and the job's done; no compiling necessary (which can be a pain imo).

[namida]

this does give me ideas for add-on ranks

I don't see how this topic would give you ideas? Unless your idea is "let's add my own stuff to other people's packs"... which probably isn't a good idea to be having.

[GigaLem]

i ment my own

[namida]

Okay well. I think it's pretty well agreed that switching to a core player which loads data files (rather than an EXE per game) is the preferred option.

So the next question is - what to do about the editor? There's three possibilities here:

1. Keep the current setup. Some tools may need a bit of reworking, and this may limit what can be done in levels as the Lemmix Editor (from which the NeoLemmix Editor is derived) is quite difficult for me to work out how it does what, and as such, I can't always add new things easily - take a look at how long it took to support custom window orders in any capacity other than "not erasing the data from levels that already have it", for example.

2. Develop a new, all-in-one editor tool (not just levels, but also integrate graphic set editing, etc, into a single app). This is probably my most preferred method. By developing it from scratch, not only will I know exactly how it works and thus be easily able to modify it for new features as needed, but can also make sure it's specifically designed solely with NeoLemmix in mind. The downside is that I probably won't be likely to include support for other formats beyond those of NeoLemmix; while it will be able to import a lot of them, don't expect such a program to be able to edit them and save modified versions.

3. Same as above, but integrate it into the main player EXE. Advantage compared to method 2 is not needing a seperate download, and possibly better integration for playtesting etc; the disadvantage would be that if, say, only the editor has been updated, the whole package will need to be redownloaded. This kind of issue could possibly be minimized with some kind of auto-updater, but I'm not entirely sure about my ability to make such a thing.

[Wafflem]

This is a much better idea, and it tidies up a lot of space on one's computer (i.e. you don't have to download so many players for each game).

Since only one EXE will be used to open up levelpacks/fangames, how will this affects Talismans?