Insane
Level: Master Delver

Rank Points: 154
Registered: 08-06-2005
IP: Logged

I think I have an even more elegant idea.
This one relies on the fact that every entity knows it's own movement order (a simple number reflecting which turn it will move), and is publicly accessible at any time.

This method does not need any additional lists whatsoever and is perfectly consistent with the first system.
If an entity bumps into another entity, it first check whether that entity's movement occurs after it's own, and if thus, call it's Step() code, relying on the fact that it hasn't been called already, since it normally moves after itself.

Later, the entity's Step() code will be called again, but this time it terminates due to having already moved this turn.

Yes...yes I'll go implement that now.

-Insane

Insane
Level: Master Delver

Rank Points: 154
Registered: 08-06-2005
IP: Logged

File: experiment5.png (13.4 KB)
Downloaded 419 times.
License: Public Domain

Update: Yes, it turned out working PERFECT.
On additional news, I made characters turn to face when moving (or trying to).



-Insane

EDIT: I lied. Infinite recursion once no more moves possible.

---

[Last edited by Insane at 11-12-2007 05:00 PM]

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Mmh.. I liked mine better


Anyway, sorting all monsters left-to-right, top-to-bottom before going through whatever algorithm you use would make everything independent of placement order, at least, but it could have some weird results. For example:

  R R
        ->    RR
   |          |
   @          @

No problems there, but ..

     R
  R R          R
        ->   RR
   |          |
   @          @

The green roach tries to move first and taps the blue roach on the shoulder, making it move before the red roach.

 R   R
  R R        R R
        ->    RR
   |          |
   @          @

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

That's why I used a queue - it maintains the ordering, pushing back a monster just to where it needs to be.

Also, Insane, you can just use a single static variable to guard against infinite recursion. Call it currentlyStepping or something.

Maurog
Level: Smitemaster

Rank Points: 1501
Registered: 09-16-2004
IP: Logged

Another idea - roaches closest to Beethro move first. Will that make it more consistent?

____________________________
Slay the living! Raise the dead!
Paint the sky in crimson red!

Insane
Level: Master Delver

Rank Points: 154
Registered: 08-06-2005
IP: Logged

Isn't yours and mine essentially the same? (EDIT: talking to trick here)
Except yours uses an int, global move count compared to last_turn-moved, while mine uses a bool that gets reset after every move.

Also, I've fixed mine now, by keeping track of HasMoved for individual tiles, not just entities. (It was looping out when it hit a wall, since the wall technically had no entity. Wals are room objects and not entities, but still return a false for the bumpcheck, thus making the TryMove() script think that an entity there is blocking it's path, but fail in performing it's step since there is none, thus not setting the nonexistant entity's HasMoved() value to true.)

In related news, I've added customizable post-process shaders. (Well, there's my feature request)
I already have a Dx9, GPU-accelerated surface, so why not?

Currently I only have:
-None
-Grayscale (For memories? I might make a better version of this that's fuzzy on the edges, and slightly colorized too.)

-Insane

EDIT: As opposed to both Maurog and trick's ideas, I still have DROD's placement movement order as global-scale order decision. I'm keeping this because I feel it's more consistent.

Now will we stop arguing about who's idea is better and discuss something else?
Here's an idea: Can somebody explain to me how roach AI works?
I know already (I think) that DROD assigns a priority to every square on all 8 sides, and then the square with the best priority is chosen.
But from the way roach AI works, I gather that parallel to this, some primary rules are still followed, for instance:
An unbrained roach will never move away from it's target (player/decoy/stalwart/whatever).
A roach, I believe, still has preferences (orthogonally over diagonally, north over south or something).

Comments?
-Insane

---

[Last edited by Insane at 11-12-2007 05:44 PM]

Dex Stewart
Level: Smiter
Rank Points: 355
Registered: 01-19-2007
IP: Logged

The only preference it has is to move vertically when it wants to move diagonally, it can't, but it can move orthogonally in both directions.
And otherwise it simply moves like a bee towards it's target, unless, again, there's an obstacle in the way.
Really, you've got the complete roach AI there .

---

[Last edited by Dex Stewart at 11-13-2007 06:55 AM]

Pekka
Level: Smiter
Rank Points: 302
Registered: 09-19-2007
IP: Logged

Here's an idea: Can somebody explain to me how roach AI works?

There's a whole thread on monster movement. The fourth message by bibelot goes into details.

http://forum.caravelgames.com/viewtopic.php?TopicID=2587

Of course, you can also read the source code itself.

schep
Level: Smitemaster

Rank Points: 865
Registered: 03-01-2005
IP: Logged

The thing about scoring each of the nine moves is what goblins do. (Unbrained) roaches just try to move in the direction of the player. If that direction is diagonal and the first choice is blocked, it will try the adjacent vertical direction and then the adjacent horizontal direction.

---

[Last edited by schep at 11-13-2007 01:57 PM]

Insane
Level: Master Delver

Rank Points: 154
Registered: 08-06-2005
IP: Logged

File: experiment6.png (145.9 KB)
Downloaded 276 times.
License: Public Domain

Ok, next update.
First of all, I (for now) modified the whole interface to look like AE. Second of all, I added a basic particle class (which I will definitely be re-making sometime :/), but for now the only randomness was the burst direction, which for now wasn't affected by sword allocation at all.

Furthermore, I made Roaches behave like real roaches now.
(That link was Excellent!)

Here's another image to impress y'all. (And no, It's not a stolen image from AE. I can send you the .exe if you doubt. Plus, the particles are symmetric and non-physically affected.)


-Insane

---

[Last edited by Insane at 11-13-2007 03:56 PM]

golfrman
Level: Master Delver

Rank Points: 165
Registered: 07-10-2006
IP: Logged

so far the the pictures your showing it seems like you've recreated DROD:AE. (although i do know that's not what you're aiming for, but still quite impressive.

____________________________
Jesus is Lord and Messiah!

Insane
Level: Master Delver

Rank Points: 154
Registered: 08-06-2005
IP: Logged

File: DROD.zip (637.2 KB)
Downloaded 46 times.
License: Creative Commons
Noncommercial 3.0 Unported

True, but I'm really aiming for AE right now, at least until somebody gives me an idea for something else.
I'm still staying as flexible as possible, although right now the interface and game-are and room size are hardcoded, I can change them easily without breaking anything. (Although I suppose I have to make the window+border larger. )

But what I can change at any time is tile size. (From 14 to 22, say)

Back to the matter at hand (for me), I need help from somebody that's more experienced in C# than me.
What I'm (still) trying to do is the R and Backspace keys.
All of this is being handled in the RoomState class, which provides a few arrays, lists and variables that get copied from the actual room when saving, and get overwritten when loading.

But somehow this isn't working just as expected. (And monsters, which should be copied in both the roomTiles array and the movementList list, aren't updating at all. Only the player is being duplicated (!), although since the sword is shared, there's only one sword in the room)

I'm uploading the source here, although you need both Visual C# Studio 2005 Express Edition (Only Express) and Microsoft XNA Framework 1.0 Refresh for it to work. (Not to mention DirectX 9, so it's Windows-only anyways) Also needed is the .NET Framework 2.0 or greater.
If anybody doesn't have either of these, links are provided at this topic.

-Insane

EDIT: Re-uploading new version.
Changes:
The current room's tiles are destroyed before re-loading, that way the old roaches actually disappear.
What's still not working is that the stored roaches re-load.
Also, I've made a message pop up when you die.
Furthermore, I've included the built version (DROD\bin\x86\Release) for those that don't have visual studio.
However, you do still need the XNA Framework and .NET Framework for it to run.

---

[Last edited by Insane at 11-17-2007 10:26 PM]

Kwakstur
Level: Smiter

Rank Points: 385
Registered: 05-05-2006
IP: Logged

Aww, stupid XNA. I myself downloaded XNA Game Studio 1.0 Refresh. You know what I got? A help Index overcrowded to the point of being useless, and the unfortunate knowledge that my graphics card does not support the latest Direct3D. I can make an empty XNA game, strip every code page of every Using statement I can safetly remove without a failed build, and it will still complain about Direct3D when I debug it.
But I digress. And I do so quite often. Actually, it makes sense given how, in real life, every other thing I say is a complaint.

Anyways, props to you, Insane. This program seems to be coming along nicely. And surprisingly quickly. Either that or it just seems quick because I've only been visiting once a week.

____________________________
Also known as ExpHP everywhere else.

---

[Last edited by Kwakstur at 11-18-2007 11:31 PM]