Deimos Development Thread

[AveryMaurice]

With summer coming soon I was brainstorming projects I could attempt to create and see how they do, not saying I'm locked into this, but would like to hear opinions about it.

I was thinking about a Doom content delivery system, kind of like Steam. This could have a number of benefits in my eyes:

- Auto-updating source ports.
- Ability to launch wads right from the wad collection menu.
- Easy for newbies who don't want to deal with the command line, setting up source ports, etc.
- New Stuff Chronicles wads could be browsed and instantly delivered.
- Background downloading, task tray capabilities. (Not that WADs take that long to download anyways)
- News feed that lists new releases or popular wads.
- Possible social network capabilities. (Who's playing what WAD at what time.)

Just a few things I thought of. This would be a beast of a project, so I want to know if people are actually interested in it before I begin even thinking about it. I would most likely release beta-builds with new features as they come.

If anyone has opinions or further ideas I would like to hear them.

[Nomad]

If you can actually do it, and have the drive, I say go for it. Could be pretty cool.

[AveryMaurice]

Nomad said:

If you can actually do it, and have the drive, I say go for it. Could be pretty cool.

Thanks, I have thought about ways I could make this work and I have all the resources and knowledge I need to get the project done (at least at this time) and will start experimenting with it before I go into full-blown development to make sure I can do it.

[RestlessRodent]

Open Source and Cross Platform, otherwise some users these days will not use it if they can't use it at all (if they are interested in it). If you want to have a higher chance of being successful you need to cover more area. Saying "They can install Mono or WINE" is a joke.

I could assist some bit but that all depends on certain cases.

[Epyo]

Sounds effing sweet, I'd love to have something like that on my desktop next to steam n stuff.

[Reiken]

The effort required for all the on-going technical
and political wrangling needed to accomplish this
would probably ultimately be better spent on
improving/innovating lump tools and such.

This is a bit of a stretch, but artificially hiding
the perceived complexity of computing basics that
have and always will be around (files) in favor of
a centralized, metadata-choked wizard could prevent
would-be new mappers/modders from digging deeper.

Nothing personal, but the constant push of
'user-friendliness' which is really the opposite
is a bit wearing these days.

If you do end up going through with such a plan, start
researching network security first :p.

[AveryMaurice]

Reiken said:

If you do end up going through with such a plan, start
researching network security first :p.

It would be a client that would retrieve files from the internet, and install them for use with a source port, nothing more. You're digging a little too deeply. :P

[Reiken]

AveryMaurice said:

It would be a client that would retrieve files from the internet, and install them for use with a source port, nothing more. You're digging a little too deeply. :P

A bad habit of mine; guess I saw the comparison to Steam
and the warning bells went off. Don't mean to take the wind
from your sails, but it seemed pretty ambitious. With
developer cooperation it might be interesting, especially
if it made inroads to eventually standardizing things like
slopes, but would be a shame if it became the only distribution
channel other than compiling, somehow.

Probably looking way too deeply again :D.

[Jodwin]

It's an interesting idea for a project, but I'm not sure how useful it would be...anyway, a few things to take into consideration:

Port compatibility for wads. If you want to make it easy, you must not allow people to play wads with incompatible ports (at least not as a default :P). This goes even further when you realize that old ZDoom wads in particular don't work with the latest versions: You'd need to keep track of an ever growing list of different port version and all the wad compatibilities, not to mention that at the time of this writing there is no wad compatibility database, and it's practically impossible to automatically determine correct compatibility 100 % of the time. So your only option would be to build a manually managed database of wad and source port version compatibilities yourself. Good luck with that. :)

Interfacing as many current Doom services as possible. In theory interfacing the multiplayer master servers for different multiplayer ports should be easy, but only if you're allowed to do it. After that it would be really interesting to see speed demo archives interfaced into the system, so that every time you download and/or play a wad you could quickly check the best times for it and download the demos. Of course, you're going to have interface /idgames, and then somehow get all the projects that are posted on ZDoom forums but never on /idgames to appear.



Oh, and don't care about what GhostlyDeath said. It's better to make something that actually works than to bother yourself with getting it to work everywhere right off the bat and then fail, especially if you aren't used to cross platform developing yet. If the idea looks like it's going to be a success, then you could consider making it more available. But first get a prototype out, see if it's worth it, and continue if yes, revise your idea and if necessary drop it if no.

And, well, if it's really good enough, you can then just open source it and some day some one will port it if people really want to use it on other systems, too (and if it doesn't work on emulators - people are still using DB on WINE on Linux, so it can't be too bad :P).

[RestlessRodent]

Reiken said:

With
developer cooperation it might be interesting, especially
if it made inroads to eventually standardizing things like
slopes

Slopes will probably never be standardized and I doubt software like this would standardize port editing features. Slopes are a ZDoom extension and the only ports I know of that have slopes are ZDoom and Doom Legacy 2. The only thing I can see that could possibly become standardized is networking related stuff.

Making something like this to be integrated to work with a source port better would require cooperation between this program and source port devs to make it possible.

EDIT:

Jodwin said:

Oh, and don't care about what GhostlyDeath said. It's better to make something that actually works than to bother yourself with getting it to work everywhere right off the bat and then fail, especially if you aren't used to cross platform developing yet. If the idea looks like it's going to be a success, then you could consider making it more available. But first get a prototype out, see if it's worth it, and continue if yes, revise your idea and if necessary drop it if no.

And, well, if it's really good enough, you can then just open source it and some day some one will port it if people really want to use it on other systems, too (and if it doesn't work on emulators - people are still using DB on WINE on Linux, so it can't be too bad :P).

You can have it open source from the start and gather people who are interested in developing it. If it's Windows only, running it in WINE isn't really going to be that great because UNIX and Windows are very different. WINE users would need to create wrapping scripts to get the stuff launched correctly so that wads are correctly loaded and such. Doom Builder on WINE either works perfectly, fails miserably, or has stuff that doesn't work at all. There's already Doom Connector and existing launchers for Doom on Windows but there's not really anything of that sort of thing for any other system. You can release Linux binaries but then you'd be leaving everyone else out who can run it (unless you statically link it which would make the binary huge).

[Reiken]

GhostlyDeath said:

Slopes will probably never be standardized and I doubt software like this would standardize port editing features. Slopes are a ZDoom extension and the only ports I know of that have slopes are ZDoom and Doom Legacy 2. The only thing I can see that could possibly become standardized is networking related stuff.

Making something like this to be integrated to work with a source port better would require cooperation between this program and source port devs to make it possible.

Yeah, I just meant that if this project took off and brought the port
devs closer (yeah, probably impossible), it could be a communal
factor in encouraging a new iteration of compatibility (ie Boom).

Was mainly trying to counter my earlier stifling post with a bit of
hope.

[AveryMaurice]

Jodwin said:

Port compatibility for wads. If you want to make it easy, you must not allow people to play wads with incompatible ports (at least not as a default :P).

I've been thinking about this as well, a method I thought of was to make the program read the .txt file bundled with the WAD (like on the \idgames archives) to get the required information about compatibility, and the slot the maps are located on etc.

[Graf Zahl]

GhostlyDeath said:

Slopes will probably never be standardized and I doubt software like this would standardize port editing features. Slopes are a ZDoom extension and the only ports I know of that have slopes are ZDoom and Doom Legacy 2. The only thing I can see that could possibly become standardized is networking related stuff.

Uh, what?

Vavoom has slopes, Eternity is in the process of adding them and all 3 implementations are compatible (meaning that they share some means to define them and the methods not yet shared can be easily ported to each of these engines.)


The only port making something different with them is Risen3D.

Regarding Legacy 2, I don't know if it really has slopes. I can't remember that it has.

[Gez]

EDGE, Eternity, GZDoom, Skulltag, Vavoom, ZDoom all have slopes.
EDGE slopes use line types 567 (floor), 568 (ceiling), and 569 (both).
Eternity uses line types 386 to 396.
Vavoom uses things.
ZDoom in the Doom map format uses line types 340 to 347, but it is compatible with all other methods: it supports Vavoom's things and (through map translators) the EDGE and Eternity linedefs can be remapped to Plane_Align and Plane_Copy.

Jodwin said:

This goes even further when you realize that old ZDoom wads in particular don't work with the latest versions

They have no reason not to. If you have any example of mod that doesn't work, this should be reported as a bug.

[Graf Zahl]

It should, but some people apparently prefer to spread urban legends than to help fix such issues...

[Jodwin]

AveryMaurice said:

I've been thinking about this as well, a method I thought of was to make the program read the .txt file bundled with the WAD (like on the \idgames archives) to get the required information about compatibility, and the slot the maps are located on etc.

That could work, but you must realize that not all readmes are identically written, meaning that the ports, map numbers and so on can be mentioned in many ways depending on who wrote the readme and how drunk/tired/high/etc they were at the time. And then there's the readmes which just omit the info.



@Gez: Aren't there quite a few ZDoom wads that work properly only on 2.063a, for example? I thought ZDoom intentionally disregarded backwards compatibility.

[Graf Zahl]

Of course there's the occasional WAD that breaks. Most of the time it's because the mappers thought to be smarter than the engine developers and used dirty hacks - but as it always is with abusing bugs or undocumented features, since these things have no well-defined behavior, it's prone to change and break mods depending on them.

A good example was the first release of the ZDoom community map which fell victim to the DEHSUPP craze of the time. Too bad that DEHSUPP was explicitly stated not to be version compatible so big surprise! Next ZDoom release and the map didn't work anymore.

But this is the exception. An engine that doesn't care about backwards compatibility to older versions of itself is doomed to fail. No developer would be that stupid.

[Gez]

Jodwin said:

@Gez: Aren't there quite a few ZDoom wads that work properly only on 2.063a, for example? I thought ZDoom intentionally disregarded backwards compatibility.

Does this look like intentional disregard?

[Bucket]

You could call it Stoom!

[AveryMaurice]

Thanks for all the support, I meant to get around to this earlier but I just finished a final exam for science and have some free time now. The product is still unnamed, I've just been calling it Deimos right now (in reference to the moon teleporters moving "content" around, I'm clever like that) but if anyone has a better name for it, please post it. I'll put updates and such in this thread when I begin experimenting with this and show you all the results. I'll begin to trying things out probably starting this weekend after finals.

Again, thanks for all the support. All your input/information has been useful to me.

[AveryMaurice]

Update: Heres the first sorta functional build of Deimos, completely unfinished. The reason I wanted to show this was to show some of the progress I am making.

Deimos can now generate a WAD list from its "wad\" directory, and install other WADs to it. Right now, it reads ".deimos" files to get the files information, but I am hoping to add /idgame .txt capability soon. If a file doesn't have any information, it will still work and be able to be launched from Deimos, but will appear in the WAD list without a description or port information and be labeled unsupported.

This screenshots shows a successful import of the Alien Vendetta WAD file and .deimos file, and can be launched right from this screen. I would say that the launcher code is 90% complete as well as the import code.

Next step is to actually get the downloading to work using Deimos's online WAD archive. I'll keep you all posted.

[Gez]

AveryMaurice said:

If a file doesn't have any information, it will still work and be able to be launched from Deimos, but will appear in the WAD list without a description or port information and be labeled unsupported.

It should be possible for the user to generate a .deimos file from within the program, just by filling a small form panel with basic info (name, iwad, port, author(s), etc.).

[Nomad]

Wow! I didn't expect to see results so quickly! I'm excited to see how it turns out!

[AveryMaurice]

Gez said:

It should be possible for the user to generate a .deimos file from within the program, just by filling a small form panel with basic info (name, iwad, port, author(s), etc.).

Thanks for the feedback, I'm adding this feature now. I'll keep you updated.

[Whoo]

Just curious about this: what language is it being built in?

[AveryMaurice]

Whoo said:

Just curious about this: what language is it being built in?

Both C# and VB.NET. C# is being used for possible Dll librarys and all that crap for stuff I can't do in VB.NET, while VB.NET is the general base of it because of its simplicity.

Unfortunately, this means it would be focused around Windows, but if It actually takes off I'll start thinking about Linux ports first.

[Jodwin]

AveryMaurice said:

VB

ewwwwwwwwwwww :x (j/k)

Anyway...some other thoughts:

Importing your currently downloaded wads into the program. Allow user to choose whether it just moves wads to Deimos' wad folder, or should it copy everything there. Also add support for other wad folders (important when you're working on wad projects, but don't want to mix those wads with all other wads...or if you just want to categorize your wads on the HD by any criteria).

Also, when copying wads from HD to Deimos, it should get the readmes from /idgames automatically if they aren't present on the HD.

Add sorting wads by any possible criteria (map count (you could get this from the wad, no need for readme ;)), port, date, name, author, single/coop/dm...). Also consider the option of an online wad database where additional info about wads could be uploaded for better sorting (difficulty, gameplay style, etc).

MAKE IT EASY AND QUICK TO USE, BUT POWERFUL. The user interface is the single most important aspect of a good frontend. I know it's still very much under work and the screenshot is a mockup, but I have no idea how you're supposed to launch the game with you port of choice, with demos and command line options. You really need to spend some time planning it, Steam (which you compared to) has easier time with the GUI since you just click on a game and press play, but with Doom you need to allow multiple wads, dehs, lmps, pk3s, and preferably zips (it saves HD space a lot if you just keep downloaded wads in zips and extract for runtime), and command line options and different ports.

When you start up the frontend, the first view should be one that *quickly allows you to fire up the game, while all the extra features are on other tabs/screens/etc. Because that's what the primary function of a frontend: Launching the game. It's ok to make the set-up phase slightly longer or more complicated if it guarantees that after set-up the frontend will be straightforward, fast and painless to use. After all, set-up is something that you'll be doing only once.




*Don't misunderstand, there certainly is space for this kind of a frontend for Doom if done well, and if you'll pull it off, I'd probably use it too. But no matter how different kind of users you're targeting (compared to, say, CDL), you still need to keep in mind what's the main purpose of a launcher when designing its user interface.

[AveryMaurice]

Jodwin said:

...how you're supposed to launch the game with you port of choice, with demos and command line options.

Double clicking a WAD in the WAD library automatically launches that WAD using the recommended source port given by the Deimos file, but going through the launch menu on the menu bar you can select/enter parameters and custom ports if needed. Thanks for the feedback as well, I'll work on accomplishing the things you've suggested.

[Jodwin]

AveryMaurice said:

Double clicking a WAD in the WAD library automatically launches that WAD using the recommended source port given by the Deimos file, but going through the launch menu on the menu bar you can select/enter parameters and custom ports if needed.

Okay, the double-click sounds good for when you just wand to load one file and are happy with whatever default port you have (how is that determined anyway? Is Chocolate always the default for vanilla, for example, or can you make any port default for vanilla and any Boom-comp port default for Boom wads, for example?). Having to go to a particular menu, on the other hand, sounds pretty bad if you just want to pick multiple wads (music wads or weapon mods, for example), or if you want to watch or record demos, use -fast or -nomonsters, etc.

There are different metrics and "rules" used in user interface design to evaluate how good the interfaces are. One of my personal favorites is just counting required clicks to perform something (like starting the game). Double-click is certainly the best way (only two clicks, assuming you start in the wad list), but since it covers only one use case you need other quick ways for other use cases. Menus aren't good for this kind of stuff. They're great for hiding less relevant functionality that needs to be accessible, but not necessarily that quickly. So...yeah. One other GUI metric basically says that further away two buttons that you need to click in sequence are, the worse it is (so according to this metric, in CDL if the "Play"-button was right above the wad list it would be better, since you're first going to click on a wad and then on the button).

[AveryMaurice]

The recommended/default port is the one that the WAD was built for as stated in the readme or Deimos file for each WAD. Like I said earlier, since this is focused for easy access to WADs and expansions, I will most likely add in advanced features a bit later but It will probably just be > control click WADs, launch menu, select port.