PDA

View Full Version : WFTO 0.2 Preview



dotted
October 8th, 2009, 02:14
http://www.youtube.com/watch?v=gIgkAYjyD7g&hd=1

Enjoy

reybag
October 8th, 2009, 05:20
cool,now i only want to see some trolls in action :D,of course i will have to wait a lot but i like to say trolls :D

Dark_Omega MK2
October 8th, 2009, 05:46
Its looking pretty good... The ground (not claimed ground) pattern looks the same and the imp moves a bit ackward... but thats undertandable... i also how you can move the camera, angles, scale freely thats pretty cool and something i really didnt likes about both DKs with the zoom out limit.

Really good job guys...

:fly::fly::fly::fly:
i give you 4 flies out of 5

danvzare
October 9th, 2009, 11:54
If I was you I would try to work on compatibility because almost no one could play the last one

Shkykeeper
October 12th, 2009, 10:16
Hrmm. Not to nitpick, but even though it's 0.2 and you've got to expect hinky stuff to crop up...what;s with the imp leaving random parcels of land unclaimed?

Blutonium
October 12th, 2009, 12:27
Hrmm. Not to nitpick, but even though it's 0.2 and you've got to expect hinky stuff to crop up...what;s with the imp leaving random parcels of land unclaimed?

+1

but in their defence, even the imps in Dk1 were kind of weird when claiming land...sometimes...

dotted
October 12th, 2009, 16:47
Hrmm. Not to nitpick, but even though it's 0.2 and you've got to expect hinky stuff to crop up...what;s with the imp leaving random parcels of land unclaimed?

Other than designing AI is very hard?

nebster
October 12th, 2009, 17:39
Other than designing AI is very hard?

And apart from the fact that I based it off DK1! That's what they do it DK1. All that I did was make it find all the ones on adjacent (including diagonals) that could be claimed, and chose a random one. If anyone can design a better algorithm or path to follow in all circumstances, that would be good

Metal Gear Rex
October 12th, 2009, 17:46
Maybe pick the closest first, and to prevent something like

C=Claimed, U=Unclaimed

CU
CU
CU
CC
CC
CC

You could try and make it reconize that that one unclaimed tile is surrounded by two claimed tiles, so to give it priority.

agustins69
October 12th, 2009, 17:55
Good work man!

nbk revived!

imp clasic is good, and the movements

blutonium create , creatures in this project?

Simburgur
October 12th, 2009, 18:24
And apart from the fact that I based it off DK1! That's what they do it DK1. All that I did was make it find all the ones on adjacent (including diagonals) that could be claimed, and chose a random one. If anyone can design a better algorithm or path to follow in all circumstances, that would be good


Maybe pick the closest first, and to prevent something like

C=Claimed, U=Unclaimed

CU
CU
CU
CC
CC
CC

You could try and make it reconize that that one unclaimed tile is surrounded by two claimed tiles, so to give it priority.
Or assign each tile a 'score' depending on how high the priority of claiming it is.

Say, every claimed tile adjacent (as in side on, not corners) to it would be worth 1.1, and every wall tile would be worth 1. The imp will choose highest scoring adjacent (side on and corners) tile to himself.

That should stop situations where the imp leaves out random tiles in a corridor, but I don't know how difficult it would be to code.

Kromeh
October 12th, 2009, 18:48
I think it would eat up processors, because it would be tracking each and every tile. And on a 50x50-100x100 map, that's 250 checks a tick, or past 1k checks a tick. It would slow down old processors.

If you could make it so it doesn't have to check every tile, it would work.

Metal Gear Rex
October 12th, 2009, 18:50
Well... it has to check the claimed tiles and tiles near it so yeah. Dungeon Keeper already checks the map for every turn. It probably won't lag it as much as you think.

Kromeh
October 12th, 2009, 18:53
What do you mean checks the map?

Metal Gear Rex
October 12th, 2009, 18:56
It checks what's where and stuff... that's how the ai tells creatures where to go. It was the first thing Bullfrog had to tackle.

Kromeh
October 12th, 2009, 18:58
Minutely, yes. It doesn't check 1k things a tick though.

Simburgur
October 12th, 2009, 20:05
I think it would eat up processors, because it would be tracking each and every tile. And on a 50x50-100x100 map, that's 250 checks a tick, or past 1k checks a tick. It would slow down old processors.

If you could make it so it doesn't have to check every tile, it would work.

Could be optimized one of two ways:

1) Only re-checks each tile every time an adjacent tile is modified (ie, claimed, dug out, w/e).

2) Only re-checks each tile every time an imp nearby is ready to claim a tile.

And there's probably more, but those are just off the top of my head.

Kopavel
November 6th, 2009, 14:41
Hey guys.
I've checked out NBK demo (the one that shows DK-1 level with a bile demon near dungeon heart) - and was confused. It shows far more features than WFTO 0.2 (but did you say it have the same sources?).
Too bad my previous post didn't arrive at forum (!!!) - as I stated there, I'm developing my own DK engine.
I already have some progress, and planning to show you my work in nearest future, hoping you'll be interested.

dotted
November 6th, 2009, 16:54
Hey guys.
I've checked out NBK demo (the one that shows DK-1 level with a bile demon near dungeon heart) - and was confused. It shows far more features than WFTO 0.2 (but did you say it have the same sources?).
Too bad my previous post didn't arrive at forum (!!!) - as I stated there, I'm developing my own DK engine.
I already have some progress, and planning to show you my work in nearest future, hoping you'll be interested.

No NBK is different from NBKE which was rewritten from scratch.

Blutonium
November 6th, 2009, 17:26
u guys are catching up pretty fast tho :eek:

Kopavel
November 6th, 2009, 22:04
No NBK is different from NBKE which was rewritten from scratch.

So WFTO is based on rewritten version? By whom was it rewritten?

nebster
November 8th, 2009, 15:50
Wow, everyone is helping with the imps ^^

The funny movement has since been fixed. How the imps can claim all blocks easily is beyond me at the moment. But your ideas are helping. Keep them coming!!!

So far, since you said set a score to every single block, that would mean that the imp might go to the other side of the map to check for claiming.
A better idea would be to generate a score for all adjacent blocks only and check which has the highest score.
At the moment it's completely random (or as random as you can get with the in-built C++ random number generator (It gives out random numbers like 1,1,1,2,1,3,4,2,3,1,1,1))
If you think there's a better way, or a flaw to my plan, or better to use the other way, please say. :)
I am still working on this but I'm rewriting the path finder for the 4th time. This time so the imps can walk at angles other that 0,45,90,etc. It's harder than I thought.

Blutonium
November 8th, 2009, 17:13
I got it!

Ok, my idea works like this:

Example:
http://i38.tinypic.com/24d0bkh.jpg

Grey blocks = available
Red blocks = rock/already claimed

Scenario A:
-Imp Starts at A1.
-PC looks at all 8 surrounding blocks of A1 (A2,B1,B2 is available) - it selects one at random, Block B2. then it moves to one of the other, A2, and then the last, B1. These 3 blocks were all surrounding Block A1.

-Now there are no more left to claim of the A1 surrounding blocks, and uses B1 as a starting point again. it sees C1 & C2 as surrounding blocks, and claims them.

-now there are now more blocks surrounding B1 to claim (C1 & C2 is now claimed) - it then uses it's last point, yet again (C2). the surrounding blocks of C2 are: C3, B3, D3,D2 & D1. it claims all of those.

After those are claimed, it uses D1 as a starting point......etc,etc,etc,etc

see whats happening?

http://i35.tinypic.com/14m9qq9.jpg

It just looks for the 8 surrounding blocks (image below), claims them all, and then starts again from that point.
http://i34.tinypic.com/2zfvqs8.jpg





If you look at the First "Scenario Example" pictures, every time it has claimed it's 8 surrounding blocks, the arrow color changes to *show* you.



In Scenario B, it ends up at another path because it randomly started at B1, and not B2 like Scenario A.

it also comes to a dead end twice, in position A10, and D7 (marked with yellow stars) - in this situation, the imp simply looks for the closest unclaimed block it can find, and goes on from there.

ask me any questions if you do not understand - hope this helps! :)

natchoguy
November 9th, 2009, 01:25
how about the walls?

Blutonium
November 9th, 2009, 06:18
easy.
-Start at one part
-Randomly go left or right
-Keep going until Dead end
-Search for next closest wall to fortify

Hapuga
November 9th, 2009, 11:05
Scenario A is not logical from the beginning.

why moving from B3 to D3 when move B3-A3 is much more logical? the chain then proceeds as A4-B4-B5-A5-A6-B6 and so on.

Scenario B hold similar errors.

B3-C2 move is totally illogical. B3-B4, and proceed as pictured.


The more imp runs back and forth, the more time you lose.
Imp should cover as much territory as possible in shortest time. Running around wastes precious seconds.

The most serious argument from my side is, that when you have a direct line with several side ways, short ones, say, 3-4 tiles. And there is a portal up in front. If the imp will waste his time claiming "strategic" corners, you will lose the portal to another player.

Blutonium
November 9th, 2009, 12:29
it's not the most perfect solution that can possibly be coded, but IMO this is a good, and CHEAP way, to code it.

this doesn't use any complicated code and also has no overhead - it simply takes a tile, claims all adjacent tiles, and uses the last tile to do it again.

It's not perfect, like I said, but he will NOT claim in a straight line and leave unclaimed tiles behind such as in the video preview.

It's almost like the one nebster is coding (looks at adjacent tiles), except for one thing - it's not random - it basically claims a 3x3 grid of tiles at a time (9 in total) without ever missing one.

Hapuga - yes, he doesn't move perfectly - but at least this algorithm doesn't miss any tiles.

yes, he has to run back from B3 to D3, but how would you code that he goes from B3 to A3 instead, with a SIMPLE solution?

you might give him an algorithm to always run straight forward if there is a tile available in front of him "to save time", but then he will start skipping a few, like the video =/

to sum up my algorithm - the imp claims the land chunk by chunk, not tile by tile. he claims an area at a time, instead of just claiming in a straight line or randomly.

dotted
November 9th, 2009, 12:40
So WFTO is based on rewritten version? By whom was it rewritten?

http://z9.invisionfree.com/Keeper_Klan_Forum/index.php?showtopic=1540

Hapuga
November 9th, 2009, 13:22
it's not the most perfect solution that can possibly be coded, but IMO this is a good, and CHEAP way, to code it.

this doesn't use any complicated code and also has no overhead - it simply takes a tile, claims all adjacent tiles, and uses the last tile to do it again.

It's not perfect, like I said, but he will NOT claim in a straight line and leave unclaimed tiles behind such as in the video preview.

It's almost like the one nebster is coding (looks at adjacent tiles), except for one thing - it's not random - it basically claims a 3x3 grid of tiles at a time (9 in total) without ever missing one.

Hapuga - yes, he doesn't move perfectly - but at least this algorithm doesn't miss any tiles.

yes, he has to run back from B3 to D3, but how would you code that he goes from B3 to A3 instead, with a SIMPLE solution?

you might give him an algorithm to always run straight forward if there is a tile available in front of him "to save time", but then he will start skipping a few, like the video =/

to sum up my algorithm - the imp claims the land chunk by chunk, not tile by tile. he claims an area at a time, instead of just claiming in a straight line or randomly.

Yes, chunk by chunk is the most reasonable solution. however, there must be a way to set him do priority tasks over common claiming, if that is possible. For example, make him "feel" when the pass to the critical point such as unclaimed portal or other room is open, and work towards it. Setting the "feel" radius will abolish the problem of seeing an object in the other map corner and rapidly moving there, ignoring all around. If no such points are available, work in a regular manner.

Is that possible?

natchoguy
November 9th, 2009, 14:50
What if you can choose different imp behaviors so you can choose the pattern he claims land and also choose what type of walls it will mine first and other stuff

Hapuga
November 9th, 2009, 15:13
how do you imagine that?

natchoguy
November 9th, 2009, 15:28
не знаю- maybe a thing in some random options menu or it is random for evry imp (they should have different personalities).

Hapuga
November 9th, 2009, 15:34
that would be close to impossible to implement. Terrain is always changing, imagine me digging a huge square 10x10 tiles, and an imp has a "narrow tunnel" script.

Никак =)

natchoguy
November 9th, 2009, 15:38
xoрошo...

Trass3r
November 9th, 2009, 17:08
Trickiest thing is to make them communicate smartly. As soon as a tile is *targeted* by an imp the others imps in the area don't choose that one anymore.
This prevents the DK2 behavior where they didn't get that information until the imp actually began claiming.

If this is easier to implement one could even use a foreman concept.

Blutonium
November 9th, 2009, 17:56
What if you can choose different imp behaviors so you can choose the pattern he claims land and also choose what type of walls it will mine first and other stuff

that will make gameplay too complicated...the imps should think for themselves.

Blutonium
November 9th, 2009, 17:59
Trickiest thing is to make them communicate smartly. As soon as a tile is *targeted* by an imp the others imps in the area don't choose that one anymore.
This prevents the DK2 behavior where they didn't get that information until the imp actually began claiming.

If this is easier to implement one could even use a foreman concept.

that's easy for programmers

They just set the tile's status to "Claiming in progress" if an imp goes for it

when an imp wats to claim a tile, it first checks if another imp "doesn't have it's eye on it" :p

Kopavel
November 9th, 2009, 19:35
http://z9.invisionfree.com/Keeper_Klan_Forum/index.php?showtopic=1540

Thanks!
But are you really planning to use it for WFTO? IKSLM have done a great job, but NBKE engine design is not applicable to anything bigger than NBKE currently is. And I feel that with artist like Synesthesia WFTO can get much bigger.

dotted
November 12th, 2009, 00:49
Thanks!
But are you really planning to use it for WFTO? IKSLM have done a great job, but NBKE engine design is not applicable to anything bigger than NBKE currently is. And I feel that with artist like Synesthesia WFTO can get much bigger.

NBKE is basicly just a starting point, so we didnt have to start from scratch.

Trass3r
November 12th, 2009, 09:51
but NBKE engine design is not applicable to anything bigger than NBKE currently is
care to elaborate?

Kopavel
November 12th, 2009, 13:09
care to elaborate?
- No good middleware used (for, say UI, math, physics, sound, animation), while these base systems are either not implemented or poorly implemented.
- Bad class design (), and usage of OpenGL types and lack of microsoft-specific optimizations (In Windows application!)
- Bad rendering code - draw calls are not sorted, and not multithreaded (and it looks like its not possible to improve it without completely rewriting the whole thing), lots of direct Graphics API calls (these are extremely hard to track)
- Bad project structure: lots of namespaces, no forward declarations, no solid PCH.

Anyway, as I already said, NBKE is fine software, but I am more experienced developer, and I would never use it to write something on top of it.

Please take no offense, and wait untill I present my version of DK renderer for you to judge.

Trass3r
November 12th, 2009, 16:07
- Bad class design (), and usage of OpenGL types and lack of microsoft-specific optimizations (In Windows application!)
- Bad project structure: lots of namespaces, no forward declarations
Namespaces...forward declarations...
C++ is such a f-in dinosaur :D

Blutonium
November 12th, 2009, 16:39
Please take no offense, and wait untill I present my version of DK renderer for you to judge.

if you think you can do it, then show us :)

the screenshot looks very promising, i must say, but coding an entire engine is another story.

If you can catch up to NBK and prove you have a better engine, you can have my models.

Kopavel
November 12th, 2009, 17:51
Namespaces...forward declarations...
C++ is such a f-in dinosaur :D

He-he... already switched to D? xD

dotted
November 12th, 2009, 18:20
and usage of OpenGL types and lack of microsoft-specific optimizations (In Windows application!)

Well we would were much like for this to be multi-platform and i would imagine at this stage optimizing for Windows would hurt us in the long run?

Also do you have a history of spamming wordpress blogs? Akismet seems to block nearly all your posts.

Trass3r
November 12th, 2009, 23:21
He-he... already switched to D? xD
Of course, once you get used to it, you don't wanna go back ;)

Kopavel
November 13th, 2009, 21:44
Well we would were much like for this to be multi-platform and i would imagine at this stage optimizing for Windows would hurt us in the long run?

Also do you have a history of spamming wordpress blogs? Akismet seems to block nearly all your posts.

It's currently Windows-only. IMHO theres little sense in writing games for linux.
And no, I dont spam any blogs.

nebster
November 14th, 2009, 18:10
Of course, once you get used to it, you don't wanna go back ;)

I agree, unluckily I'm stuck with C++ for this :P

Also, someone mentioned earlier that the imps shouldn't go after the same blocks. This is actually already implemented

Edit: Kopavel, if you can design a better base (hopefully in D since it's very similar to C++ but tends to be faster, safer and more efficient overall), we could possibly use it and scrap the old one.

I really wanted one that everything is modular so there's dll's (or the D equivalent which is faster and works better) for absolutely everything. So there's one for the renderer and it gets the data to render and return true when there's an idle thread to write it to the buffer.

This I think would work well because it's loaded into memory just like the original exe so it would run just as fast.
Also, it means if there's a bug, it's just replacing the relevant section, as well as it means that we could have different renderers (one for opengl, one for directx), different sound systems, etc. Rather than building it all in since it means that it would run a bit faster (I know only a small difference but it adds up)

Zhampir
April 23rd, 2010, 07:31
huh... I'm not an advanced programmer by any means... but I've developed some ideas for this... not sure if they're practical though (a part of my ongoing journal of DK programming updates [I only have access to C++ 2005 right now..., and I just got it, previous all I ever used was VB and... I really didn't go far into it, but I'm a quick study with code (at least my instructor was impressed))

Some later improvements have all ready been basically displayed [An Impish Idea (http://forum.keeperklan.com/impish-idea-t950.html)](in C++ again).. I have no idea how to implement it (we didn't even get to sorting in that class... it was lame... I was a month ahead of the class and had nothing to do... I'm not good at ideas for what to write, I just know how to write it (or I typically look it up, but this seems like it'd be a more complicated process to look up, and I'd rather spend my time developing the idea so I can actually get to writing it, breaking down the dream to achievable goals one step at a time)

The Search function:
This idea was based off of how I think DK1 works:
Basically it checks every tile on the map, see's what objects are there.
The search function is a base for many others such as movement for an imp's duties(either by the imp to claim land/fortify walls/gold/bodies and so on), and fighting.

It would be sent what to look for and the creature's resistance to lave or flying. Then execute the movement (while using it's own function to search for a fight) if found true, else it returns as false and the next desirable "object" is searched for.
For items (ie not fights) The search would start from the dungeon's heart in an increasing circular pattern, If lava is encountered (or a some other obstacle) then a path of movement would be calculated (I never learned directed maze-like movement..., but I'm guessing that this would start from most direct until it hit an obstacle then check the sides, if an obstacle if found the current block of reference is marked as blocked and returns to the previous block of reference until a path is found) if this function returns false (it cannot find a path) the the search function returns false entirely, if true then the creature moves.
For fighting the "sphere of view" would depend upon the creatures max amount of seeable tiles and it's angle of view. Forming a cone of view, with smaller "blocked" cones forming in the case of an obstruction (wall/ door/ so forth) If an enemy creature/door/trap is found then if a creature is found is checks to see if your creature can see invisible (if true than skips next step) and check to see if the enemy is invisible (if true then the search for fight returns false) If either of those 2 return true, then the game doesn't even bother checking to see if your creature is invisible or not, it just makes them visible. After that (in the same nested if/then as before) it initiates the attack procedure (which I'm sure any decent programmer could figure out, lot of directed "random" functions mixed in with stat comparisons)
Not sure how this would really work with randomly claiming land, but you seem to have that down (how it works seems perfectly fine with me, I have no problem with it... just make more imps...I tend to go for 25)

an Idea posted in the aforementioned thread of "user directed imp paths" came up, and I like this idea. It would basically work the same as as the my "flagging" idea, and the imp would ignore all unclaimed territory until those that are in it's most directed path are claimed (could potentially work the same as fortify walls, and I would likely design the movement function with these in mind so i only have to write one function to do basically the same thing)

Of course, unless "ignore fights" is checked, the game would constantly check for fights.

note that I'm not going to post actual code on the forums, if you want it you'll have to pm me, besides that I haven't actually wrote most of it mostly just pure speculation after playing the game for the last several years.