Insane
Level: Master Delver

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

Hey!

Recently I've been feeling more and more like making my own DROD-style engine/game in C#, the only problem is that I can't for love of my life make any images/holds/ideas for it.
I'd love to make the engine, and I have some really good efficiency/management ideas, so I'd love if anybody wants to support me.

Otherwise I should maybe just drop the project.
What do you guys say?

-Insane

calamarain
Level: Smitemaster

Rank Points: 933
Registered: 03-25-2007
IP: Logged

Insane wrote:
Hey!

Recently I've been feeling more and more like making my own DROD-style engine/game in C#, the only problem is that I can't for love of my life make any images/holds/ideas for it.
I'd love to make the engine, and I have some really good efficiency/management ideas, so I'd love if anybody wants to support me.

Otherwise I should maybe just drop the project.
What do you guys say?

-Insane

Depends how much free time you have on your hands.

Try to keep things as general as possible. That makes it a lot easier to add new creatures/stuff in whenever you can. The scripting in TCB is a good example of that.

Also... what about Hexadrod? A DROD-like game on hexagonal squares. That would be very cool, and once the engine was done, I'm sure there would be plenty of volunteers from the forum to make levels for you.

____________________________
My Holds

Insane
Level: Master Delver

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

I'm actually working on a larger scale project, but I should have a lot of free time in the next few weeks since my current part is finished, it's time for my fellow developers to work now.

So yeah, I like the hexadrod idea.
I've already started a little work (making some general Tile, Object and Room classes), and interaction like Actors bumps (for non-eating characters), Actor attacks (sword stabbing/moving onto) etc.

The only thing that makes me wonder with such a system is the practical implementation of the room coordinates.
I was until now using X/Y, but I'm unsure how to get these coordinates into a hexagonal square.
Also troubling is how to do the black/white checkerboard pattern (I actually already implemented that for the Tile class)

I'm gonna go play Settlers right now though, so if you could help me figure that out, it'd be a blast!

-Insane

Syntax
Level: Smitemaster
Rank Points: 1218
Registered: 05-12-2005
IP: Logged

Insane wrote:
Recently I've been feeling more and more like making my own DROD-style engine/game in C#

I would gladly help out with a Java port but not yet played with C# unfortunately...

Insane
Level: Master Delver

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

That's fine, I don't really need coding help.
I just need art/idea/system support, so basically anybody can help.
Pathfinding will be a bit tricky, although it happens I have made an A* implementation in C# already.
Problem is, I also made it for a sqaure grid, not hexadecimal.

So I think I'll just screw the hexa thing and do a normal square grid too.
Or maybe an octogonal grid, since that's basically the same with a different layout (8 movement directions)

So basically I can do the engine using just X/Y for now.

-Insane

calamarain
Level: Smitemaster

Rank Points: 933
Registered: 03-25-2007
IP: Logged

File: hexcoord.PNG (7.9 KB)
Downloaded 87 times.
License: Public Domain

Insane wrote:
I'm actually working on a larger scale project, but I should have a lot of free time in the next few weeks since my current part is finished, it's time for my fellow developers to work now.

So yeah, I like the hexadrod idea.
I've already started a little work (making some general Tile, Object and Room classes), and interaction like Actors bumps (for non-eating characters), Actor attacks (sword stabbing/moving onto) etc.

The only thing that makes me wonder with such a system is the practical implementation of the room coordinates.
I was until now using X/Y, but I'm unsure how to get these coordinates into a hexagonal square.
Also troubling is how to do the black/white checkerboard pattern (I actually already implemented that for the Tile class)

I'm gonna go play Settlers right now though, so if you could help me figure that out, it'd be a blast!

-Insane

There is a coordinate system for hex. It's a little confusing for a player to look at, but works perfectly well for a computer

One sec while I do a diagram... Taking the space with the axes starting from it to be (0,0), the green one would be (0,3) and the blue one would be (-2, 4)

I would advise either setting the central hex to be 0,0, or have an appropriate shaped grin - just because it's hexagonal doesn't mean that the rooms have to be hexagonal - they can be a nice parallelogram that makes coordinate systems easier.

Just as a point of pedantry, for any repeating tiled system made of infinite numbers of the same tiles, there are an infinite number of possible coordinate systems. x and y axes don't necessarily have to be orthogonal

____________________________
My Holds

---

[Last edited by calamarain at 11-10-2007 09:06 PM]

calamarain
Level: Smitemaster

Rank Points: 933
Registered: 03-25-2007
IP: Logged

File: hextile.PNG (5.1 KB)
Downloaded 90 times.
License: Public Domain

Also, for the checkerboard - it can't be 2 colours. Here's a nice simple pattern that works with 3.

____________________________
My Holds

Insane
Level: Master Delver

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

Dealing with parallelograms is still quite complicated, though.
For now, I'll make it squares (visually), and I'll try to shift to a parallelogram as soon as possible, since I still have to make a nice, consistent method of figuring out parallelogram limits. (It's a very odd/different edge point list, instead of just (0,0) to (n,n), so normal greater than/less than checks do not work.)

I'd still have to figure out grid size for this.
Also, I'll have to work out the controls, too.
I was thinking numpad (default) like DROD up to now, but that's eight keys, not six.
If you show me a really elegant way of managing all of this, I'll make it DHOD (Deadly Hexagons of Death), if not, it's DOOD (now that's a weird name).

-Insane

calamarain
Level: Smitemaster

Rank Points: 933
Registered: 03-25-2007
IP: Logged

Shifting to parallelograms won't work trivially - each "place" goes down to 6 connections not 8. I'm not talking about parallelogram tiles - I am talking about rooms that are parallelogram shaped, but where the tiles are all hexes.

____________________________
My Holds

---

[Last edited by calamarain at 11-10-2007 09:18 PM]

Insane
Level: Master Delver

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

Ah yes, of course, you're right.
Well this renders everything I have anyways quite useless, since it would be more trouble than it's worth it to switch my pathfinding algorithm from 8 connections to 6.

-Insane

Insane
Level: Master Delver

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

File: experiment.png (15.3 KB)
Downloaded 624 times.
License: Public Domain

Ok, I've done some more basic work now, and made a first wrap-up of a testing room.

Right now I've made one architecture-layer tile (A wall) and one monster-layer tile (a test object that just walks aimlessly to the left until it hits something).



The only problem so far is movement order.
Right now, movement order is from topleft to topright (since it just loops through the array and executes a step for every monster-layer object), so I figured I'll need a way of tracking movement order.

I can't simply use time of creation, since, when moving, entities copy themselves of the target square (including all variables) and then proceed to destroy (not kill) themselves.
This is because every tile can have only one item on each layer (currently only architecture and entity, planning of object (orbs etc.)).

I've been thinking of using a simple array to track the instances, but when removing one it would leave gaping holes.
Can anybody help me here?

-Insane

---

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

Maurog
Level: Smitemaster

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

Why not a list? It's the natural solution for a list of instances. Do you need random access for anything right now?

____________________________
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

Maurog wrote:
Why not a list? It's the natural solution for a list of instances. Do you need random access for anything right now?

The problem is I can't modify the list while it's being accessed (in my foreach loop), thus making it impossible to change the associated tile for a single instance during the actual move.

Any practical way of modifying the instance without deleting/inserting it?

-Insane

EDIT: I solved the problem by creating another class which contained a dummy reference to the LivingObject, thus making it not change the actual entity list.

With this system, I solved two problems in the same step. 1) Keeping track of actual entities (not virtual entities)
2) I now have perfectly replicated DROD's movement order. Quick tests confirm.

---

[Last edited by Insane at 11-11-2007 08:07 AM]

Insane
Level: Master Delver

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

File: experiment2.png (16 KB)
Downloaded 575 times.
License: Public Domain

Ok, another update.
This time I've added a small debugger so I can watch precisely what's happening.
This is a screenshot in which the movement order is shown.



The current frame is after one single move, and the original line-up was:

 #
 #  OOO
 #

Next up I'm implementing the actual player role, and after that a simple roach.

-Insane

EDIT: I need help here: Can anybody give me the calculation for calculating the direction (in degrees) from point (X1,Y1) to point (X2,Y2)?
I can't seem to find it on wikipedia, which means I'm looking wrong.
EDIT #2: Never mind, I found it.

---

[Last edited by Insane at 11-11-2007 09:27 AM]

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Insane wrote:
The problem is I can't modify the list while it's being accessed (in my foreach loop), thus making it impossible to change the associated tile for a single instance during the actual move.

Eh? You can't modify the list itself, true, but you can easily change it's elements itself.

I do hope you're not using a list element for each tile of the playfield, but a list element for each character/monster that's on it, together with x and y coordinates for it, right? That takes care of the movement order problem in one fell swoop...

As for not being able to change the list - simply use a second list that you add all objects to after you processed them. If a monster gets killed, simply don't add it, if more monsters are spawned, simply add them at the end. Of course, you'll probably also need to keep some other data structure (like an array) around and updated that stores for each tile which object it is occupied by, because traversing the whole list for collision checks is prohibitively expensive...

And when your foreach loop is done, you can just throw away your original list and replace it with the new one...

np: Yoko Kanno - Replica (ft. Ilaria Graziano) (Ghost In The Shell Stand Alone Complex Solid State Society OST)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

---

[Last edited by Briareos at 11-11-2007 10:24 AM]

Insane
Level: Master Delver

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

This is exactly what I've been doing.
EDIT: Actually no, I'm not using a second list. I'm using an elegant togetherplay of list and array.

I'm keeping an array for every single tile, and a list of special moving entities (things that get affected by movement order), which reference the tiles that their on.
That way you can just look-up, say, the second monster to move at all on the the list, then follow it's reference to the tile it's standing on, and then manipulate the actual object in any way you wish. (Say move it, perform it's logic/step, re-draw it, kill it etc.)

-Insane

---

[Last edited by Insane at 11-11-2007 10:53 AM]

Insane
Level: Master Delver

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

File: experiment3.png (15.6 KB)
Downloaded 548 times.
License: Public Domain

Ok, I finished all player management, and I made a first real enemy: Basically roaches with rock golem logic (since their logic is the easiest to make).



Basically that's a wrap for now.
If anybody wants it, I can put the code up for grabs, and people can add logic for other monsters (roaches).

-Insane

---

[Last edited by Insane at 11-11-2007 11:53 AM]

Insane
Level: Master Delver

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

File: experiment4.png (13.9 KB)
Downloaded 535 times.
License: Public Domain

Sorry for the triple post but MAJOR UPDATE!
1) Finished all player keys, including the repeating when holding them down.
2) Added a stylesheet instead of individual images.
3) Added some AE graphics.
4) Tried to add restarting/undo but failing miserably so far. Damn my RoomState class!

Notes: The style used is Chaco's 25th Level style. I took it since I didn't want to download AE first, and it was the best style I found on the official AE style mods list.
All I used were the four wall images (only two visible in screenshot).



-Insane

---

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

calamarain
Level: Smitemaster

Rank Points: 933
Registered: 03-25-2007
IP: Logged

Insane wrote:
Sorry for the triple post but MAJOR UPDATE!
1) Finished all player keys, including the repeating when holding them down.
2) Added a stylesheet instead of individual images.
3) Added some AE graphics.
4) Tried to add restarting/undo but failing miserably so far. Damn my RoomState class!

Notes: The style used is Chaco's 25th Level style. I took it since I didn't want to download AE first, and it was the best style I found on the official AE style mods list.
All I used were the four wall images (only two visible in screenshot).

Click here to view the secret text

×

-Insane

Looking very cool If you develop it further, you'd probably have to make some new graphics (I know the AE ones are public domain, but you want yours to be distinct )

*impressed*

____________________________
My Holds

Chaco
Level: Smitemaster
Rank Points: 3624
Registered: 10-06-2005
IP: Logged

Insane wrote:
Notes: The style used is Chaco's 26th Level style. I took it since I didn't want to download AE first, and it was the best style I found on the official AE style mods list.
All I used were the four wall images (only two visible in screenshot).

I, Chaco, hereby give Insane complete permission to use, reproduce, and distribute all of the 26th Level graphics in this or any of his programs.

____________________________
Quick links to my stuff (in case you forgot where it was):

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

Since you're making a new engine anyway, have you considered getting rid of (or at least minimizing) the movement order issues that DROD has? Since your game is completely new it can change things like that without having to worry about compatibility. I'm not sure if absolutely all movement order issues can be gotten rid of completely, but at least avoiding holes in movement shouldn't be too hard.

O- RRRR | RRRR -O
   ↓    |    ↓
O-RRRR  |  RRRR-O

One simple way could for example be: Pick a monster, A, that hasn't tried to move yet this turn. If monster A is blocked by another monster B that also hasn't moved yet this turn and is not waiting, mark monster A as waiting and then try to move monster B (similar to what A just did), and then go back to move A when done (ie recursion). Otherwise, try alternate moves for A or give up. Repeat this until all monsters in the room either has moved or given up. You could further minimize movement order effects by giving different monster types different priorities, so that roaches always moves before roach queens, for example.

Movement order would still be playing a role and probably have some quirks of its own that I haven't thought of, but it'd be a smaller, different role

Maurog
Level: Smitemaster

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

    R |        |
   R  |     R  |
O-    |  O-R   |

    R |        |
   R  |      R |
O-    |  O-R   |

Move order - blue before red. How do you avoid this?

____________________________
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

Indeed, that's interesting, and also quite feasible.
The way I'd do it is to make a "waiting to move" list, and fill it up with every entity at the begin of each step.

Then, I go into an infinite loop while entities are on the list, and for each one I simply perform my normal TryMove(x,y) script.
This script I would modify to, if GetBump()/GetKill() fail, to see if the target entity is on that list, and if so, do not remove itself from the list and carry on with the rest.

However:
This would only affect direct entity-to-entity bumps, but not entity-to-related-item bumps.
Consider:

   #  @-S
O- #R
   #
S = Sworded character
R = Roach
# = Yellow door
@ = orb

If the S would move before the roach, the roach could pass.
If not, it couldn't.
The only way to pass this would be either to:
1) Perform complex checks to see if such situation are possible. (Bad idea)
2) Bring in a second list, this time containing entities that tried to move already but failed. Then if an entity, by moving, activates a certain item (like an orb), all of these would be re-added to the list.

So I consider just sticking to bumps. (Thus giving the illusion that entities will move away for them, if they have room).

Another movement-order affected situation:

O-  R-S

This time, R dies only if S moves first, but not the other way around. (Since it technically isn't a denied Bump, it's an approved Kill, resulting in suicide of the roach)

-Insane

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

Maurog wrote:
Move order - blue before red. How do you avoid this?

The idea was that primary moves are tried first, then secondary moves, etc. So:

    R |        |
   R  |     R  |
O-    |  O-R   |

Blue: I'd like to move SW, which is free, so here I go.
Red: Me too! Yay!

    R |        |
   R  |     R  |
O-    |  O-R   |

Blue: I'd like to try moving SW first, but it's blocked by you, Red Roach. Mind moving out of my way?
Red: Not at all, my good chap. Lookit me moving SW!
Blue: Indeed! Me now!

If red was blocked for some reason, it'd go something like this in stead:

    R |        |
  #R  |    #RR |
O-##  |  O-##  |

Blue: Hey, Red Roach, you're blocking my path into the southwest! Get out of my way!
Red: Sorry, can't. Also, you're being rude.
Blue: Grumble. Guess I'll be going south in stead, then, which happens to be free.

Insane wrote:

   #  @-S
O- #R
   #
S = Sworded character
R = Roach
# = Yellow door
@ = orb

If the S would move before the roach, the roach could pass.
If not, it couldn't.

Situations like these are the reason I suggested to give different monster types different movement priorities. For example, process all roaches first, treating other monsters as impassable obstacles, then process all sworded characters, etc. So, if roaches are processed first, the roach will not pass in that example, and..

Another movement-order affected situation:

O-  R-S

..the roach will survive. If on the other hand you give sworded characters higher priority than roaches, the first roach will pass and the second one will die. Either way it would be consistent within the game.

Insane
Level: Master Delver

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

File: styleSheet.png (4.5 KB)
Downloaded 53 times.
License: Public Domain

In this case I'd suggest to not introduce global monster orders, but to stick to DROD's movement order plus asking other monsters to move out of the way.

Your illustration above sheds some new light on this anyways, so I suggest not using a global list, but directly asking that monster if it can move before you (instead of after you).
This would also be consistent with my current movement style (using a function called TryMove(x, y) that wraps all of this up and returns true/false, although I'd have to introduce a new function, called StepFirst() which basically either processes Step() or returns false, which it does is hardcoded into the monster. (ie. immobile living objects would not do so in this case. Examples of such are swords, rock golem bodies, gel tiles etc. (not implying these will be implemented))

Further, I'd like to kindly ask if anybody could make me some cool tiles.
I believe the actual tiles are obvious on what they are, if not:


Oh yeah, and the actual tiles can be any size, as can the room.
I'd like them to be 22x22, if possible.
EDIT: I forgot to point out that unlike DROD, entity tiles facing east, and go counterclockwise.

-Insane

---

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

Maurog
Level: Smitemaster

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

Hmm...

R R

 |
 @

____________________________
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

Maurog wrote:
Hmm...

R R

 |
 @

Blue: Yay I can move!
Red: But now I can't move anymore! Can you please go out of the way?
Blue: I'm sorry, but I've already moved, in case you haven't noticed.
Red: Oh well, fine. I'll take the alternative.

RR
 |
 @

-Insane

Maurog
Level: Smitemaster

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

Now reverse the colors and you will understand what I meant.

____________________________
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

But that's not the point.
He never tried to prove that movement order didn't play a role, he implied that his idea would prevent spaces after roaches move. There's no space in your situation, and it's the exact same using DROD logic too.

-Insane

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

Here's how a simple implementation designed by me would do it:

Make a list (I believe a list is the fastest implementation of this. If each monster stores iterators to itself, all operations used here become O(1))
Each monster is inserted into the vector according to some predetermined order.
Each monster tries to move.
If a monster's movement is blocked by another monster, it will move itself back in the movement vector, just beyond the monster blocking it. It will also record the size of the vector.
If a monster's movement is blocked by an obstacle, it will try and find the first square blocked by a monster to follow behind.
If it wasn't blocked by a monster, it moves normally.
If it was, it doesn't.
When the monster's turn comes up again, it looks at the monster it was blocked by. If the monster has decided to wait, the first monster will search for another appropriate square. If it moved away, the monster will take that square, and if the other monster has yet to move, it will push itself behind it yet again.
If a monster's turn comes up again and the monster queue is the exact same size as it was last time (all monsters are bottled up by each other), it will attempt a new move anyway, since otherwise we have an infinite loop.

There are some major flaws, but this is the most simplistic implementation.