DieHard Wolfers :: View topic - Announcing the Diehard Wolfers' Mapping League!
Announcing the Diehard Wolfers' Mapping League!
Subject: Re: Announcing the Diehard Wolfers' Mapping League!
1) I was thinking, would it be a good idea to allow for multiple pages for saved games slots ala 'The Orb of Dilaaria'? In that mod, you can save up to 100 games if I recall correctly. Either go for ten pages (or however many pages we want), or otherwise make the page scroll down if that is even possible? I reckon that this capability might come in handy for single packages going over the 10-map count (such as the 1st Mapping League package with its 11 maps), or even more so when we start building the anthology as we go so that people do not have to manually administer saved games files outside of the game. Thoughts?
This shouldn't be too hard to do; I'm probably going to add a map select menu, so if I do it might not be strictly necessary.
2) Also, would people be open to adding the Lost Episodes bosses? Just an idea. I believe that adding them should in principle not entail challenges code-wise (since I reckon they are mere sprite (and also sound?) replacements of the original SoD bosses), but it might be a bit time-consuming to get them in? Again, just a thought.
3) How about adding an in-game message that lets you know when you've died because of a moving wall? I understand that in many cases such a message will not be necessary as the death cause will be pretty obvious, but I am finding that in some cases you will have to wait between 3 to 4 seconds to realise it was a wall that killed you, especially when the camera rotates almost 360 degrees. Plus, perhaps the message in itself will not look too bad?
4) Would it be worth considering adding a toggle to choose whether the knife is a silent weapon or not? Just an idea. Some maps might benefit from the 'stealth' strategy that a silent weapon allows for.
5) Here's a rather crazy one and I've no idea how painful it might be to pull it off: how about a toggle that lets you decide if moving walls can step into your teleporters and continue down their route elsewhere in the map?
1) The in-game messages do not look entirely right when they are on screen and you die. Say you pick up an item and immediately die (or you step into an artifact of death), and then the red fade-in effect comes in, then you'll see that the messages get overlapped by the redness. I believe that a more aesthetic approach would be to bring the message to the front and keep the red fade-in to the back so that the message is completely visible.
If I actually win the MCC contest for a change, I'd be requesting adding of eight new treasure types and a few 3D Directional Sprites relating to things like the Spear Rack from Wolf3D. Also to add to the list would be a number of new IMF tracks added to the list, which I'm working on now.
No need to win for that, send me the relevant sprites and details on the objects and I'll put them in.
And the last thing I'd like to add would be a bug fix for the "killed by Pushwall" bug, where it spawns an invisible guard in the square of the fatal wall, "fires off" a fatal shot at the player, and then the EXE rotates the player's view to the guilty party.
It doesn't actually do anything that complicated; it just turns the player 180 degrees. I'll see if I can make it actually turn towards the pushwall in question (and fix the rendering for being in the front of a pushwall).
I believe I kind of understand the limitations you are starting to face with old editors like MapEdit and ChaosEdit as the mapping kit keeps escalating. Just so I understand a bit further: are you looking into an alternative that would kind of emulate the capabilities you obtain by using a third plane (not accessible in MapEdit, and limited in ChaosEdit), but by using the mapinfo file instead? If that is the end goal, then exactly which capabilities would you enable via the mapinfo file that an editor such as WDC would normally enable via the third plane? I can easily imagine floor and ceiling textures, or certain weather effects ala 'The Orb of Dilaaria', where you would get, say, instant rain the moment you stepped out into a courtyard; however, those are not features we (currently) have, so I'm wondering what it would be that we would now have to enable via the mapinfo file? Sorry that I need this clarification; it's all so I can help.
I would not be enabling floor and ceiling textures; at present the main benefit would be to allow a significant number more pushwall groups. (As for weather switching, the next kit will have an object that switches to a certain teleporter group's environmental settings without actually doing any teleportation, which should make such things much less annoying to map around).
'd prefer this be called up through the Mapinfo?? files instead. This is IMO unused, and it has a lot of potential to remove many of the limitations we have regarding mapping for just two planes on the map.
My intention was to allow for both the third plane and the mapinfo file to be used for specifying this, as if your editor supports it, using the third plane is much more elegant. It will have identical capabilities regardless of the method used.
One last request, AlumiuN - I've found no option in the MAPINFO files where teleporting disables/enables shading; the on/off switch for shading at the start of the level is what you're stuck with. All you can do is adjust the settings of it. Yes, you can adjust the distance regarding walls per se, but the ceiling colors still adjust their colors to a certain degree. This is the only major fallback I've seen in mapping using your new MAPINFO code, and considering how many features the new code provides, that's a very good success ratio.
That actually works the way it used to - if you set the fog value to 255, there will be no shading applied. TBH I could probably do away with the "enableshade" option as it doesn't really do much any more.
I've been having serious problems with energy of late, so this kit is not going to be ready by April; unfortunately I can't really give any sort of real timescale for it being ready, but hopefully it won't be too long.
Yeah man, get well, and take all the time you need!
Take all the time you need; it sounds like you need a break from it.
Of course, if you win the MMC contest again, I suppose it might give you an adrenalin rush. Maybe.
Good news; I've found some energy and have managed to work through a fairly large amount of what I have planned for the second league. There's still a fair bit to do (in particular the pushwall system rewrite is looking a little daunting), but it's progressing. If anyone has thought of any inclusions they want made (that haven't been mentioned yet, because I think I noted all of the previous ones down), please let me know soonish.
Excellent to hear you're doing better, Sir. Take care and take it easy.
It should be noted that these don't display through to anything actually behind them, they just don't overdraw the floor/ceiling colours or sky type. I'm still thinking about how to make weather particles show up in them, as even though they didn't show up in the wall tiles before, they look a little weird now that it shows through to the sky.
Each of those sets expands and collapses at will, and the bottom panel will have more information when complete (including best achieved kills/secrets/treasure/time and highest score on the level). I'm still working on adding a "Development" entry as a default so that a set info file is not required while developing, but it shouldn't take too much work. I'll also be applying this scrolling menu to the save/load game menu so I can make more saves available.
I think a hub level would be awesome where you can choose which map you want to play, if you finish the map then return to the hub level to choose an another level (Don't know how the scores or the end game will works).
I think I could probably add that as the option for "Play All" and let people design a small entrance section for their map in the hub. How would other people feel about that?
I am not sure I follow. Would this approach entail using an initial level from which all other levels in the package could be accessed? Then, upon finishing any of the other levels, the player would return to the initial level and be allowed to play the other levels (perhaps even the one(s) he/she has already finished)?
If the above is what this means, then I am not sure why mappers would have to design anything extra to contribute to the hub? If we wanna go ahead with this, then the hub might be a generic layout that could be used all throughout this series but regardless of however big each package is? The hub would accommodate however many levels there are in the current package? Moving forward, a generic -and recycable- solution might be the way to go?
Maybe it's me. I am just having a bit of trouble picturing in my head how this would be implemented.
Good to hear from you again, AlumiuN!
I think the entrance section would be a bit much when it covers more than just a handful of maps.
This is what it would be, yes; the idea behind a mapper providing a small section would be to provide a unique-looking entry for their map (otherwise whoever is responsible for making the hub map, most likely me, would make the entrances). I think the generic, recyclable solution is probably the menu as I've implmented it rather than having a hub level at all.
EDIT: To elaborate on the hub maps, the idea would be to have some sort of map with a largeish foyer-type area and a small entrance section for each map (probably stylised in some way to fit the map) off that foyer.
You might be right; it does seem like a fair amount of effort (mainly in terms of making an interesting hub map, the code should be pretty simple) for not a huge amount of gain. It's possibly also more annoying from a usability perspective than just having the menu.
Subject: Announcing the Diehard Wolfers' Mapping League!
Today I finished a new set of settings - enemy groups. These allow you (using the teleporter IDs, which are now more general-purpose object IDs) to have certain enemies have different properties, namely whether they should be the lost episode versions (if appropriate), if they should be deaf (which is boring, but because you can't use the normal ambush marker with grouped enemies I needed to include it), and perhaps most hilariously, how much to multiply each enemy's health, damage, movement speed and animation speed by (and it supports floating point numbers, so you can reduce them or increase them). This can lead to terrifying things like this, for example.
If anyone has thought of any inclusions they want made (that haven't been mentioned yet, because I think I noted all of the previous ones down), please let me know soonish.
1) Can we include arrows to make the moving walls move diagonally? If I remember correctly, in the ML1 package we could only make them move north-, east-, south-, and west-wards.
2) This one is only an aesthetic whim of mine and others may not agree it is necessary (or desirable): any chance to add a fade-out type of effect for walls that are destroyed? I understand it doesn't matter when they are destroyed and the player is not facing them, but when you are right in front of a wall that is destroyed the effect you get is it disappears into thin air (meaning, from one instant to the next the walls is just no longer there). Perhaps a quick fade-out thing like the effect we get when we teleport would make things more aesthetically pleasing? (No sound, just the visual fade-out). Just an idea. Perhaps even a toggle in the text file would also come in handy to turn the effect on and off, as I understand some people might want to keep the wall destruction behaviour the way it is.
So, in essence, does this mean that whenever we teleport, we will be able to change (or keep untouched) the enemy settings you mention? If this is the intent, then I can think of a sort of escalation sequence where the player would teleport multiple times and each time the baddies would be one level more lethal. Or a deacceleration version of the same idea where things would get increasingly easier for the player. Also, in the video you linked, what is really happening? Is the boss faster upon you teleporting? I think that's what I noticed but I am not entirely sure.
I can look into it, but it increases the complexity of the renderer by quite a bit (which is the part of the codebase I'm least adept with modifying), so I might not be able to do it.
This is also complicated renderer-wise, but I might be able to get something working.
This is actually completely unrelated to the teleporter system. What I meant by mentioning the IDs is that the map plane objects that were used in ML1 solely to give teleporters their groups are now used to specify the groups of other objects, but teleporter groups are different to enemy groups. What this means is that you can give the settings of an enemy group to specific enemies.
What's happening in the video is that the group the boss is in has 2x move speed and 5x animation speed (along with being the Lost Episode version; the robot is the LE equivalent of the Death Knight).
I will totally understand if that is the case. No issues at all and thanks all the same.
Again, if this is too painful then please don't bother. It is merely an aesthetic whim of mine and not that important to go into a lot of trouble.
Thank you for clarifying. I believe I begin to understand how this new setting works. Sounds like a nice new toy to play around with it.
Thanks again for all the hard work you keep putting into this.
I see another problem with this, also. Whenever a Pushwall is moving, any area it covers is marked as a wall ... even if the wall is only covering it by less than 10%. So until the Pushwall has completely moved off of the square, the code will think the Pushwall is blocking off any shots from you or the enemy ... even when the wall is clearly not in the way. More than one map illustrates this problem perfectly ... particularly in boss fights. There is a way to work around this, but it severely limits the way you map. So I would recommend this problem be fixed before diagonal movement is implemented.
Feel free, and I also encourage you to post the correction in the SDL Code Crackers forum if you can. Because I have no idea how to fix the problem.
From what I understand in some of the (vanilla) CheckLine code, a square that the player can move through can also be seen through. The vanilla source allows all actor types - including the player - to walk through the door the instant an enemy starts to open it up (The code follows a different procedure when the player opens the door). I haven't been very thorough as to all the changes made to CheckLine and CheckSight when it comes to the MMC code. To be honest, I don't have a handle on the changes 100%, and that's why I never got the newest version of the code running in Dev C++.
Well, it's supposed to take the position of the door into account, but the end result is that the door can be seen through entirely once it's past a certain point, and that certain point is further into the animation the higher its x and y coordinates are (although thanks to the scale even if the door is at 63, 63 it's considered entirely open when the door is only an eighth open).
Well, I appear to have lapsed into inability once again; I've not been able to do any programming for about the last two weeks. As a result, I'm probably just going to shore up a couple of things that are left to do and release the next package some time shortly without the planned pushwall rework (as having to rewrite both the entirety of the pushwall code itself as well as the majority of AsmRefresh is a lot of work); hopefully then that will give me enough time to get that done for the third league.
Take it easy, mate. Please handle it according to your own times. Nobody is in any rush. Anything you decide will be more than alright.
It seems like the WDC definitions for this include a tiny mistake.
Thanks, I'll touch it up before the next release.