Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nepster

Pages: 1 ... 89 90 [91] 92 93 ... 125
1351
Level Design / Re: Opinion on designing levels
« on: February 16, 2016, 12:06:54 AM »
As you already can see from the previous posts, everyone has a different approach to level creation. My own workflow is usually like this:

1) Get level idea
More often than not, I get level ideas while playing other levels. I try out something, but it doesn't work. But the lemmings interact in an interesting way, skills get combined in an unusual way, ... in other words: stuff that cries "turn me into a new level".

2) Strip the level idea of anything unnecessary
When first encountering some level idea as above, I usually made many skill assignments before, there is lots of terrain around, ... But I want that players of my level to see the level idea in the clearest possible way. So I ask myself the questions: What are the key ingredients contained in the level idea? What is the minimal terrain layout where this can work?
To answer them, I step completely away from the computer and "play" the level purely in my mind. For me this is the fastest way to modify the imaginary level, strip away parts and see what happens, add some piece of terrain to see how this influences the level, let the lemmings wander around without having to care about their precise timing, ... For very complex ideas, I make rough sketches on paper once the broad layout is fixed.
This step might not be absolutely necessary. But I found it useful to reduce the amount of unintended solutions. In the following steps, the levels usually gains quite a bit of complexity again, and the more complex, the more potential for backroutes.

3) First rough design in the editor
Now I return to the editor and put terrain where I imagined them. I do not worry about the looks at all and in this state the levels usually look like an unholy mess. It is meant to check, whether my imaginary level can be turned real. If some lemmings have to meet at a certain point, I have to adjust the lengths of paths they walk; if a miner should reach point X, I have to worry that this is actually possible, ...

4) Do I see easy alternative solutions?
Changing the final level with all the terrain carefully fitted together is quite a bit of work. Therefore I found it useful to start worrying about alternative approaches/solutions quite early. So I sit down (usually after taking a break) and try my best to backroute my own level. Whenever I find one, some rough modification is made to the level to remove it.

5) Prettify the level
Now that I have a level that more or less works as intended, but looks totally unappealing, it is time to prettify it. Often I find, that the style I chose at first is not really suitable to turn the level's terrain into some pretty terrain. So I start another editor and recreate the level from the beginning, but now properly fitting the terrain pieces together.

6) More backrouting
Prettifying a level usually changes lots of details, so backroutes may creep in again. I found it useful to have a whole day break before starting backrouting again.

7) Make intended solution easier to execute
As the level designer I already know, where to start the builder, miner, ... but all other players don't know. So I go through the whole solution and always ask myself: Does the solution still work if I assign the skill a few frames earlier or later? Quite often changing a few pixels can make a huge difference to this question.

8) Let other people play the level and encourage feedback
Other players might see problems, ways to improve the level, ... that I missed. Not to mention that they will almost certainly find more backroutes that needs to be fixed ;).

Some final advice:
- Take your time! People are much more likely to play your levels, if they see that you put much effort into it. I am probably one of the slower level creators here and even for a one-screen level I rarely need less than 4-5 hours (not counted any time I spend backrouting my level).
- Do not be discouraged if your first levels have not quite the quality you wish for. Of the first 20 levels I made, only 5 were ever seen by other people (and then only after heavy editing once I got more experienced). Of course there are other people, who create excellent levels right away.

1352
In Development / Re: Update database Lemmix levels to NeoLemmix?
« on: February 15, 2016, 07:06:58 PM »
I do any such solvability tests before I change anything in the level (and check afterwards that the solutions still work).
Attached the levels, loaded in the NeoLemmix editor and saved without any changes.

1353
In Development / Re: Update database Lemmix levels to NeoLemmix?
« on: February 15, 2016, 05:37:57 PM »
I have a few questions mainly about whether some levels are still solvable in NeoLemmix:

1tseug.dat - NULL
ccexplore's solution (see here) does no longer work in NeoLemmix. However a completely different approach still works in NeoLemmix, such that one can save 72 instead of 78 lemmings.
Question: Should I update this level with the reduced save requirement of 72 lemmings? Of course the readme would describe this change and the reason for it.
EDIT: Actually managed to save 77 lemmings in NeoLemmix now, but this is the theoretical maximum of this approach.

1tseug.dat - Rush Hour (click to show/hide)

elfpak01.dat - BL CK FR ME (click to show/hide)

elfpak01.dat - Fortress 13 (click to show/hide)

1354
NeoLemmix Main / Re: Mass replay checking.
« on: February 14, 2016, 09:40:00 PM »
I tried the replay checker as well and everything worked really well.

I don't really care about the speed. Even if it would take ten times as long, it would be OK. However with every new replay, the replay checker catches the mouse again, so one cannot do anything else while the replay checker works. If there is an easy way to remove this, it would be appreciated.

1355
Let me move my PM-questions and namida's answers here:

What is the default setting for this new option?
How does this new option differ from the "One-Way Inversion" option?
Quote from: namida
The One-Way Inversion option is there for compatibility with content that pre-dates this option / comes from other engines, and is not recommended for use with made-for-NeoLemmix levels. The default setting for this new option is on; when the option is on, all newly-placed (and non-steel) terrain pieces will have the "One Way" flag on.

I am satisfied with these changes.

1356
NeoLemmix Levels / Re: NepsterLems - Release thread
« on: February 14, 2016, 02:21:48 PM »
Opinions on aesthetics differ, but seeing that Planet 7 is so popular...

1357
Sorry, I don't understand: In your first sentence, you agree that the default should be changed, but then you give agruments for keeping the current behavior. What am I missing?

But an option to inverse the default would be a good thing for people, who are more comfortable with the other way. :)
Isn't this equivalent to the current "One-Way Inversion" option?
What I am suggestion is not to add another new option, but to change the default setting of the current options.

1358
Closed / Re: [DISCUSSION][PLAYER] Climber mechanics
« on: February 14, 2016, 12:23:59 PM »
Please chack the following suggestions, whether they are practicable and don't introduce new glitches.

Overhang middle/top make difference in trigger falling:
I can see only rather elaborate fixes to this. The first idea would be to keep climbing instead of falling, when on frames 0-3 the hoister-check was successful, but terrain was encountered. Then ideally the terrain checks for frames 4-7 would see the overhang and trigger the transition to faller.
Problems appear when the overhang gets removed in the meantime, but the gap remains: Then the climber would simply continue climbing over the gap in the wall without transitioning to faller or hoister at any time. So one would have to include hoister checks for frames 4-7 as well...
Thus I vote for keeping this inconsistency.

Walls of heights 8 or 9:
I cannot think of anything that is simpler than adding special terrain checks for frames 1, 2 and 3 on the first cycle. To keep the code readable, perhaps one could deal with the first 4 frames separately, e.g. in the form
Code: [Select]
if (LemClimbed = 0) then
  // Check for hoister transition on first cycle
  ...
else if (LemFrame <= 3) then
  // Check for hoister transition on all other cycles
  ...
else
  // Move lemming and check for overhangs
  ...
end

Wall is (10+4k) pixels high, but overhang at height (11+4k):
This seems surprisingly difficult to fix. The best I could come up with, is the following:
Change the terrain check on frame 7 to
Code: [Select]
(HasPixelAt_ClipY(LemX - LemDx, LemY - 7, -8) = TRUE) and (HasPixelAt_ClipY(LemX, LemY - 7, 0) = FALSE)i.e. only transition to faller if the lemming will not become a hoister in the next frame.

Again we have a problem, if the terrain is modified between frame 7 and the following frame 0: If the gap in the wall (which should trigger the hoister transition) is filled during this one frame, the lemming continues climbing and thus passes through the overhang.
So on frame 0, one needs an additional check for
Code: [Select]
(LemClimbed > 0) and (HasPixelAt_ClipY(LemX - LemDx, LemY - 7, -8) = TRUE)which triggers falling, regardless what the hoister-check does.

At first glance a stricter terrain check on frame 4 seems to work as well, similarly to the one done in the first cycle. So instead of
Code: [Select]
or ((LemClimbed = 1) and HasPixelAt_ClipY(LemX - LemDx, LemY - 6, -8))we would have:
Code: [Select]
or ((LemFrame = 4) and HasPixelAt_ClipY(LemX - LemDx, LemY - 6, -8))However then the following weird glitch appears: If there are gaps in the wall at heights 11+4k and 14+4k and overhang at height 11+4k. If the gap at height 11+4k is filled in frame 7+8k, the lemming continues in the climbing animation. However on frame 11+8k, i.e. one frame before the additional terrain check would trigger the falling animation, the hoister-check finds the gap at height 14+4k. The following terrain checks check only at heights 12+4k and 13+4k, so succeeds and the lemming will transition to a hoister.


An alternative would be to disallow hoisting in such cases in general by adding a terrain check at the same height as the hoist-check. However this might break much more replays or even levels than always allowing hoister-transitions.


Btw: What is the the third argument in HasPixelAt_ClipY?

1359
Just looking through my levels in NepsterLems:
- Levels that would not change if every terrain piece is one-way: 24
- Levels that use one-way and not-one-way-combinations: 5
So at least for me, there are much more cases where I want to add the one-way property to terrain pieces than cases where I want to remove this property.

1360
NeoLemmix Levels / Re: NepsterLems - Release thread
« on: February 14, 2016, 09:36:50 AM »
How did you manage to make some red blocks in the Fire set?!
These are lots and lots or the red arrows with the non-red stuff erased and placed above each other with no-overwrite. If you want to study this in greater details: The player allows mass-dumping all levels with F4 on the main menu. Then load 0307.lvl into the editor.

Your solution to Black Hole 18 was introduced by the latest backroute-fix, because I forgot to remove one of the blockers. Still it is close enough to the intended solution to be acceptable.

1361
NeoLemmix Levels / [NeoLemmix] NepsterLems
« on: February 14, 2016, 12:00:07 AM »
 :8(): :8(): Welcome to NepsterLems - A big level pack with 111 challenges!  :8(): :8():

Right on time for the 25th anniversary of Lemmings, all my levels are finished, backrouted by the beta testers and fixed again. Have Fun!

Download link of version 2.0 for NeoLemmix V10.15.20 or later:
   https://www.dropbox.com/s/fkrqzojlfrwnen7/NepsterLems.zip?dl=1
If you want to have the old version 1.11 for NeoLemmix V10.13.18 or earlier, then you can still get it here:
  https://www.dropbox.com/s/1erpv2pyqjkxqe4/NepsterLems%20V1.11.nxp?dl=1

Rank 1: Comet (15 levels)

You always have 5 of each skill. The terrain usually gives you many options - and be sure to use them. Despite being the first rank, you will find only very few any-way-you-want levels.

Rank 2: Moon (15 levels)

Now it is up to 10 of each skill - and much more complex obstacles. Even more so than in the first rank, planning a general route at the beginning is advisable.

Rank 3: Planet (20 levels)

Ok, let's start with giving you less and less freedom to solve the levels. The first levels start around Tricky/Taxing difficulty, but soon progress to Mayhem.

Rank 4: Sun (20 levels)

Now you need more and more tricks, unusual combinations of skills, etc. However the solutions are not yet overly convoluted (main word being "overly").

Rank 5: Neutron Star (20 levels)

By now all the levels can easily compete in difficulty with late Mayhem or late Havoc. Be prepared to use non-linear approaches or (and?) heavy multitasking.

Rank 6: Black Hole (21 levels)

These levels should give headaches even to the greatest experts. Go and let the lemmings perform a complex dance on your screen!
Advice: Play the very last level as a save-as-many-as-you-can level. Even getting close to solving the level is a huge achievement!

Many thanks to...
- DMA Design for inventing the game Lemmings,
- Eric Langedijk for creating Lemmix, which was used to create most of the levels,
- namida for providing NeoLemmix, the FlexiToolkit and technical help,
- Akseli, DynaLem, IchoTolot and namida for pre-release testing,
- all other level designers for all their level ideas, that I reused in my levels,
- and everyone on LemmingsForums in general, for keeping Lemmings alive. It was you, more than anything else, that spawned the idea of NepsterLems in my head.

1362
Closed / Re: [DISCUSSION][PLAYER] Climber mechanics
« on: February 13, 2016, 08:41:19 PM »
Thanks. I corrected my table above accordingly.

1363
Closed / Re: [DISCUSSION][PLAYER] Climber mechanics
« on: February 13, 2016, 08:28:40 PM »
Here a list of the frames, positions and check-locations (as I understand it - so no guarantee). If a Hoist-check is made, the Terrain-check only occurs if the Hoist-check was successful.
Frame    Y-Pos    Hoist-Check    Terrain-Check
00-7never occurs
10-8-7
20-9-8
30-10-9
4-1none-7, -8
5-2none-9
6-3none-10
7-4none-11
8-4-11-9, -10
9-4-12-10, -11
10-4-13-11, -12
11-4-14-12, -13
12-5none-12
13-6none-13
14-7none-14
15-8none-15

This tells me to expect the following irregular behaviors in addition to the one described by namida:
1) If the wall is 8 pixels high, the code does nowhere check for terrain at height 7.
2) If the wall is 9 pixels high, the code does nowhere check for terrain at heights 7 or 8.
3) If the wall is (10+4k) pixels high, but there is an overhang at height (11+4k), the terrain check at frame (7+8k) detects this overhang and the lemming falls down. If this setup appears for any other height of the wall, the lemming may climb it.

Finally in your code snippet for frames 4-7 you have the line:
Code: [Select]
or ((LemClimbed = 1) and HasPixelAt_ClipY(LemX - LemDx, LemY - 6, -8))Why is it LemClimbed = 1 and not LemClimbed = 0, if you want to check for the first cycle?


1364
Closed / Re: [DISCUSSION][PLAYER] Climber mechanics
« on: February 13, 2016, 07:13:48 PM »
I am trying to understand the code first, before forming an opinion on possible changes:
- During frames 0-3 the climber does not change position, but the checks to transition to a hoister are made higher and higher, i.e. for hoister purposes, the lemming climbs on frames 0-3.
- During frames 4-7, the position of the lemming changes. However during frames 4-6 he cannot transition to hoister (assuming the terrain stays constant), because the terrain checks are actually made for lower pixels than during frame 3.
Is this correct?

1365
Closed / Re: [DISCUSSION][PLAYER] Climber mechanics
« on: February 13, 2016, 06:52:21 PM »
Will look at the code soon, but here is something else (that I wanted to post in the bug report thread, but it's closed again!):
If the wall is precisely 9 pixels high with an overhang at 8 pixels, the climber may climb this as well (at least in V1.42).

Pages: 1 ... 89 90 [91] 92 93 ... 125