Messages

46

Programming / Re: Lighting Issues

« on: September 26, 2012, 09:48:11 AM »

As for the walls, I had to make every wall adjacent to a "lit" floor space also be considered lit, and not actually cast light on the walls (which makes sense if you think about it: the wall is taking up the whole tile, and no light should be actually "entering" the tile, since it's all full of opaque wall).  Even without the lighting issues you are talking about, the player's field of view looked really ugly without doing it that way.  I ended up going back through the set of visible cells and adding all of the opaque cells adjacent to visible cells to the set of results, rather than trying to write it into the shadowcasting algorithm.

Interesting post...lots of things I hadn't thought of...I guess I am going to need to try lighting before being able to contribute anything to this discussion or I'll just end up spouting nonsense....*enters lurk mode*

47

Programming / Re: Lighting Issues

« on: September 26, 2012, 09:37:47 AM »

Maybe I misunderstand, but that doesn't sound like the idea I was suggesting.

I probably misread it then.

sorry wasn't having a go, your solution seems the best I just can't use it. I was secretly hoping penguin_buddha would try my idea so he could find any problems with it ahead of me i haven't even tried adding lighting yet...I am still stuck on map generator...3 months now. i am slow 

48

Programming / Re: Lighting Issues

« on: September 25, 2012, 11:20:55 PM »

Maybe I misunderstand, but that doesn't sound like the idea I was suggesting.

I am saying don't do another check from the player. I am saying if either of the floor tiles bordering the 2 sides of the wall tile facing the player are both lit and visible to the player then light up the wall tile. Caveat is that I don't know for sure if this works.

I think you are instead suggesting to check which wall-sides are visible from both the player and light and when both the player and light can see a wall-side, that wall tile is lit. Your suggestion, unlike mine, seems 100% accurate and reliable to me, but the problem is my FOV algorithm (and I suspect penguin_buddha's too as we are both using shadowcasting) only returns which tiles are visible, it doesn't return which sides of tiles are visible.

So to avoid altering the FOV algorithm to provide tile-side visibility (I don't even know how), I was trying to solve the problem without knowing which tile-sides are visible.

49

Programming / Re: Lighting Issues

« on: September 25, 2012, 04:10:17 PM »

What about only drawing a wall tile as lit if the player can see at least one lit floor tile adjacent to that wall tile?

50

Programming / Re: Dumb AI as a feature

« on: September 15, 2012, 06:49:21 PM »

ah man theres nothing worse than the first level of brogue and a monkey steals your darts

51

Programming / Re: How about sound effects? Distracting? Fun?

« on: September 12, 2012, 11:17:11 PM »

Mind sharing where you got those from? They are quite good.

I made many of the sounds. For example, for a knocking sound, I banged my hand against my desk, recorded it, and added some muffling in audacity (a free sound editing software).

Some of the sounds I just couldn't physically make, so I got them off of soundbible.com. Many of the sounds there are creative commons.

Nice to know microphone plus audacity works. Did you record any death screams for monsters? I want to but I fear the neighbours might call the police.

52

Programming / Re: Pathfinder + Fog of War

« on: September 12, 2012, 11:09:43 PM »

I haven't done/tested this yet so this is just my plan, but hopefully it will help to share the idea.

You can't calculate a path directly to the target tile with the information the player has, but you can calculate a path to a known passable nearby tile. As you get closer to that tile and reveal more map you will hopefully be able to calculate a new path to an even closer tile and finally the target tile itself will come into view and you'll be able to calculate a path to it directly.

The trick is deciding which tile nearer the target to use as a temporary target each turn. It isn't as simple as the nearest tile. The distance from the player matters too.

I think it involves minimizing this:
Cost of moving to temporary target tile + Estimated cost of moving from temporary target tile to actual target tile.

Unfortunately the second term is hard to estimate, not just because it involves picking some heuristic for the cost of crossing unseen tiles, but also because there can be patches of known tiles on the route requiring breaking out into proper path finding. The whole thing scared me off.

What I do instead is use the autoexplore method mentioned here:
http://roguebasin.roguelikedevelopment.org/index.php/The_Incredible_Power_of_Dijkstra_Maps
See section 2) Autoexplore

Use the target tile as the only goal and radiate out the echo/Dijkstra Map from there, treating each unseen tile as passable. Then from the player tile take the route towards the source. When new map info is revealed recalculate the map. Effectively this does the "hard" cost estimation mentioned above for free.

The downside is that it calculates a path to the target from lots of tiles on the map when we really only want the path from the player, so it's a little inefficient. Still it should make reasonably good intuitive guesses about where the closest path will be and if it finds it's a dead end it'll try another route.

I plan to add some constraints anyway like if the target is too far into unseen territory then don't allow it to be selected as a goal.

53

Programming / Re: Defunct projects (C++)

« on: September 12, 2012, 09:24:49 PM »

I spent 5 years maintaining some C/C++ application. 7 hours a day (well...not quite...). And still I didn't understand it. I could tweak parts (sometimes after some effort) but never did I tame the leviathan.

54

Programming / Re: How taboo is the "borrowing" of public domain tiles?

« on: September 11, 2012, 03:29:13 PM »

Just get it working with public domain and change it later to custom tiles in an update if you want to.

55

Programming / Re: Good Settings for Free-Roam RogueLikes

« on: August 13, 2012, 04:35:41 PM »

"I really like post-apocalyptic settings, but I don't want to turn it into an allegory of how we need to downsize our nuclear weapons departments, or stop global warming, or protect the koala bear because without it this certain tree will grow too large and take over our cities, etc."

Then don't.

56

Programming / Re: Multiplayer in Roguelikes

« on: July 29, 2012, 08:50:15 AM »

I was thinking about this before. I wondered if it would be worth allowing players to see other player's screens during the other player's turn. That way if one player's turns are taking ages because they are having tough decisions then other players can at least spectate it. That might reduce some of the waiting for other players problem.

57

Programming / Re: Experience Points

« on: July 13, 2012, 04:41:23 PM »

I didn't read this thread there were too many words on it but I did look at the pictures. This one caught my eye:

What on earth is going on there? The guy on the right is holding the sword the wrong way round lol.

I bet the one on the left is saying "you fool Thomas, you are holding your sword the wrong way round! And to think when you came out in all that gear I thought you knew what you were doing! Look how easy it is for me to stab you Thomas and I am not even really trying"

58

Programming / Re: Procedurally generating one or more families/a small population?

« on: July 03, 2012, 11:02:56 PM »

I would split this into four parts/stages of work: Simulating, recording and querying, optimizing.

Simulation
Maintain a list of people in the town you are tracking. This is just a list. For each person (entry in the list) only store very basic info. I would just store their full name, gender and age and nothing else. Run the simulation forward a year at a time. Each year, for each person in the list, calculate whether they hook up with someone, have kids, or die or whatever. If they die, remove them from the list. If they marry someone outside the pool, or have kids then add the new spouse or kids to the list. Continue the simulation for however many years. There's no memory in this simulation, nothing is remembered about past years or generations, but that's intentional for demarcation and to keep it simple.

Recording
As the simulation progresses, each time a recordable event happens (marriage, death, birth, etc), create a record for it with relevant info (eg for a birth record who the parents were, for a marriage record who married) and add the record to a list. This list is much like a book being maintained in the village hall of all new births, deaths, marriages, etc. This is the memory part, whereas the simulation is the current state part.

Querying
Now say you want to know if two particular people, by name, are related. All the information to answer this is in the history list. I would write a function like bool AreRelated(name1, name2) which goes through the history list to answer the question. You can run such queries as the simulation progresses (eg find out if two people are related to determine if they can marry, ie to prevent incest).

Optimizing
You might think I am crazy above as I am saying run queries against a list when that would be very inefficient. A tree is obviously much more efficient. You could generate a tree for querying from the history list, but I wouldn't bother unless/until I found a performance problem. For one thing you rapidly get the game working this way and you find out where the performance bottlenecks are and they might be easily overcome without a complex data structure. eg perhaps the only performance problem will be working out a common ancestor of two people, in which case you only need a tree for querying that holds descendant/ancestor info and not marriage.

Just designing a catch-all tree that can be used for any possible query seems like it could take more time than all of the above combined. Then you have to spend a lot of time implementing the super tree. Then think of all the hours that are inevitably lost on bug hunting when something weird happens with some pointer...

And just think, you might find that from the player point of view the extra delay from querying a list rather than a super treelike structure is completely unnoticeable, in which case wouldn't you kick yourself for spending ages writing the super tree? Then again I am quite lazy. I gave it some thought but I have no idea how to design a tree structure that can hold marriage relationships and descendant/ancestor relationships, the problem made my head hurt so I avoided it.

59

Programming / Re: Roguelike timing systems.

« on: June 27, 2012, 11:42:46 PM »

I implemented variable length actions and tried it out but I am disappointed about the results and am thinking of implementing a much simpler system. It's good simulation wise but it gets unintuitive and very complicated from a gameplay perspective. Take this example:

player time to move one tile = 1
player time to melee attack neighbouring tile = 0.5
bird time to move one tile = 0.4

What the player sees if they move about is that the bird alternates between moving 2 and 3 tiles at a time: 2,3,2,3,2,3

Now if the player switches to melee attacking something (not the bird) the bird will appear to slow down: 1,1,1,2,1,1,1,2

This highlights two problems (in my opinion). First the bird slowing down is unintuitive. Why would a bird appear to slow when the player attacks and speed up when they move? This expects the player to understand the whole relative time thingy.

Second that 1,1,1,2 staggering...the player can't predict movement in this system because look there are three 1s in a row and you might think the next movement of the bird will be one tile...but no it suddenly seems to jump 2. Okay that's a common problem and a minor one, but it does limit predictability.

The biggest problem I see is that the player is expected to make critical survival decisions based on time, yet variable length actions obfuscates how time works in the game and forces them to run complicated calculations upon detailed statistics. For example imagine the player is being chased by a tiger and needs to work out if they have time to throw a javelin at the tiger and still be able to flee to a door 10 tiles away in time how do they do that? The tiger moves 121% as fast as the player. Throwing a javelin takes 78% as long as moving a tile. They are going to need a calculator. They could just guess, and that's how I would play, but I would do so knowing that my method of play was "lazy" and I was playing with a sub-optimal strategy. After losing a few times I might just decide I will never win unless I bother running all the calculations...

Another problem I found was kiting:

player time to move one tile = 1
player time to melee attack neighbouring tile = 0.8
orc time to move one tile = 1
orc time to melee attack neighbouring tile = 1

So now if the player times this right they can can wait for the orc to walk up to them, melee attack and the orc doesn't get a chance to react before the player gets to move again. The player then steps backwards and avoids the orcs attack. But this kiting only works if you time it right, which means the player has to calculate it. But this is fine because it's a simulation - except if it's a proper simulation the player should be able to choose how long they wait. Ie a variable "wait" action. Press that '.' key and get a little input field asking how many "turn units" you want to wait. 0.2 please. And now this game is just getting too complicated.

All these things can be worked around somewhat. But I am beginning to lean towards uber simplicity of just having all actions of all creatures take the same amount of time, or multiples of 2. At least that is predictable and perhaps that's what matters most of all? It's not like variable action lengths are easy to implement either. Knowing what I do now I wouldn't have bothered.

Same story with field of vision...I spent too long reading about permissive field of view and that digital one, and turns out the far more basic method is "better".

60

Programming / Re: Roguelike timing systems.

« on: June 26, 2012, 02:14:34 PM »

The benefit of a queue is you can jump efficiently to the actor whose turn is next, you don't have to scan through all the actors and find the one with the lowest cooldown. But I suspect the performance difference is irrelevant on modern computers unless you plan on having thousands of actors.

I went with a queue and I regret it now because it took so long to implement and it just makes things more complicated.  If I was starting again I would go with the array approach and only switch to a queue IF the array approach wasn't performing. I am betting the array approach will be fast enough. I suspect the processing of the actors actions takes a lot more processing time than working out who acts next anyway.