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?

[namida]

They'll still be tied to individual games / packs. That won't change.

The specifics of how things will be implemented (eg. menus) is still to be decided on. The main points come first, then the final details can be decided on later. At the moment, the only coding I've done towards this is some of the very core stuff - reading of files, etc. Not a single part of the menus / interface has been coded yet.

[bsmith]

I can support option 2 or 3 for the new editor.  Right now I am leaning toward option 2.  I have absolutely no problem for the 2.0 editor being just for NeoLemmix levels.

My biggest concern about option 3 is how all the metadata would be managed in a fullscreen mode.  (I assume that NeoLemmix 2.0 will be fullscreen like its predecessors.)  Right now I let the Inspector, Skillset, and Level Properties windows float off to the right of the main editor window so I can have a full height view of the level I am working on and still be able to see critical metadata simultaneously.

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.  '.dat' and '.lvl' are used by so many different programs now - enough that I don't want to make a file association for those (unless it is something like a generic text editor).

[namida]

(I assume that NeoLemmix 2.0 will be fullscreen like its predecessors.)

While the option for full-screen will be there, supporting a Windowed mode is definitely intended.

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.

Yes, I'm strongly considering using more NeoLemmix-specific extensions. I haven't made any decisions about what these might be yet, though - it depends on the overall architecture of files. I would also avoid anything that conveys a general Lemmings implication, in favor of one that specifically relates to NeoLemmix (for example, all of the extensions might start with ".nx"; eg "nxlv" for levels, "nxgs" for graphic set - these are just examples, not confirmed as to-be-used).

DAT compression algorithm is almost certianly going to become a thing of the past; most likely I'll either abandon compression altogether or use ZLib. It'll remain able to import old DAT-compressed files, though, for obvious reasons. While in existing versions, the code to support DAT is already there (and easier to work with), if rewriting the majority of the code, there's little advantage to be gained from using it, especially with it becoming increasingly ineffective with higher-bit-depth graphics; I can only assume the effect would be even more pronounced when higher-resolution graphics are also supported. At this point, there's little reason to continue using it for other formats where it does remain fairly effective (eg. levels) if an alternative such as ZLib, which functions better for the graphics, still functions very well for these other formats too.

[ccexplore]

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.  '.dat' and '.lvl' are used by so many different programs now - enough that I don't want to make a file association for those (unless it is something like a generic text editor).

We can potentially make it user configurable which extensions to do associations for.  And we most certainly should warn the user first if it detects there are existing associations to other programs since we don't want to silently do anything that may be overwriting pre-existing user choices.  I get your point, but at the same time, I actually think most users probably won't have pre-existing associations for those extensions precisely since they are too generic.  When those extensions are associated to NeoLemmix, it may be slightly misleading that it would look like all DAT and LVL files can be opened by NeoLemmix when it isn't actually the case, but I think most users won't be intentionally trying to open random DAT/LVL files other than ones that are explicitly levelsets they downloaded, so I don't see too much of a problem for the user.

All that being said, if we are considering totally new file formats, then yeah, they should get their own NeoLemmix-specific extensions and not reuse the rather generic DAT and LVL.

[namida]

Most likely, the formats are going to be revised - but files in old formats will be importable (at least as far back as what works well with current NeoLemmix versions - ie: variable-size level files (or 10KB level files that include a graphic set name rather than just a number), single-file graphic sets, all variations of VGASPECs, etc). Rather than have somewhat different setups for various types of files, the formats are going to be more similar to each other - of course a graphic set and a level are going to have differences in the exact data, but the underlying structure of the file will be similar; enough so that (for those who understand what this means) rather than implement seperate classes / functions for loading seperate types of files, they can all be derived from a common base class which would do virtually all of the work that isn't data-type-specific (eg: the specific graphic set class would be responsible for interpreting the graphic and metadata of an object, but the base class would be able to pull out the data of individual objects, using exactly the same code it'd use to pull out the data of, say, the data of an individual talisman in the talisman file).

[namida]

Seems opinions on the editor / player division (or lack thereof) is also close to unanimous. So, it looks like there'll be a player, and a seperate editor suite (which will include level editor, graphic set editor, pack editor, etc all in one app). I would imagine for the most part this would come down to four sections - a level editor, a graphic set editor, a system graphics editor, and a pack editor; with most other things being integrated into one of those (eg. talismans would just be part of the pack editor).

We're still a long way away from that existing, and thus from knowing exactly how it'll be set up, though.

[NaOH]

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.

I'm a little late seeing this thread, but I just wanted to say that I approve of bundling the pack into a standalone executable. It was very convenient that I could be sent a level pack in an engine I don't have installed and I wouldn't need to download anything else to play the pack.

[namida]

That too was one of my thoughts behind keeping it that way for a long time (originally, this was just how Lemmix was set up). However, it came up from time to time that a core player should exist; and when I put the poll out there, results were almost completely unanimous (might've even been 100%).

With wanting more control over the configuration (eg. custom hotkeys, customizable skillpanel, etc), having to reconfigure them for each seperate game would be a hassle - it's not so bad when there's only 4 or 5 options, but when there's heaps of them...

Setup should still be (aside from customizing your configuration, if one wishes not to use the default options) very simple; in particular, it won't have the messiness that the setup of (Super)Lemmini or the traditional Lemmix editor require. It'll be more akin to Lix in this regard; just unzip, optionally configure hotkeys / etc how you like them, and play.