Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
chungy

Freedoom 0.9 release plan/goal

Recommended Posts

It's been a long time (at least, feels like it) since 0.8 and that last release no longer accurately represents the game. I've talked to fraggle over email and he agrees with this, and we should strive for a new release within the next two weeks.

Two weeks? Am I crazy? Perhaps. :) A big reason for this is that the Debian project is close to putting their next version in a "freeze" where no new software versions are allowed in, and presently they only have Freedoom 0.8. Debian is one of the most prominent upstream distributions (Ubuntu and Mint are based on Debian, along with many others) and it has a long release cycle: it can take upwards of two years for new stable releases to come around, that can mean two years of (at least) hundreds of users seeing Freedoom 0.8 as representative of our state which it really should not be.

Aside from this scheduling, Freedoom 0.9 already includes renamed IWADs, a new font, new sprites from raymoohawk, huge changes to FreeDM (its entire lineup is new), and other things I can't even remember. The latest Freedoom release at any point in time should represent the project well, and 0.8 does not do that. :)

I've created a 0.9 milestone on the GitHub tracker with a few issues that I think are critical to be fixed before we release. In addition to these, fraggle and I are hoping that raymoohawk will be able to finish the sergeant within this time frame (if you're reading this, raymoohawk, no intention of rushing you). This milestone isn't 100% definitive of all that needs to be done, if anyone else thinks another component really needs to be done, and can be done in a couple weeks' time, speak up or forever hold your peace... until our next release :)

Additionally, as a reminder, if anyone wants to check out what Freedoom's IWADs look like presently, you can always download an automated master branch build from http://freedoom.soulsphere.org/

Share this post


Link to post

My skill level testing has shown only 11 maps in Freedoom2 have any type of skill level settings. We do not need extensive, precise, and fully tested skill level settings at the moment.

Currently I am hoping for skills to at least be tagged in an editor. Fully adjusting them to perfection will take time and much play testing, but as long as thing are tagged we have a baseline to start adjusting.

Share this post


Link to post

i hope ill be able to get the shotgunguy in in-time, but theres no way ill be able to finish the imp before the deadline, sorry :-P

Share this post


Link to post

One other thing: the purpose of this thread is to encourage some collaboration so that we can get the 0.9 milestone bugs fixed so we can do a release. If you want to help out and take on a particular bug, it's a good idea if you announce that you're going to work on it - either on the bug or in this thread. This will avoid duplicated effort.

Ideally we should try to get this finished in under two weeks. Debian is going to freeze around the start of November, and we want to leave time so that we can get through the Debian bureaucracy and make sure that 0.9 gets in to the next release.

Catoptromancy said:

My skill level testing has shown only 11 maps in Freedoom2 have any type of skill level settings. We do not need extensive, precise, and fully tested skill level settings at the moment.

Currently I am hoping for skills to at least be tagged in an editor. Fully adjusting them to perfection will take time and much play testing, but as long as thing are tagged we have a baseline to start adjusting.

That's to be expected. The skill level adjustment work is really important but it's a lot of work and I don't think there's any way we could get it done in a couple of weeks. For now I think it's okay to leave things as they are.

raymoohawk said:

i hope ill be able to get the shotgunguy in in-time, but theres no way ill be able to finish the imp before the deadline, sorry :-P

No problem, that's what we expected :)

Just having the two zombies (and Cyberdemon) redone is going to make a world of difference over the old zombies, I think.

Share this post


Link to post

We've fixed several bugs tonight already and made some really good progress. Good job everyone!

Share this post


Link to post

Wow. Considering the length of time between 0.7 and 0.8, I have to say I'm impressed.

It's good to see that the project is getting more attention these days.

And while it would probably be nice to get all of raymoohawk's potential sprites in 0.9, just having a new zombie and shotgundude would probably be enough to garner more positive attention for the project. Honestly, after seeing the new zombie, I have a difficult time rationalizing the use of 0.8.

Presumably, even though the website says no more beta and rc releases, there will be at least one for 1.0? It seems like this project is getting very close to being a functional *cough*replacement*cough* for certain IWADs.

edit: I haven't really played through many of the maps ever since coming across a few showstoppers in Freedoom 1 (0.8) (it's kind-of annoying when there is a map, but it can't be beaten by going through the logical route), but I think I'll give it another try. I forget exactly which map it was, but I think it was one where you needed a key to access an elevator, and then when you went up, there was a broken door, and a "cleverly" hidden secret switch that did absolutely nothing. That was around the time I discovered OBLIGE.

Share this post


Link to post

As the maintainer of the "freedoom" package in Debian, let me add some thoughts:

Currently, two binary packages are created from the "freedoom" source package: freedoom and freedm [1]. The former contains only the Doom 2 replacement IWAD, which was still called freedoom.wad at the time of the 0.8 release, and the latter contains freedm.wad.

However, in the meantime since the 0.8 release, two important things have happened that IMHO need representation in the Debian package: 1) The Freedoom IWADs have been renamed to freedoom1.wad and freedoom2.wad and 2) "Freedoom: Phase 1" has received enough love that I tihnk it should get included in the set of binary packages as well.

There are (at least) two or three different ways to achieve this:
- I could package 0.9 identical to 0.8 and simply ignore freedoom1.wad.
- I could simply add freedoom1.wad to the "freedoom" package and be done with it.
- I could add a "freedoom1" package and rename the current one to "freedoom2". The former "freedoom" package would become a dummy package that depends on "freedoom2". (Alternative names for the new packages would be "freedoom-phase1" and "freedoom-phase2". Should the "freedm" package get renamed to "freedoom-freedm" as well?)

I very much prefer the third alternative, but it comes with one problem: Adding a new binary package to the Debian archive requires the source package to go through the NEW queue [2], in which it is reviewed again for DFSG- and policy compliance. And packages tend to be stuck in the NEW queue for quite some weeks, which would mean that we cannot meet the freeze deadline.

So, what shall I do?

Edit: Added a few remarks.

PS: I am a bit puzzled why you haven't approached my before? I mean, I am the Debian maintainer for the package in question and I hang around here and on github regularly.

[1] https://packages.qa.debian.org/f/freedoom.html
[2] https://ftp-master.debian.org/new.html

Share this post


Link to post
fabian said:

The former contains only the Doom 2 replacement IWAD, which was still called freedoom.wad at the time of the 0.8 release.

This was a big motivation for the renaming. freedoom.wad was never an official name for the IWAD :)

fabian said:

2) "Freedoom: Phase 1" has received enough love that I tihnk it should get included in the set of binary packages as well.

Probably should have been included earlier, but the fact that it had a temporary name ("Ultimate Freedoom") for ~5 years does indicate its prior status, yes.

fabian said:

- I could add a "freedoom1" package and rename the current one to "freedoom2". The former "freedoom" package would become a dummy package that depends on "freedoom2". (Alternative names for the new packages would be "freedoom-phase1" and "freedoom-phase2". Should the "freedm" package get renamed to "freedoom-freedm" as well?)

This is the cleanest and preferred method. You can use the "install-freedm", "install-freedoom1", and "install-freedoom2" to install each individually and hopefully help in packaging it. The usual autotools-like variables control where files are installed.

fabian said:

I very much prefer the third alternative, but it comes with one problem: Adding a new binary package to the Debian archive requires the source package to go through the NEW queue [2], in which it is reviewed again for DFSG- and policy compliance. And packages tend to be stuck in the NEW queue for quite some weeks, which would mean that we cannot meet the freeze deadline.

I hadn't realized there would be so much work for simply splitting the Freedoom package, but if that's what it takes, then I can only say "oh well."

fabian said:

PS: I am a bit puzzled why you haven't approached my before? I mean, I am the Debian maintainer for the package in question and I hang around here and on github regularly.

I didn't have the thought (of making it before the Debian freeze) for more than a handful of days, it probably would not have changed the circumstances drastically, but I am sorry :)

fabian said:

So, what shall I do?

Carry on per normal. If my logic was just wishful thinking, then that's what it is.

Share this post


Link to post

Frankly I think you could ship all three freedoom iwads in one binary package, unless there's some technical reason for the separation*

________
* I can only immediately think of two: freedoom and freedm both install a file named "doom2.wad" in the same place, so they conflict [edit: but this no longer applies, see below, apologies to Gez]; or a way to choose default IWAD for engines that automatically prefer one over another if several are installed.

Share this post


Link to post
fabian said:

- I could simply add freedoom1.wad to the "freedoom" package and be done with it.

It seems like the best approach to me, but I don't use Debian so feel free to ignore my opinion. :p

RjY said:

* I can only immediately think of two: freedoom and freedm both install a file named "doom2.wad" in the same place, so they conflict; or a way to choose default IWAD for engines that automatically prefer one over another if several are installed.

They no longer do, do they? I though the IWADs were now named freedoom1.wad, freedoom2.wad, and freedm.wad.

Share this post


Link to post

Well, they never did. FreeDM has always had the file name of freedm.wad, whereas Phase 1 and 2 had the file names of doom.wad and doom2.wad... which are now different.

The reason for having three separate packages is simply so people can pick+choose which IWADs they want to have.

Share this post


Link to post

To me it seems like needless complexity to have to pick and choose options when, by today's HD size standards, having all three together isn't really a hindrance. I can understand something like not getting FreeDM if you're not interested in deathmatch (or inversely, only getting FreeDM if you're only interested in deathmatch) but I see no real virtue to separate phase 1 and phase 2.

Share this post


Link to post
fabian said:

- I could simply add freedoom1.wad to the "freedoom" package and be done with it.

This sounds like the simplest solution given the timescale. I'd rather see this happen than see freedoom1.wad just left out entirely.

Splitting it into separate packages that can be independently installed would be nice, but given that storage and bandwidth are cheap and plentiful nowadays, it doesn't seem like that big a deal to just bundle them together.

Share this post


Link to post

Freedoom1 package
Freedoom2 package
Freedm package
Freedoom meta-package with all of them.

I really do not care about the packaging details. But this seems to make sense. Not all ports support Boom, so Freedoom1 and 2 are out. Some ports are mainly DM.

Share this post


Link to post

It's probably worth noting that the Zip files that will be downloadable, as generated with "make dist", are just two files, freedm and phase 1+2 in a single "freedoom" Zip. It definitely sounds reasonable to me to reflect this in distro packaging too.

Share this post


Link to post

Alright, then I'll package it that way. This will significantly speed things up.

Thank you for your input!

Share this post


Link to post

Am I the only one that takes issue with the number? Can we call this 0.85 instead?

I think that too little progress has been made to justify an entire version update, we should at least wait for the sprite overhaul. There are many other bad assets that need to be replaced. I think Freedoom should look and sound far better before we even come close to 1.0, it should give a good impression and be worth playing on its own and not just "that crappy version of Doom that I only use because it's free". Its current state is more of the latter and less of the former for me at present. I think it has potential, but it seriously needs some quality asset replacements to be truly good.

Yes, much of it is up to the community and no one party is responsible, I'll submit new assets soon. In general, I replacements should be more readily accepted; as long as 1. it's better quality than what is currently there and 2. is sufficiently different than the id version, it should go in for the sake of making Freedoom better than it currently is.

Share this post


Link to post

If we jumped to 0.85, we'd be skipping 77 releases. :P

The number isn't a percentage indicator. We'll likely have a 0.10 at least before 1.0 is out. I can't get my crystal ball any clearer than that. Plus I think there's been more than sufficient justification for a new major version.

Share this post


Link to post
Sodaholic said:

Am I the only one that takes issue with the number? Can we call this 0.85 instead?

I think that too little progress has been made to justify an entire version update, we should at least wait for the sprite overhaul.

A lot of progress has been made since the last release, and that's why a new major release is justified. This isn't just some minor bugfix update to 0.8.

The mistake I assume you're making is thinking that 0.85 is a decimal and represents some "fraction of progress" towards a 1.0 release. That isn't the case. After 0.8 comes 0.9, and after 0.9 comes 0.10.

The kind of thinking you're showing in your post is exactly why (in my opinion) decimal version numbers are actively harmful. It either discourages maintainers from doing regular releases, or destroys the distinction between major and minor releases.

Share this post


Link to post

0.8.1 would indicate a bug fix release.
0.9 would indicate a major release.
1.0 would indicate a finished project.

I think this is correct after all the lengthy versioning talks.

Share this post


Link to post

We're making good progress towards the 0.9 milestone. One thing that hasn't been taken on yet is doing new demos. We need:

  • Somebody to record new demos for freedoom1.wad and freedoom2.wad. The levels ought to be stable enough now that this should be possible. These don't have to be anything special, it's just important that they should be recorded in Vanilla format (probably with PrBoom+ or Eternity in Vanilla compatibility mode).
  • Demos for FreeDM. Somebody needs to schedule a time when a few people can get together and record some demos. FreeDM needs to be fully Vanilla compatible so you'll have to use Chocolate Doom or Vanilla Doom running in DOSbox. I suggest recording demos for 5-6 different levels, just in case some of the levels get tweaked before the release (there are still some open bugs against FreeDM levels)

Share this post


Link to post

Some more things should be said about demos: they should not be speedrun demos or high-skill play-throughs. It's tempted to show off your skills, and nothing is wrong with that, but it's inappropriate for an IWAD. We should demonstrate basic gameplay (probably with autorun turned OFF and your shift key not pressed most of the time) with moderate competency, but just enough that new players shouldn't become frustrated that their playing skills are inferior to that in the normal demo run. Check out the demos in both Ultimate Doom and Doom II for an example, they're all recorded by John Romero but none of them display exceptional skill, it's often lousy and silly. Not obviously feigned but also not a high barrier to surpass.

We can take in many more submissions and pick out the "best" demos, of course, but it should also be noted that we should have four demos for each of the three IWADs. DEMO4 in freedoom2.wad avoids crashing the Final Doom vanilla exe, or Chocolate Doom with "-gameversion final" -- the maps might crash these engines anyway, but the lack of a demo won't.

Share this post


Link to post
chungy said:

We can take in many more submissions and pick out the "best" demos, of course, but it should also be noted that we should have four demos for each of the three IWADs.

No disagreement here about people submitting their demos and the best getting picked out. For the single player IWADs people can record their own demos on their own. However, for FreeDM we need someone to organize a session to record some deathmatch games. I was kind of hoping that someone will step up and organize that. Anyone care to take on that responsibility?

Share this post


Link to post

Let's meet up and idle in #freedoom on irc.oftc.net. Eventually we will have enough players to make some demos.

I will make some SP demos at the last minute if no one else does.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×