Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Toady One]

This thread is going to be locked if it continues to be an argument.  People should try to be respectful in general.  If the OP doesn't want to discuss certain things, that should be how it goes, but not at the expense of having a thread with constant fighting.  If people remain in good spirits there shouldn't be a problem.

[Outcast Orange]

I am very pleased with what you've done so far.

You program the way I do.
Whatever is easiest is implemented, and when you want new functionality,
 you can go back and change things.

It works out pretty well, since even if you are wasting some time,
 you get a faster "prototype", giving you foresight more quickly,
 and the double benefit of doing things BOTH ways.

Right now I have terrible, barely adequate rectangular collision code.
I will have to make it more complex and resilient tomorrow.
Do I feel like I missed out?

Not really.

I would rather have a functional placeholder, than be debugging a more complex function,
 when I was not even sure that I would have liked the result.


It was probably quite a few posts back, so can you restate your next goal or addition?

[Normandy]

Blech, we're the bad people? Before I jump ship, at least look into greedy best-first searches. You should add a path class as it's a major refactor; i.e. Roguelike 8.

[Kalasen]

If you don't mind my asking, just what are you using for path-finding?

The system doesn't really have a name.  It's just something I came up with on my own.  I tried to explain it earlier but I'll go over it again.  In all honesty it's not even pathfinding in the traditional sense.  The AI doesn't build a path to it's destination like in A*. 

Every round the AI checks to see if it has a line of sight to it's target.  If it does, it records the target's location and moves a tile towards it.  If it does not have line of sight, it moves towards the last recorded location of the target.  Once it reaches the last known location it checks for line of sight to the target.  If it doesn't have line of sight it basically gives up and goes back to whatever it was doing before.  If it does have line of sight, it repeats the process.

From an economical standpoint it's amazing.  The only difficult calculation it uses is calculating the line of sight which is a drop in the bucket compared to proper pathfinding algorithms.  I'd describe it as efficient but very limited.  It will never get the AI through a maze unless it's following the player.  But it will make the AI reliably chase down the player until the player has either moved out of range or turned enough corners to keep out of sight.  But in the end it's only half a step up from no pathfinding at all.

Wow, thank you for posting that. It may not be the best path absolutely, and it may not get a creature where it needs to go for sure, but it definitely is incredibly fast, and easy to code. I completely understand what you mean about getting something out now as a prototype, then doing something more in depth when it's needed or it warrants more time and effort. I myself have been working on trying to implement an A* algorithm using binary search, but it's taken a while of coding and I'm still not done with it. I think I'll throw up some simple thing like that, and write a full A* algorithm later.

Don't let the others get you down, I know what it's like to start out, but I think you have the right process in mind: prototype, then refine, as opposed to trying to write masterpiece code every time and being stuck in debugging for weeks if it doesn't work.

[winner]

That sounds like effective monster behavior; it makes them move correctly whenever the player can see them. 
If you wish for bloodhound creatures you can borrow a trick from angband and have your player's field of view code update each tile you can see with a number that is the turn count minus the tile's distance from you. Monsters who are looking for you can simply move from lower numbered tiles to higher ones. 

[Outcast Orange]

Wow, thank you for posting that. It may not be the best path absolutely, and it may not get a creature where it needs to go for sure, but it definitely is incredibly fast, and easy to code. I completely understand what you mean about getting something out now as a prototype, then doing something more in depth when it's needed or it warrants more time and effort. I myself have been working on trying to implement an A* algorithm using binary search, but it's taken a while of coding and I'm still not done with it. I think I'll throw up some simple thing like that, and write a full A* algorithm later.

Don't let the others get you down, I know what it's like to start out, but I think you have the right process in mind: prototype, then refine, as opposed to trying to write masterpiece code every time and being stuck in debugging for weeks if it doesn't work.

Uh... are you sure you didn't intend to quote my post?

If he said basically the same thing as I did earlier, and I missed it, then my post would seem pretty dumb.
Sorry about that.

[Lemunde]

That sounds like effective monster behavior; it makes them move correctly whenever the player can see them. 
If you wish for bloodhound creatures you can borrow a trick from angband and have your player's field of view code update each tile you can see with a number that is the turn count minus the tile's distance from you. Monsters who are looking for you can simply move from lower numbered tiles to higher ones.

That sounds like an interesting trick.  I don't know if I'll need to use anything like that but I'll keep it in mind.

[Lemunde]

I updated the OP with some lore and finally decided on a name for the game; Dathida's Legacy.  As you'll read in the lore, Dathida is the god of chaos and disarray.  I thought it fitting that a god of chaos should be the creator of a world with so many random elements.  But don't worry, it won't be that chaotic.

On the programming side I set up a system for drawing text to get ready for adding items and commands.  I want to add a window that shows a list of commands that the player can choose from and apply using a combination of an action key plus the direction keys.  So if the player wants to attack a Creature to the east they just select an attack command then press the action key and numpad 6.  Ranged attacks will have to work differently but I'll cross that bridge when I come to it.

Here's the latest screenshot.  Mostly just graphical changes but you can also see the LoS and text at work. 

Spoiler (click to show/hide)

You won't see the text over characters like that the whole time.  You have to hold down a key to see it.  The numbers represent the Creature's current health.  Later I'll add text that shows the class so you'll see stuff like "Shaman" under "Goblin".

[Outcast Orange]

I like the mixed ASCII style, but it still seems very odd that the main character is a big letter H.
The grass and bushes are pretty detailed, so it seems comically insane.

I look forward to tromping through the world as a homicidal letter H,
 and slaughtering everything I come across.

Be sure to make the blood nice and everywhere if you choose to add it in.

[SolarShado]

I'll hazard a guess that the 'H' is a placeholder... I could be wrong, of course

I like the visual style too, are you making your own art?

[Supermikhail]

The walls in the screenshot look like a termite city. Are there giant termites yet?

[Lemunde]

Yeah, the H is definitely a placeholder.  I can make the character anything I want and I'll probably give the player that option as well.  And yes, I am making my own art which is part of the reason I'm using ASCII characters in the first place.  Map tile graphics and miscellaneous objects are actually pretty easy for me to make but when it comes to characters, well, it just takes a lot longer.  If I can come up with a character art style that is quick and easy to make I'll probably swap out the ASCII for artwork.

I'm using the same wall design concept that is used in Dwarf Fortress.  It lets the walls connect to each other smoothly but not as much as you see in other games.  This is to keep the number of tiles I need to draw low.  The brown color does make it look a little odd and I've been meaning to get around to changing it.  Those tiles are more for constructions than rock anyway so I'll probably be changing the graphics around.

I got a basic inventory screen up and running and it's listing the player's inventory correctly but before I continue any further with items I'm going to have to start work on the command menu.  There's three basic commands I want to get up and running for items: Use Item, Equip Item and Drop Item.  I'm toying with the idea of being able to equip any item in the weapon hand.  It might be amusing to bust a Health Potion over a goblin's head and watch his health increase.  Usable items would be destroyed during the process but if you wield a stack of items(Health Potion x 10) only one would be destroyed.

I still have a lot of stuff to sort out with inventory, commands and items so it might be a while before I decide if this concept is feasible.

[Lemunde]

I decided it would be a good idea to go ahead and make a blog page.  Despite the manner in which it was suggested, a blog will be a reliable way to backup the posts I make here and it's much more organized.  So if you want to browse through the lore or look at screenshots there's sections for those.  I still plan on maintaining this thread and most of my posts there will be directly copy/pasted from here.  You can visit the blog at http://dathida.blogspot.com/.  I'll update the OP with the link.

I took a break from commands and started changing some of the graphics around.  I spent a good deal of time last night experimenting with different ways to draw Creature graphics.  A full body, colored creature takes a lot of time to draw and can look awkward without animations.  ASCII might be good enough for some people but it doesn't really portray what a Creature is very well.  So I decided to shoot for something in the middle and I'm not sure how popular this idea is going to be.

Creatures are now represented in game as tokens.  They basically look like coins with a simple drawing of the Creature's head in the middle.  The Creature's image is overlaid on the token at runtime.  So for instance I can have a goblin head portrayed on a rough looking, white token to represent a goblin skeleton.  In my opinion it looks a lot better than ASCII but is a far cry from being realistic.  But at a glance the player should be thinking "Yep, that's a goblin alright".  Here's a screenshot of the token in action:

Spoiler (click to show/hide)

[Supermikhail]

Oh, yes!
These things are forever going to be pogs for me, and are going to be a symbol of pro roleplaying. However, green on a green background for goblins without a very distinct boundary is not so good. Also, even with very unique portraits it appears to me that it's not a big step ahead from the conventional ASCII, as it seems to rely mostly on colour and a few shapes. Maybe you could make the pogs more colourful, and have monsters have their distinct pattern instead of a single colour?

In hindsight, the colour of goblin pogs could reflect their natural protective colouration, and the difficulty in making out in a forest would be a sign of their stealthiness. However, then the PC's detection skills become kind of useless.

[Lemunde]

Yeah, the goblin tokens did look a little dark so I went ahead and brightened them up.  I thought about doing a different color outline for the tokens but it seems that won't be necessary.  As long as I keep objects such as creatures bright and map tiles relatively dark it shouldn't be an issue.  But I may still go back and make two color options for tokens, just for variety.