A few other thoughts I had after playing:
The enemies have fairly simple AI, where once they notice you, they just chase you infinitely. I think that can work, but it could perhaps be improved by doing this:
Give each enemy a bit of a different movement speed. - That way, they won't bunch up as much, and it makes them feel a bit more different and therefore more natural.
- For example, if the current running speed for enemies is, say "5", you could make some move at speed "3" (quite slow) and they're therefore easier to get away from. Another could be "5" (full speed) who slowly gains on you, and is therefore more persistent and more dangerous.
- This has the benefits of making them feel like they have different personalities, different threat level, and produce different dynamics for the player to deal with. All just by varying their speeds!
- (Another character could be 4, another could be 3.5, etc). You could just hand-tweak their speeds, or give them some code that randomises their speed on Start() or something.
Also, you could add a basic check system that lets a chasing enemy go back to being a pastroling enemy.
- For example, add some code that runs when they are in the chase state, which says something like, "Each Frame (or each 0.5 seconds), do a raycast to see if I can see the player (if it gets blocked by a wall or other collider, it counds as they can't see the player for that check).
- If I can't see the player on that check, increment a timer/counter. Keep adding up these checks. "If I don't see the player for [6 seconds], go back to patroling/walking around."
- If at any point within those 6 seconds they DO see the player, keep chasing, and reset the counter to "0" again.
- So, they keep chasing the player, but if they don't see the player for everty check they do within 6 consecutive seconds, they go back to patroling. At that point, they could also say something like "Damn it! They go away." Or, "Where did they go? Run and hide! I'll find you later!".
- This lets the player know the enemy gave up, and it's also satisfying to hear that you've outsmarted them.
MUZBOZ
Creator of
Recent community posts
Something that kills me, is trying to deal with "corners" and "end caps", like trying to have things all connect or end neatly, without resulting double ups, or z-fighting.
You seem to have techniques that deal with these, as your resulting levels look really clean, without these issues.
Do you find you need to make special allowances for these sorts of things (like special pieces to cap things off in places?)
Like, having a "ledge cap" around the outside of each new level of the building at the bottom level of each floor. Or architraves around an inner or outer corner of a room.
I guess one can resolve z-fighting by using triplanar mapping, which can completely hide z-fighting even though it's technically happening. Do you rely on that to solve some of those challenges? :)
Really enjoying the super thorough blog posts. I've been working on a proc gen game (Secret Keep) for years, but I get a little hung up on the complexity of procedural generation, and really needing a more methodical approach, and better mathematical and algorithmic underpinnings! Your blog posts give solid examples of the sorts of things I mean!
I think the main thing is definitely needing a DATA FORM of the level, that can be begun, added to, adjusted, pruned, and then finally realised in physical form later in the process...
I definitely tangle and trip myself up trying to make a more improvised "let's just roll through some processes and try to generate something cool" approach!
It's being able to double back and check relationships between things, detect things that need to be removed, or placing something based on finding the appropriate context that I really need to do better!
That's cool! Interesting to see your various uploads this week, with the maze generator (cool stuff!), and I guess seeing some of the results of that appearing in this (I assume!).
I feel like there's a touch of "Eldritch" elements in this perhaps (?) with the possible connections between rooms through the walls at various heights. Not sure, just reminded me of some of David Pittman's approach there. :)
I like the vibe of the player controller, with the way you land and recover, by sort of crouching out of the jump. That's cool.
Always fun to see your creations!
I had a go. The pistons are very frustrating because the player is not in control while on them, the player sort of bounces around uncontrollably. Like, it's just glitchy. So I had trouble having fun because of that.
I like the overall look and vibe of the game, though. Nice work. :D
If you had the time, you could try to tweak the code, and see if you can "parent the player to the pistons" while touching them, and then jump off to "release the connection". Something to consider.
Thought I'd upload my video playtest, in case it's helpful for you. Rock on buddy.
(Feel free to remove this comment if you want!).
Looks awesome.
For some reason, it crashes to desktop when I go into the first portal to begin the scenario.
Perhaps I need to update Quake Spasm, as I haven't played Quake in a while. But thought I'd report the issue.
Game runs fine in the menu, and the little intro space. Not sure why it crashes after that. I've tried 4 or 5 times. Same thing each time I go in the starting portal.
My main thoughts on improvements (especially for a first time player) would be:
Make the controls a bit more consistent, and make sure you're letting the player know the controls for each part of the game.
I got stuck trying to burn the symbols onto the tablet, because I had to "Hold E", but those instructions couldn't be found anywhere.
I'd suggest:
- Hold RMB to Burn the Symbols into the Tablet (and show tip onscreen).
That would keep those controls the same for both actions.
:D






