next »

[Kyzrati]

Last two interactive machines for now: Repair Stations and Recycling Units.

[JobLeonard]

I showed your stuff to a few friends. Their responses:

"Goddamn!"

"Hnnnng... cleanup on aisle three."

"Curse you for showing me this when I can actually play it yet!"

I think that's a compliment . And I can't exactly blame the last guy, I feel his pain...

(pointed them to your blog - they've probably subscribed by RSS since)

[Kyzrati]

Haha, I love that second one. And of course happy to hear that more people are excited--thanks for sharing these

I, too, wish I could show nothing or little of the project while in development then suddenly surprise everyone with an awesome near-finished game where I hadn't already shared 90% of the features individually along the way, but such is the life of us indie devs who have to rely on sharing as much as possible to make up for our lack of a hefty advertising budget :/

2014 will be the year!

[Kyzrati]

Another GUI upgrade: Part Info Visualization

[eigenbom]

Good luck for 2014 dude! I'm looking forward to playing this when it's done.

[Kyzrati]

Thanks! While I can't yet promise "completely done" for 2014, I can definitely say it will be released and very playable. Planning on releasing once development reaches alpha.

[Kyzrati]

Something every roguelike dev has to consider: A trade-off between eye candy and freedom of pace. (An overview of this issue as it relates to Cogmind development.)

[JobLeonard]

For some reason the comment I posted never showed, but I wondered: why not play out turns in parallel?

[Kyzrati]

It did show, and I replied immediately, you just didn't notice you replied to the wrong post Apparently you followed the link to the old allies post from last year and commented there. You'll still see your comment listed under the sidebar Recent Comments sections, and can see where it ended up.

My response: "Playing out turns in parallel" is the definition of realtime, but Cogmind is and always will be a turn-based game.

While there do exist (very rare) hybrid types, like turn-based games where all entities choose their action then carry them out at once, they are forced to have simple actions that are comparable in time cost. Cogmind's time system is more complex than that. That and even when using such a method, simple things like movement then become tedious by comparison to what you can do in a normal roguelike, e.g. race to the end of a corridor as quickly as you like, regardless of its length.

[JobLeonard]

  whoops

Fair enough, seems you have put quite a bit of thought into this.

"Playing out turns in parallel" is the definition of realtime

Actually, I don't quite agree with this. What I meant was playing the animations of multiple turns in parallel, if the turns in question obviously do not affect each other. It's kind of like dealing with embarrassingly parallel problems in programming. Let's say A attacks B with a gun and C attacks D with a gun (so no explosions affecting terrain or something). You can have the internal system play these out in turns, including sequential descriptions of text, but play the animations in parallel.

So the idea would be to "stack" animations until you reach a synchronisation point (a death, terrain modification, etc.).

[Kyzrati]

Ah, I see what you mean. I wasn't thinking along those lines when replying since I was only taking into consideration my own situation, which was not focused on too well in what was honestly a pretty rambling post. My own issue was more about how to best/quickly determine what you can and cannot see *or* hear, in order to skip those animations entirely. (But I didn't provide any details so it may not be too apparent all wrapped up in another topic like that )

I just now updated the original post to include a summary of my solution, as implemented earlier today. Might as well copy it to here:

Today I implemented the solution and after some preliminary testing it seems to be working nicely. You can walk along just fine while large-scale battles rage on elsewhere on the map. I also managed to hack it into the existing state machine with minimal collateral damage, and only used one of those much maligned "goto" statements in the process

At the most basic level there are only two types of animation in the game: shots and explosions. They're now filtered more or less using the same method:

• If the origin is visible or audible the entire shot/explosion is animated normally.
• Else if any part of the LOF to point of impact (or final AOE for explosions) will be visible, the entire shot/explosion is animated normally.
• Else instantly apply the shot's effects at the point of impact (or explosion's effects to all objects and terrain within the area of effect).

Because it's not possible to know in advance (i.e. at the time of shooting/explosion) whether a final effect will audible until that effect is fully applied (the process is too complex to predict everything beyond the LOF/AOE state), the game will also pause action for as long as it takes to play any resulting audible sounds such as impacts and destruction. This means you'll still be able to hear nearby combat that may not be visible, and if there are numerous sounds from sequential turns they won't all be mixed together in a jumble of noise.

There's still some more testing and tweaking to do, but at least the solution took a lot less time to implement than it did to mull over the possibilities.

[JobLeonard]

Is there sound falloff? As in: the more distant, the more quiet? Because I don't see that mentioned anywhere.

[Kyzrati]

Yep, both falloff and dampening by terrain materials are already implemented. I have a completed draft post about that coming up soon (just too much development going on to publish everything at once!). For falloff there are four different models and several adjustable parameters.

[JobLeonard]

So I assume when a sound is so soft you can't hear it, it is skipped?

[Spelle]

Info visualization panels and animations are sweet. I sense something like ADOM with guns and robots, which is super awesome.

[Kyzrati]

So I assume when a sound is so soft you can't hear it, it is skipped?

Yep. In short, sound sources pathfind to the player from their origin and decrease in volume via falloff and dampening; any sound that reaches 0% volume before arriving at the player's position is not played.

Info visualization panels and animations are sweet. I sense something like ADOM with guns and robots, which is super awesome.

Thanks! I suppose you could say ADOM with guns since it is ASCII turned sci-fi, though I'm definitely going for something more player-friendly than ADOM. There's full mouse control, though at the same time you don't have to touch the mouse if you don't want to--full keyboard support is available, too.

You'll also see that character-wise the game mechanics are quite different from your standard person-centric roguelike, so I'm sure someone out there's done a better job of "ADOM with guns" before. (Maybe Caves of Qud? Not sure since I haven't played it before. Or maybe Cataclysm is a somewhat closer fit, despite being a survival game rather than a dungeon dive.)

I'm trying to take rather traditional roguelike gameplay concepts and modernize everything while still keeping as close to that tradition as possible. I think the results will be pretty interesting and unique. So many samey games out there these days...

[JobLeonard]

I suppose you could say ADOM with guns since it is ASCII turned sci-fi, though I'm definitely going for something more player-friendly than ADOM. There's full mouse control, though at the same time you don't have to touch the mouse if you don't want to--full keyboard support is available, too.

I'm seriously wondering if and how you are going to pull this off - the more elaborate the mechanics, the more the interface tends to turn into a labyrinth. Gnomoria might be a DF light, there's still a lot of options to dig through.

[Kyzrati]

Simulationist games (e.g. DF, Gnomoria) tend to have a lot more commands and actions (especially sub-menus) to worry about than a game focused on one PC. Maybe you're thinking Cogmind is a lot more complex than it actually is?

There are only 5 basic actions in the game: get, drop, equip, unequip, and fire, plus another hybrid action (get-attach) and another one used less often (swap). Keyboard interaction with equipped items uses their associated letter (a-z), while inventory items use their associated number (0-10). Unlike most complex roguelikes these are always visible--no submenu required, so reference and access is even faster.

There are only two types of sub-menu: hacking (covered before here) and ally orders (an extensive blog post about those is coming in a few days), which use letters/numbers for their options (all of which are visible and labeled on opening those menus). There may end up being a few more rarely accessed windows, but in all cases the interface is going to be 100% intuitive, with buttons for mouse users and letters or numbers for the keyboard. To make things even easier on mouse users, the entire item interface supports drag-and-drop!

Back in 2012 there were several compliments from players on the prototype's interface being something that seemed like it could be so complex yet turned out to be quite simple to control. I'm glad for that since the current interface has been much improved since then.

[JobLeonard]

Maybe you're thinking Cogmind is a lot more complex than it actually is?

Well, it is a roguelike . I tend to assume those are complex until proven otherwise.

[Kyzrati]

Good point

I'd like to say the design intent has been to create something that is both simple and complex. If you want a coffee break experience you can use the drag and drop UI to strap on a few parts and blast some robots. But for those players with the time and inclination there are a lot of optional details to dig into and parts of the game to explore, including plenty of interesting mechanics, though knowledge of how they work isn't required for a good time