Messages

16

Programming / Re: Comic Action Games

« on: February 02, 2013, 11:57:38 PM »

The idea itself is cool, but the phrase "Multiphased Kill Sequence" sounds so awesome.

I am going to try and work it into conversation some time.

"Where's Tim?"

"He was subjected to a Multiphased Kill Sequence. He did not survive."

17

Challenges / Re: Early 7DRL Declaration

« on: February 02, 2013, 01:45:40 AM »

I think I'll make an experimental 7DRL that has a portal gun and see what that plays like. Experimental in the sense that the gameplay might turn out to be very boring.

18

Challenges / Re: Early 7DRL Declaration

« on: February 02, 2013, 01:30:48 AM »

I've been toying around with the idea of using the concept of weeping angels from doctor who for a 7DRL. Players and angels would have directional field of view, similar to the heroes in Darren Grey's Gruesome. If an angel is in anyone's line of sight (including other angels), it cannot move. Otherwise, it can move very quickly (2 or 3 tiles per turn). In order to aid the player, the maps will have mirrors (perhaps even mirrors who's orientation can be adjusted). Note that the field of view will have to be a simplified 2D ray tracing algorithm to accommodate the mirrors. Given time (in other words, probably not), you could add in more tactical depth by allowing the player to sprint for short distances, or allowing angels to close their eyes (no cheating AI though).

Sounds like SCP-173 (http://www.scp-wiki.net/scp-173). (as a reference this is cooler than Doctor Who, plus I think they came up with the idea first before Dr Who)

19

Programming / Re: 7DRL Development Kit

« on: February 02, 2013, 01:14:32 AM »

Uh, before you go to all that effort, have you seen the T-Engine? Lua-based, numerous customizable level generators, LOS, lots of options like hex, full graphics and sound support... You would be very hard pressed to rival it.

Yeah. Let's give up everything we do because somebody has already done it. We would be still living in caves hunting polar bears if everyone kept thinking like this.

I think Darren is just warning against reinventing the wheel.

20

Programming / Re: Press to move or press to single-step?

« on: December 21, 2012, 09:46:50 PM »

On a related note how can per action animation be handled? Eg a monster launches a rocket towards a Target which explodes. If a rocket is depicted as flying from the monster to Target for 200ms and then an explosion takes another 200ms that's pretty quick, but it still means one monster's turn taking 400ms. Imagine 10 monsters firing each turn. The player has to wait 4 seconds per turn even if they are holding the move key down.

It doesn't seem correct to run the animations in parallel because the turns are in series and it causes strange results (monster hit by arrow appeared to dodge it before it arrived).

Dungeons of dredmore had a lot of animation, inc movement animation and as a result you had to wait for all monsters to animate each turn. Which could be very annoying when you wanted to wander around quickly while your pet was in combat with a monster. You can't even tap tap tap, you have to sit through animations.

Perhaps a solution is to skip animation if the players taps an action key and immediately process the key. But this then makes it easy for the player to accidentally skip animations.

21

Programming / Re: Random Roguelike Town

« on: December 09, 2012, 02:28:12 PM »

wow that makes quite a difference. my eyes now get drawn to the room contents rather than I guess being confused about the walls. So now I am wondering what is in those locked chests and down those stairs.

22

Programming / Re: Random Roguelike Town

« on: December 08, 2012, 10:18:45 PM »

I also noticed the top of the walls are the same color as the ground but forgot to mention it

23

Programming / Re: Torso & Head direction

« on: December 08, 2012, 03:49:34 PM »

DoomRL remembers the direction of last move you took. This influences dodging. It is easier to dodge missiles moving perpendicular to your path.

Did not know that...

24

Programming / Re: Peril: Experimental Survival Horror Roguelike

« on: December 07, 2012, 09:40:28 PM »

For the roguelike I am making I added small spider-like alien creatures and scientists. I spawned into a room with some scientists and then left them and went around shooting spiders all over the map. When I returned back to where I had started I suspected I would find dead scientists, what I didn't expect to find was the dead scientist bodies swarming with over a dozen spiders. It was an accident of the spider AI which didn't switch back to random walking once the target was dead. So after killing the scientists they kept walking over them and ended up buzzing around the dead bodies as if they were feeding. I tried with scientists getting infected by being bitten and 200 turns later (approx) spiders burst out them. That's all gore kind of horror though.

I added a weak scare jump kind of horror by putting crevices into random walls on the map. Single tiled spaces that are pitch black. You can't see what's in one until you try to move into it. If it's empty you move in (and can use it to hide). But if something is already in the hole it is instantly revealed - if I add a sharp "scary" sound at this point it'll probably reinforce the jump scare. It's not much of a jump scare but it does hopefully make the player apprehensive about looking in the holes. The thing in the holes are crawly things like giant snakes,giant millipedes,spiders, etc. I think filling a very low % of holes with nasties works best as it makes the discoveries rarer and more effective when they do happen.

I also considered the idea already mentioned above to have monsters suddenly move in real time, but not as a surprise the player doesn't expect. I was thinking more like the "quick hide!" sequences that get triggered in Amnesia and the Penumbra games where activating a certain item or entering a certain area. I was thinking that the player accidentally making a loud sound could trigger it (like in left4dead) by attracting attention. It doesn't have to happen often, maybe only once per level. This would then leave the bulk of the game to be standard turn-based roguelike.

The way I was thinking it could work is that when a chase is activated the game initially pauses to either play some suspenseful music or flash something up on the screen to indicate what's about to happen. Then the game world starts forcefully advancing at something like 1 tile per second, or however fast the player moves. Some monster or monsters are released that are coming towards the player's position so the player has to run or hide. Then after some time the monster has passed and the game goes back to regular turns.

25

Programming / Re: Random Roguelike Town

« on: December 04, 2012, 09:42:38 PM »

A few dozen citizens walking around randomly between shops and their houses would be cool. Maybe stray dogs or cats and a horse and cart going up and down the road. Just to make it feel busy like a town is going on around you. Then you can also do cool stuff like make the player come across a town that has no activity at all and the player will notice that something is wrong.

26

Programming / Ranged attack idea

« on: December 04, 2012, 12:50:02 AM »

The game I am making the player is up against a lot of melee based monsters and is restricted to ranged weapons like pistols, shotguns and rifles to deal with them. Because there might be hoards of monsters I want the player to be able to fire multiple shots in a turn, possibly at multiple oncoming targets.

Accuracy should decrease with number of shots fired and number of targets fired at. At first I thought to have separate modes like "burst fire mode" for a few accurate shots at a single target, "panic fire mode" for lots of inaccurate shots at one or many targets. But as I thought it through I kept adding intermediate modes (eg "burst spray" for a few half accurate shots at two targets, "double shot" for firing a single accurate shot each at two targets).

Then it struck me it would save the work and be a nice to let the player decide for themselves how many shots and targets to fire at. Either they place shots up front and then "submit" the attack, or they could make shots sequentially.

The last one is slightly more interesting. Instead of ending the turn after the player has fired at a monster they get the option to take another shot, and another, and another, as many as they want until their clip is empty or they decide to end the turn. The caveat being that each subsequent shot has less accuracy, and also switching target would reduce the accuracy further. So for example the first shot might have 90% chance to hit, but the second only has 70% and the third 55% and then the player decides to stop firing because the chance to hit isn't worth the ammo and they are better off waiting till next turn when they have 90,70,55 again. So the player is effectively firing at the oncoming monsters with burst fire each turn.

Then suddenly the player realizes the monsters are getting too close so decides to screw the ammo and fire off all the shots in the clip in one turn. So now they've effectively chosen to panic fire.

This allows the player to choose how to handle the risk. It also challenges the player's discipline, ie how well they can avoid taking "just one more shot" rather than waiting for next turn when the %s for those shots will be higher.

I figure I might have a separate aimed shot mode anyway to allow a single consistent 100% hit option for the player as insurance against the RNG and for rpg element of the character actually standing there carefully aiming a shot.

It's probably been done before (seems everything has) but just throwing this out there in case anyone wanted to use it or had some improvements or saw some flaws in the idea.

27

Programming / Re: map[x][y] or map[y][x]

« on: December 03, 2012, 12:17:56 AM »

I found arrays were too impersonal. I give all my tiles their own names.

Code: [Select]

Tile tilex1y1;
Tile tilex2y1;
Tile tilex7y3;
Tile amy;
Tile tilex14y30;
Tile true;
Tile false;
Tile tilex18y25;
Tile dontStandHere;
etc

Don't seem to be making much progress though for some reason

28

Programming / Re: Cooldown based timing system for complex RL timing.

« on: November 24, 2012, 04:34:31 PM »

yeah i should probably add a signature like "disclaimer: omnomnom's opinion not worth shit. read at own risk."

29

Programming / Re: Cooldown based timing system for complex RL timing.

« on: November 24, 2012, 03:52:55 PM »

Does anyone see any flaws?

Not in the mechanic, but in the effect on gameplay. What you suggest would work well as a world simulator, but as a game it makes things too complicated for the player in my opinion.

For example when deciding whether to attack an adjacent monster I want to know:
a) how much time until the monster takes their next turn (ie can attack me)
b) how much time will my attack take

If b < a then I can hit the monster and step away before they can hit me. If not the monster will hit me after I hit them. Makes a huge difference. With simple RL timing this is easy, nearly always b = a so I don't even really need to ask the question. Sometimes a and b are some simple ratio like 1:2, 2:1 to simulate fast/slow creatures relative to the player, but again it's fairly simple to think through.

But for a complex RL timing as you describe a and b are not only different for each monster/player combo, they in fact change each turn as different entities will be out of sync with each other. So either somehow you visualize the numbers for a) and b) to the player (UI nightmare) or you don't and the player has to divine the ratios themselves (for optimal strategy).

This includes the player having to think "how long do I have to wait for b<a so I can kite this monster?" and then performing dummy actions to make that so. Unless of course the game offers a variable wait command (I want to wait for 0.157s!) which is a WTF in itself. With different attack and movement actions of various variable speeds (player and monster) the complexity of calculations required to figure out the optimal action to make explodes.

All this calculation is fairly boring IMO and even if the player does ignore it, it will leave a defeated player thinking "hmm I lost because I didn't spend time on the calculations." and possibly "I can't win without spending time on calculations. I don't want to spend time on calculations. I'll stop playing this game."

Another problem I found with variable action timings is combat vs movement. Imagine a lumbering monster a very slow move speed of 2s but a fast attack speed of 0.2s. The player is twice as fast. So movement 1s and attack 0.1s. So the monster steps towards the player. Now the player has 20 attacks before the monster can attack them back??? The problem is the monster's actions are frontloaded, as you put it " 'act now, pay later'". They perform some long move and then can't react again until some cooldown, even if in reality they've been "interupted". Okay you could paper over this problem by counting an attack as an "interruption" and allowing the monster to make a reaction attack, but this is just papering over the real problem IMO, which is that the turn/tile thing of roguelikes is a discrete abstraction of time and space with time still relative to the player. Trying to get variable action times to work on top of that is like trying to fit a square peg into a round hole (which is only possible in r'lyeh). The only way variable actions work somewhat with turn based is the (old) xcom style of turn units. Just my opinion though, I could be wrong, but this is the impression I got after spending time making a turn system similar to what you describe only to find I didn't like how it played.

So now my opinion has gone back to the idea of simple RL timing being better. In fact I wonder why I ever wanted to have complex RL timing. It's like having over complex combat mechanics. Sometimes simpler is better.

30

Programming / Re: Map generation woes

« on: November 15, 2012, 07:38:45 PM »

That's a good idea to have a table of room type compatibility and then bias the room placement so that rooms with higher compatibility are placed nearer each other. I was thinking about something similar with room shapes to get different zones of architecture. Haven't been able to try it yet as all my rooms are pretty similar (gray walls and floors) although I might try compatibility for circle rooms vs square corner rooms.

I haven't really thought about room purpose much. I guess medical rooms would be more likely to have medical items and monsters, eg undead "surgeons" who want to cut you to pieces so they can put you back together again. Houses could typically have locked doors that need bashing down and can have small amounts of random loot (or sometimes an angry occupant) and armories are more obvious.

Another idea with choosing room purpose is to place guarded items at dead ends. Darren mentioned this example in his blog in point #8:

8. Hmm, there’s a dead-end room in the west.  Any chance of a special item for here? Sure, a special potion. In a trapped chest. Guarded by… mages. Path to the dungeon entrance from here is to the north, so I’ll position them in a defensive formation near the door there, with a healer behind them.

Dead ends can be made the most secure rooms as they only have only one way in. Also they can be optional so the player could decide not to bother risking it and just continue to the stairs. I guess guardian rooms can't just be any old room, eg a special item in a house doesn't feel like it makes much sense. It would probably have to be things like a tomb or vault. In which case that has to be decided first. Then your compatibility table applies afterwards. If the guardian room is a tomb you wouldn't have something like an armory next door (I don't think) you'd probably have a kind of buffer area of more compatible rooms like lesser tombs or storage rooms or temples nearby and only after that do the rooms start getting "normal" again.