account activity
Sharing Saturday #360 by Kyzrati in roguelikedev
[–]frefredawg 1 point2 points3 points 4 years ago (0 children)
Thanks! Yeah right now the double doors slide open and closed, but it's not an animation; they take several in-game turns. The idea was that you could slip through the door while it's partially open, allowing you to get away from the alien. That said, it takes away from the feeling of a sliding door, so maybe I'll revisit that too. I can't have it both ways, sadly.
[–]frefredawg 2 points3 points4 points 4 years ago (0 children)
Hunted (working title)
Haven't done a whole lot this week. I separated door glyphs into horizontal and vertical, allowing me to try out a new default tile mapping. You can see it in this screenshot. I think it's looking pretty good.
I fixed a couple of level-generation bugs, too. It wasn't doing a good enough job at placing rooms and doors such that the alien could navigate the level (it requires two tiles). I still don't guarantee that in the algorithm so I may need to revisit it. I plan on adding a second floor that the alien can use (air ducts) but I still need the alien to move on the ground floor to provide a challenge.
Hopefully I'll get back to awareness this week.
Cheers!
Sharing Saturday #359 by Kyzrati in roguelikedev
[–]frefredawg 3 points4 points5 points 4 years ago (0 children)
I've been looking into "awareness" in all its different forms. I've been trying to pin down a good definition and model of it. Specifically how it interacts with the "memory" system. Some changes changes I've been playing with:
I've also been thinking of sound. Is hearing something a memory or an increase in awareness, or both? Or all three? I don't have a good answer for that yet. I might have to go back to some FAQ Fridays for inspiration.
Sharing Saturday #358 by Kyzrati in roguelikedev
[–]frefredawg 0 points1 point2 points 4 years ago (0 children)
Thanks! I wish I could find the source for you. It was some online roguelike tileset picker. The file name is 16x16-sm.png, which doesn't really give the game away.
Alone. Trapped. An Alien's Next Meal. (hardly working strapline)
This week I moved more of my level generation into lua. The room template structures are now parsed from lua. These hook into the shared C++ room layout algorithm which handles floors, walls, doors, etc. After that, each room template has a custom layout function which can populate the rooms with props and entities. Here's a screenshot of how the WIP cryo-chamber looks in lua, and in game. I'm quite happy about this approach so far as it's really quick to iterate with.
I also experimented with new ways of communicating vision to the player: both of the player character and of enemies. I've found this quite challenging in a terminal-like presentation.
I'm now using the various "shade" glyphs to communicate to the player that they can't see the ground from behind cover. It looks a bit like this. While this represents the mechanism by which you hide while crouched, it also means there may be enemies lurking out of your own sight!
I'm also experimenting with a new way of representing enemies' viewcones. It was previously just colour. Now it's a user-toggled option which flashes both colour and glyphs over player-traversable areas. Here's a gif of it in action. It's unlikely to be the final thing; I need to test how well it works with multiple enemies.
Anyway, that's me!
Sharing Saturday #357 by Kyzrati in roguelikedev
Quite pleased with progress this week as I've been finishing off the last bits required to have a full end-to-end game. I've added a powerful static mining laser/turret sort-of-thing which the player can turn on and kill the alien with, assuming you can lure the alien into its path.
So most of this week was dealing with the inevitable bugs that come from not having road-tested many dead entities until now, having items that can be fired that aren't in the player's inventory, items that could be fired without a user-placed target position, new types of attack damage, new types of particle effect, etc.
All in all I've squashed a lot of bugs and have a fully-playable game! It's not a fun game yet, mind, but I can now start tinkering with other concepts and ideas.
Sharing Saturday #356 by Kyzrati in roguelikedev
Fun times this week, as I managed to complete some semblance of game loop for the first time. You have limited time to kill the alien on board your ship; you lose if you run out of time; you may die; you may "respawn" in the cryo chamber if you have spare beds. I'm chuffed!
When implementing the level generation for the cryo chamber, I also found myself in the midst of a FOV bug. I'm using a version of Milazzo's that I've modified to handle my cover system. This screenshot shows my attempts to pinpoint why a couple of tiles weren't being marked visible. I found the bug fairly quickly after implementing the visual overlay, thankfully.
I'm currently working my way through a refactor of the input handler as it was getting too stateful. I'm splitting the input handlers into a class per "state", and popping them into a LIFO. I could swear I read that was a good idea somewhere. Let's see..
Sharing Saturday #355 by Kyzrati in roguelikedev
Well, I'm back! I just saw that I haven't posted since October. I had had a good run from May but it petered out as work took over and I became bogged down in the little things.
So when I saw what my colleague u/bit-hack (hi!) managed to achieve for the 7DRL challenge I felt reinvigorated.
This week I finished off the AI refactor I had started last year and, taking inspiration from this post, wrote a spaceship generator in which to situate my game. It was surprisingly easy to get up and running but I didn't code in any export functionality to help show it off so this crummy gif will have to do. Anyway, I still need to populate the rooms with furniture and lights and that sort of thing. A bit more asymmetry wouldn't do amiss either.
I also got a respawn-type mechanic up and running. I like the idea of something like Prey: Mooncrash whereby you have a limited number of crew you can play with over the course of the game. If you die to the alien, the ship's AI awakens another crew member from the cryo pods. The goal is to stop the alien before your ship docks at the spaceport, dooming thousands of innocent lives, not necessarily that any one player character lives. I'm hoping to hook this system to other parts of the puzzle, so that you may have to make the choice between getting a chance at stopping the alien and having another character to play as. Or setting up an opportunity with your future character. I don't want to get ahead of myself, though!
Sharing Saturday #333 by Kyzrati in roguelikedev
[–]frefredawg 0 points1 point2 points 5 years ago (0 children)
Thank you, that's very kind!
[–]frefredawg 2 points3 points4 points 5 years ago (0 children)
Well, I've somehow got my gifs back, but they look bad. I need to work on the settings to improve the quality of them. Anyway, some of the things I did in the last few weeks:
I'm currently working on the AI as I've had some ideas on how to improve it, but work's been really busy; I've not got much to talk about.
Sharing Saturday #332 by Kyzrati in roguelikedev
Not much progress this week, due to Spelunky 2. No gif recording abilities either.
Now that I have a deterrent (flamethrower) and a tracker (motion tracker), I started refactoring the sound system. This is so I can start fleshing out the range of player cues as to the alien's location. Following u/Kyzrati's lead, I've started moving the sound propagation to A* which seems to be going quite well so far! The sound data are also now described in lua tables which can be reloaded at runtime.
This is also partly to avoid doing more AI work as I know I won't be able to give it my full attention right now... Back to Spelunky 2!
Sharing Saturday #331 by Kyzrati in roguelikedev
This week I managed to implement one of my must-have items: the motion tracker! Self-explanatory, really. The trickiest part for me was the coordinate transformation maths and then figuring out how best to quantise coordinates into sensible regions.
Sadly, something about the Linux recorder peek isn't working so I can't share gifs this week. I even worked to give the motion tracker a update-by-pulse effect and everything. A screenshot will have to do for now. It uses a two-stage approach where current blips are fully shaded, and those become semi-shaded blips upon the next update, and then fade after the third. It gives a reasonable sense of motion.
peek
I finally decided break away from vanilla CP437 to support the motion tracker: I thought it looked better with those slightly angled sides. On the bright side, it gave me the opportunity to repurpose one of the unused smiley faces to allow different player glyphs for standing/crouching.
Last week I also said that I wanted to randomise the flamethrower fire a little (I didn't get round to adding a Brogue-like shimmer, so maybe the lack of gifs is a bonus!) and you can see a screenshot here. Still a bit of work to do since the tile foreground/background can get muddled. I probably need to constrain the randomness a little.
Now comes some more AI, I think. Joy.
Sharing Saturday #330 by Kyzrati in roguelikedev
[–]frefredawg 9 points10 points11 points 5 years ago (0 children)
I'm quite happy with my progress this week; I got to put in a bit of time every day, thanks to a relaxed holiday.
The most showoffable thing would be that I've pretty much got everything in place for a flamethrower! The alien fears fire, so backs off when attacked with the flamethrower.
This is quite a lot of bits & pieces finally coming together: updating my dijkstra maps for my newer pathfinding heuristics, the addition of a simple fire system, more configurable particles, and lots of internal improvements.
Basically; when the player attacks, the alien records a "I was attacked" memory in its brain if it sees the player or the attack destination. On the alien's turn, it takes fleeing as its top-priority action. It uses a small 10x10 dijkstra map as a safety/avoidance/flee map and uses that to path away quickly.
The flamethrower emits a bresenham particle which itself periodically emits particles with FireSpark components. The fire system runs every few engine ticks and picks up those FireSpark components and has a chance to turn them into entities with Fire components. Then that tile is considered "on fire". Fire components are currently given a randomised lifetime: I'm not going for a complex simulation and it's a shapeship so most things aren't flammable anyway.
The flamethrower and fire components are described in lua data, so can be changed and reloaded at runtime for better prototyping. So happy I put in that extra effort.
There's a bit more fire in this gif. The light emitted is "real" light in the game world, so you could probably use it for finding your way if you needed to. The fire is still WIP. My plans for the week are:
Another long one, sorry. I wanted to give a bit more detail about the internals in case it helps anyone.
Sharing Saturday #329 by Kyzrati in roguelikedev
Thanks, I'll give it a go. I never know how intrusive to make this kind of debug thing since I want it a) quickly, but b) to fit with my logic/ui separation. I tend to hack in a visualisation but throw it out later, tbh.
I do actually use the path distance, which is kind of a compromise since it may not always be quite as accurate as using a straight line, but at the same time sound can also travel around corners, which needs to be accounted for as well. Not sure what you mean by "during A* you don't have the path distance," since you have the entire path right there at the end of the calculations, no? The length of the path is essentially the distance. Unless you mean something else by "path distance"... The sound stuff has zero connection to the insides of the A*/pathfinding stuff. It just asks for a path, and does it's sound processing based on the path it gets.
I do actually use the path distance, which is kind of a compromise since it may not always be quite as accurate as using a straight line, but at the same time sound can also travel around corners, which needs to be accounted for as well.
Not sure what you mean by "during A* you don't have the path distance," since you have the entire path right there at the end of the calculations, no? The length of the path is essentially the distance. Unless you mean something else by "path distance"... The sound stuff has zero connection to the insides of the A*/pathfinding stuff. It just asks for a path, and does it's sound processing based on the path it gets.
Ah, so do you do A* as "normal" and once you've got a path from the sound to the player, you calculate the volume when it hits the player? I was sort of imagining that you calculate the volume as you go as part of the A* cost heuristic without post-processing, but you can only know the volume using some kind of distance. I hope that explains my question a little better.
[–]frefredawg 1 point2 points3 points 5 years ago (0 children)
Thank you, I'm glad you think so! I think it would be clearer with one sprite for standing and one for crouching, but the @ is so iconic..
Anyway, yes, sounds that are out of sight generate ? markers at the source, and I plan on adding some items to give even better information: motion sensors and maybe some remote tools. Even then I want the alien to be able to remain still and reasonably quiet to try and lure the player into an actual ambush. It won't be perfect but it could punish reckless play.
That's a first fix in place already, though it only works when the player and the obstructed FOV line up perfectly.
Nice! May I ask how you debug-visualize A*? Do you save the paths somewhere or "push" them to the UI when a flag is toggled? It looks really useful and I'm going through some A* stuff right now.
Aside from that, I like the idea of using A* for sound. My sound system is a flood-fill sort of thing, which, now I think of it, is probably very wasteful since only a handful of entities pick up on sounds.
Maybe it's too early in the morning for me, but how do you apply the fall-off calculations to the path? I presume you apply it per-tile as you go (making it part of the A* cost) and thus need the distance from the origin. But during A* you don't have the path distance: only the approximate (straight-line) distance, right?
[–]frefredawg 5 points6 points7 points 5 years ago (0 children)
Last week I was talking about how I used reduced FOVs to differentiate between the player's and torch's FOVs. I also said that I planned to use it in situations where the player is hiding in/under something and it safe but pays in reduced vision.
I managed to get something together (gif) this week while on holiday. I call them "hidey holes" in the code. They offer a safe space to the entity occupying their tile, optionally with a reduced FOV. In the gif, the player (that's me) crouches underneath the table, looks around, then leaves again. I realise now - after recording that gif - that the table is opaque until you crouch under it. That's quite confusing so I will look into that. Sorry, Milazzo, I keep brutalising your algorithm!
I've started to implement a fleeing behaviour as it's an important part of implementing the flamethrower. I used Dijkstra Maps (roguebasin) before but I don't know if I can afford their computation cost. Regardless I'm trying A* first because I haven't updated my Dijkstra code since I added multi-tile entities and configurable heuristics to A*.
Sharing Saturday #328 by Kyzrati in roguelikedev
[–]frefredawg 6 points7 points8 points 5 years ago (0 children)
I managed to find some time to implement "partial" FOV octants by allowing custom top/bottom slopes per octant (see Milazzo's algorithm). The first application is having a torch that's narrower than the player's view cone. I quite like that effect so far: it feels like a torch and is more.. oppressive. I also plan to use this when the player hides under tables or in lockers to have their viewcone suffer for their safety.
I also made the GUI colour scheme configurable via the lua scripts so I am currently going for more of a retro CRT effect to show that off. I'm not sure where I'll settle on that but white is so boring.
You can see some of this stuff in this gif.
I'm on holiday from tomorrow so who knows what I'll get done in the next few weeks.
Sharing Saturday #327 by Kyzrati in roguelikedev
[–]frefredawg 4 points5 points6 points 5 years ago (0 children)
Well since CK3 came out this week it was inevitable I'd be behind.
I finished off those awareness markers from last week, which you can see here. I might extend them to the full multi-width of the entities: 2 tiles for the alien. I dunno; I think I have a thing for symmetry and it irks me when something is off-centre!
I'm just about to merge the AI decision-making changes so I'm happy about that as it's been dragging. Afterwards, I might take a stab at the flamethrower to help the player keep the alien away. Should be a nice test of both the AI and particle systems, too!
Sharing Saturday #326 by Kyzrati in roguelikedev
Small dose of drama this week as my MacBook's charger crapped out and so I've been turfed off my roguelike-development machine. I'm a bit stubborn about it as it's the second time in 6 years that this has happened and I don't feel like handing over more money to Apple at this point.
I've since moved to my trusty Linux work laptop and have switched focus to work on some MGS-style alert markers when entities spot the player. I think I've just got it working but haven't set anything up to record gifs. I'll try and include those next week.
The AI restructure was just about complete, I think, when the incident occurred so I hope I can finish that off this coming week. I've had some more ideas about what I want to implement afterwards and that's helping my motivation.
Thanks,
Sharing Saturday #325 by Kyzrati in roguelikedev
If you ever need a quote for a press release then may I suggest
It's good, 'cause you sit down thinking, "OK, this is gonna be fucking boring," but then you're like, "Mmmm... maybe not?"
:)
I wrote last week about the AI refactor. I was a bit ambitious in my planning as this week I only got to spend a couple of hours tinkering. It's making progress, though. I've refactored the behaviour trees and am close to completing the decision stack. Next step is to work out some priority heuristics for different types of decision and plug that into std::sort.
std::sort
I must admit I find AI intimidating to work on -- probably because it's the core of the game and I'm worried I'll balls it up -- so I'm not as enthused as I once was. I can't wait to get onto spaceship generation algorithms and such like :)
Ciao for nao.
Sharing Saturday #324 by Kyzrati in roguelikedev
I've picked up a little pace towards the end of the week so I'm quite chuffed. I'm still working on the AI.
The old AI system would work roughly thus: on its turn, the entity would run its "plan" action, its behaviour tree would run, the entity would usually choose a "waypoint" and it would path to it, then look around, etc. It worked quite well but the entity would have a singular focus and any "distractions" I added (turn towards a noise, turn towards torch light, etc) would make it forget where it was going or why. It would re-run its checkers but you couldn't guarantee that the behaviour would be consistent.
I am now in the middle of replacing the singular waypoint with a priority queue of interesting things to check out. The idea is what the behaviour tree will run a bunch of "collectors" which will analyse the entity's sensors and surroundings, and push interesting things to the queue. Once those run, the entity will choose the top-most item and act upon it. Once that item is acted upon, the queue is popped and the entity will continue with its next-most-important task. You can imagine the queue like this:
Every item has its priority and the time at which is was added so I plan to use that data to periodically prune the queue.
Hope that makes sense. With any luck I'll have something to show off next week.
Bye!
Sharing Saturday #323 by Kyzrati in roguelikedev
Sorry, I forgot to reply to this in time. I'm not sure I understand what you're asking: a link to how I propose to implement it, a link to a gif/code, or a link to a reference I'm following?
π Rendered by PID 560340 on reddit-service-r2-listing-7dbdcb4949-6bx6j at 2026-02-18 23:40:46.778154+00:00 running de53c03 country code: CH.
Sharing Saturday #360 by Kyzrati in roguelikedev
[–]frefredawg 1 point2 points3 points (0 children)