Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lemunde

Pages: 1 ... 37 38 [39] 40 41 ... 62
571
Sounds ambitious.  I can't wait to see what you come up with.


I figure you'll have to hard-code each combination so it won't be much invention as discovering what crafting recipes have been built into the world. Have a "dust of enchantment" as a common recipe component.

I don't think he'll necessarily need to hardcode every combination.  If you accept that each item is made of one or more base materials and each material can be used to craft an item you can have all sorts of combinations.  This way it wouldn't be too far fetched to create a piece of armor from a sword and an axe and have a couple of pieces of wood left over.

To simplify matters you could require the player to break down an item into it's individual materials before they can construct an item from it.

572
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.

573
Don't let the phrase "line of sight" confuse you.  The function I'm using accounts for any impassable tile, including tiles occupied by creatures and tiles changed during gameplay.  I can even make the LoS function exclude Creatures for certain situations.  For pathfinding I include Creatures.

I'm not sure what you mean by this, since it's my understanding that you have no "pathfinding" aside from the "line of sight".

Quote
Yes, it is far from perfect.  That much is clear.  But it is fast, easy to implement and it's good enough for now.

The problem with "good enough for now" is that there's an extremely good chance that at some point in the near future it won't be good enough, at which point you may indeed wind up kicking yourself for not implementing something more proper.

I'm not going to argue semantics.  I haven't invented a word yet to describe what they're doing so for now I'm calling it "pathfinding".  And for Creatures they do make adjustments to try to move around them so in a sense it is pathfinding.

This won't be the first game I've made that uses a system like this so I have a pretty good idea of it's limitations.  It will work for the goals I have planned.

574
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*.

If you're not actually having the AI find a path to its destination, then you're doing something very, very, very wrong; it should be clear why.

Quote
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.

The problem here is that you have to define "move towards". If there's a wall between the creature and the last known location of the target, where does the creature go? Towards the wall? What then? He'll never, ever reach the destination, because you aren't actually calculating an appropriate path; he has no idea which direction will actually lead him to the goal.

This won't even necessarily work for chasing the player around. What if the player is across an area that allows LoS but not passage (water, windows, etc.)? What if the monsters is forcibly placed into a situation where there's no straight-line path to either the player or the last known location of the player? What if the map changes in any way (passable tiles becoming impassable or vice-versa, transparent tiles becoming opaque or vice-versa)? What if something or someone gets, say, teleported? You're working on way too many assumptions here, and they're very, very easy and likely to be broken.

Please review the rules.

First of all, I already explained that the game doesn't need more complex pathfinding at this time.  This may change as the game develops and it's easily adjustable.

Don't let the phrase "line of sight" confuse you.  The function I'm using accounts for any impassable tile, including tiles occupied by creatures and tiles changed during gameplay.  I can even make the LoS function exclude Creatures for certain situations.  For pathfinding I include Creatures. 

The pathfinding relies heavily on the flow of the gameplay.  If the Creature starts off with a wall between it and the player, it will not have the player as a target.  If the Creature does not have a valid target it will continue searching every round until it finds one.  Once it has LoS to the player it will accept him as a valid target.  If the player moves behind an obstacle the Creature will move to the player's last known position then try to reacquire the player.

Yes, it is far from perfect.  That much is clear.  But it is fast, easy to implement and it's good enough for now.

575
The opening post has been updated with ground rules.  Please review them.

576
Let me reiterate so this is perfectly clear.  Any further criticizing of my techniques or design decisions will not be tolerated.  This has not and has never been the purpose of this thread.  I am open to any suggestions but I will not have my judgment insulted.  This ends now.  Violators will be reported.

577
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.

578
Yeah, keep an eye on the first post as I'll be updating it every now and then.

I spent most of the day fine tuning the line of sight functions in regards to forests and squashing minor bugs before they become a problem.  This also gave me the opportunity to add the forestry skill to Creatures as I needed some numbers to work with the forest line of sight.  Basically the forestry skill level roughly represents the number of tiles you can see before a tree starts blocking your vision.  I'll probably have to max this skill out somewhere between 6 and 8 as any further and you're seeing off screen, which gives an unfair advantage to enemies with a high forestry skill.  They don't have to worry about whether the player is on the screen or not.

I scattered 100 goblins all over the map and took a stroll.  It's interesting how even though they're randomly placed, to the player it seems like some of them are hiding in a forest waiting for you.  Currently the player has a higher forestry skill and a higher speed (for testing purposes) so when you first see a goblin hiding in a forest, they don't necessarily see you.  It depends on how close they are to the edge of the forest.  It's actually pretty fun getting some of them to chase me and trying to lose them by dodging around corners and into forests. 

Currently the pathfinding works by following the player (or some other Creature) and remembering the spot the player was at just before they lose line of sight and moving to the last known position.  Once they reach the last known position they check for line of sight again and the process repeats.  It's a cheap but somewhat effective form of pathfinding.  It's good enough to make a creature chase another around corners.  If I want to add something like schedules where a creature goes to and from a specific location I'll have to change it to a more complex pathfinding system such as A*.  Some other features may require complex pathfinding so we'll see.  Either way it's not a priority at this time.

I've also been gradually enhancing the graphics.  I changed the rocky ground tiles to grass and dug up an old function that applies slight variations to the color of the tiles so you get mostly green with patches of greenish brown here and there.  I did this for both the grass and the trees.  The function was originally meant to be used for particles but I've found a million other uses for it.  It's great for randomly generated objects!

579
Problem with that:

Figuring out exactly what you want from this game is going to make things so much easier. And the sooner you do it, the better. And you'll need to do less fiddling to figure out what works and what doesn't. Even just some big, overarching statements, such as "the player should be able to practice necromancy" would help.

I'm not intending to be overly critical, (your program, your problem)  just give it a thought.

I don't know if you've gone back and read the first post but I'm doing just that(almost word for word).  I have everything I want to do all planned out in my head but I need to get it down in writing so I'm gradually updating the first post with a detailed description of my goals.  Which reminds me, I need to add forestry to the skills list now that I got trees up and running.  Forestry will enhance the player's ability to see and move in forests.  You can see it in action in this screenshot!:

Spoiler (click to show/hide)

580
Argumentum ad Internet, haha. He's taking such a hostile stance because if you were his coworker, he would rightly boot you out the window. Disrespect is no proper response to hostility; show your deference at the very least.

I'm kind of curious, what's the backstory to your world? What's the setting? High fantasy? Tolkienesque? Low fantasy? You don't really point out too much about it. What is your overarching goal with the game? Toady has a clear goal with DF which is why he has gotten so far; he wishes to make a fantasy world simulator. However, reading the OP, I don't think your scoping is clear. There are tons of roguelikes out there, how are you going to model your game off of such a large and diverse group? I mean, is it going to be more hack-and-slash like Diablo or a Nethack clone or something else? I've fallen multiple times into the trap of depth before breadth, and I think you maybe concentrating a little too much on the details. It's hard to do a Let's Make on such shaky grounds. We can only suggest design issues (hint hint).

If you're looking for a backstory you won't find much of one.  There's no main quest or objective for the player other than what they choose.  I do plan on adding a rich lore to the game and I have a few elements in mind such as the necromancers discussed earlier.  With many elements being generated in different ways, you're not going to find the same kind of world with the same kinds of conflicts every time a world is generated.  I haven't decided how far I want to take this but that is the general idea.

I probably do need to flesh out the description in the first post a little so I'll get to that when I have the time.  Don't expect me to have a fully developed design plan like Toady has any time soon.  That probably isn't what you want to hear but I think it's important that I get a good base engine up and running before I decide what will work and what won't.

581
I quite admire your patience for criticism, Lemunde.
It is interesting that the OP gets praised for "handling criticism" when his method of "handling" it is to ignore it and to proclaim such incredible statements as "I understand everything about inheritance" (I've been programming for fifteen years and I don't make that claim!).

Mind you: the risk is not that the OP "does something wrong," although it seems unfortunately evident that he does not have a grasp on why you write this kind of code in a certain way (which comes with experience, and apparently "learning to listen to other programmers who have been to this dance before" does too--I can't fault him for being a novice programmer, though it's disappointing that he is refusing to turn on the analytical part of his brain). The risk at large, and the only reason I threw in a post to begin with, is because other people may see this thread and think that his direction is good. It is fundamentally flawed, and for a nontrivial project will expose these flaws.

His claim later that "oh, programmers all have their own idea of what's best" is not without merit, but a mature and seasoned programmer will realize that there are multiple effective ways to do something and evaluate them on their merits. As his method of "handling" criticism is to say "trust me, this works better," it seems unlikely that he is actually interested in a dialogue and more in bragging. (At which point, why not get a blog?) And as far as "oh everyone does it differently" is concerned: when it comes to game development, it should be noted that most people who build nontrivial projects trend toward very similar designs, because they are in fact the path of least resistance. I know that, for their engine, Meltdown and Karantza largely mimicked Unreal because it was the optimal, or near-optimal, way to do it. (And, yes, a roguelike is at its core not very different from Unreal.)

As always, comments and suggestions are welcome.
Well, if they're "welcome," I can note that I am still waiting for your justification on ignoring your type system to create your AI system, instead of leveraging the framework and programming paradigm you are using the way they are intended to be used. I asked specific, pertinent technical questions, and your response was "uhh...this way works best." Why does it work best? Dead silence.

If you want to grandstand in a public forum, you have something of an ethical obligation to follow best practices because you are positioning yourself as an example to other people. I'd like to actually learn something from this thread; if there's something better about the method you are employing I'd like to hear it.

I don't know why you've decided to take such a hostile stance but it's getting old.  I am not going to change the way I program to appease you and I don't feel obligated to explain why.  End of story.  I will not discuss this further.

582
I quite admire your patience for criticism, Lemunde.

Well I knew what I was getting myself into when I started this.  In all honesty I probably shouldn't have mentioned anything about code specific operations and stuck to discussing logic and game features, which was my intention in the first place.  Programmers can be...passionate about the proper way to do things.  And even in other areas everyone has their own idea about how things should be done.  As long as everyone understands that this is my game and I'm making it my way, I don't have a problem with criticism.  As always, comments and suggestions are welcome.

583
Ah yes, I forgot about Morrowind's system of fast travel.  For those who have never played Morrowind, you can fast travel but only to and from specific locations and it costs a small sum of money to do it.  Traveling to dungeons and remote locations would still require the player to travel by foot but they wouldn't have to travel so far.  It sounds like the ideal method for this type of game!

And yes, I do plan on making the world worth exploring.  I have a few ideas on this that I'll talk more about once they're fleshed out.

584
I did some more testing with several goblins attacking at once and it seems to be working alright.  I only have a basic pathfinding system implemented so they have trouble getting around each other in certain situations.  I'll go back and add some more complicated pathfinding later but it's working for what I need right now.  I also had to add a system that marks tiles as occupied so they don't all try to move to the same tile.  That took a bit of work but it's also working as it should.

Tomorrow morning I'm going to start work on adding some tree clumps to the map.  I also need to go back and change how the order in which everything is drawn is handled.  Currently I'm using XNA's built-in z ordering but that can get a little quirky and it's going to be hard to work with with what I have planned.  More on this later.

In the mean time here's something to chew on.  I'm debating on how I want to handle the world map.  You see I want the world to be massive, on par with what you see in DF.  The technical limitations don't so much concern me as I've made several different world generators before in other projects so I know what I'm getting myself into.  I'm more concerned on what is best for the gameplay. 

DF(and DF for that matter :P) uses a sort of fast travel system but I'm not sure that is best because I want the player to be exploring the world, not just jumping from one location to another.  But if I restrict the player to traveling long distances by foot I'm just setting them up for frustration.  Alternatives could be:

*Making the world smaller, bringing all the interesting locations much closer together
*Saturating the world with interesting locations, but the player still has to travel far to get to the places they want to go
*Use a fast travel system that somehow forces the player to stop and explore every once in a while (not a fan of this one)

It's still a ways off before I start working on this part so there's no rush.  I'm definitely open to suggestions for this one.

585
Creative Projects / Re: Pixel Longcat! IT HAS BEGUN!
« on: July 01, 2010, 05:49:07 pm »
Sorry, the colors look identical on my monitor.  Should be fixed now.

Pages: 1 ... 37 38 [39] 40 41 ... 62