Pseudo-3D Dungeon View

#61 If you put in pack I will buy it. Outstanding work.

#62 @Fucifer, now, if only 356 more people say that, I can buy my BMW :)

haha -- on a serious note, thanks :)

#63 Count me in. So, that's 2/356. heh.

#64 Haha ... I can buy a matchbox BMW so far ... w00t w00t ... ;)

back to work now ... :)

#65 At $15-19, you probably could afford a remote control BMW. Maybe...

side note: artpakz has new packs coming out, they have them posted on their site. Perhaps they can make a dungeon/monsters pack too to go with your dungeon pack.

#66 @A, yeah ... I've been in communications with Artgirl since he initial release dates -- I'm SOOOOOO anxious to get my hands on the Zombie Artwork ... I'm hearing good stuff so far ... can't wait to get my hands on it ...

and yeah ... I was thinking of selling the content pack for $250 ... hence the odd 256 number ...

But, of course, I'm only kidding ... I don't need a real BMW ... I can live with a gas powered RC version ... ;)

And yeah, $15-20 would be the going rate, if I opt to sell it ...

#67 And ... for those of you who would like to see this in action, or have doubts about it's usability, haha ... either way ... here is a VIDEO of it in action ...

TGB Dungeon Builder by David Higgins and James Rozee, Video Demo 1

In this video, you'll see me navigating the dungeon, and at the end you'll see the Tile-Layer that was used to build the dungeon ... for those of you who pay close attention, you might notice some of the issues I'm having thus far with the render system ... but I'll work out those kinks soon enough ... the large number of static sprites in the Level Builder that are placed together, are just demo graphics to help figure out some of the math offsets and to help test camera positioning for POV and various other offsets -- everything seen in the Level Builder is 'cleared' from the scene graph at level startup, %sg.clearScene() is called in every "updateScene" as well ...

Anyhow, love to hear some feedback on the video version ... it's a much better way to demo this out then the screenshots ... as there fairly static, and they don't really show the "movement" ...

Some things to note ... my player.cs has the follow key-mappings WASD ... A and D simply "rotate" the player around ... changing the players direction from North to West, to South, to East, to North ... and in reverse, depending on the key ... W and S simply move forward or backward ...


very basic 'dungeon crawling' code is not complete ... now to clean it up, add some debug rendering (setBlendColor is an awesome debug trick for this type of rendering)

Some stuff is rendering too early ... or at least, it appears to ...

For instance, if you compare the map used to the video walk-thru ... you might notice how the to right-hallways continue to keep going, but for some reason when I turn into them ... theres a WALL ... heh, I think that might be 'goofed' math in the perspective hall code ...

otherwise, everything seems great so far ... enjoy the video ....

#68 Started a .plan, might be easier to track progress there ... this thread is starting to take minutes to load ... haha :)

TGB Dungeon Builder ... I'll continue to post tedious updates to this thread, as I have been so far ... but I'll post major updates to the above .plan, or create a new .plan depending on how 'major' the update is -- I'm also tracking the progress on my website, Zoul Creations, which you can browse the RSS Feeds for on my GGE Profile ...

#69 Sweet! Reminds me of Wizardry. I didn't think this kind of thing was possible in T2D.

@David, what recording software did you use? Are you able to record in-game audio?

Thanks

#70 @Kevin, I used a trial edition of Camtasia Studio -- links to it should be available on the video page ...

As for recording in-game audio, yes ... you can set the various different things to record --

It even has the ability to record from a Webcam to include 'Picture in Picture' overlays of the on-screen recording AND the webcam ... and is capable of recording from various audio inputs as well (not sure if it can record from various audio inputs at once though ... )

It also comes with a complete editing studio, so you could record the game audio ... then do a voice-over seperately and mix them together ...

#71 Wow. Awesome.

Thanks again!

#72 I posted a secondary video, Demo 2 to the .plan -- it shows some corrections in the render system ... as well as my use of setBlendColor for debugging ... and, gives a better idea of how this looks with a UI wrapped around it ...

#73 Whilst on the whole this is a cool idea, i think there are some glaring problems ...

I don't think you have understood what Oliver meant when he mentioned the point of view thing. Compare the picture he linked and yours from after you changed the POV. All you've done is moved the "camera" up and kept it looking straight ahead. This has the effect that you can't see the floor where your feet would be and the perspective feels really really weird.

I think that you either need to tilt the "camera" down a bit and ensure the perspective is correct, or go back to the dead center position. The former would be considerably better.

Another thing is lighting, or the lack thereof in your version. The lack of lighting contributes to the overall feeling of weirdness quite a lot. If you look again at the picture Oliver linked, you have some degree of shadowing on the walls and you can't see the whole length of the corridor due to fogging.

This adds a lot to the feeling of general doom and gloom that goes along with the dungeon, but also makes it feel more like the real world. The other nice thing about the shadowing is it makes the walls feel like they are looming above you ... or it would do if there wasnt a gap at the top of the picture ;-)

Most of the lighting issues are just texture issues which are easily fixed by a competent artist. You do need to implement the distance fogging in code, though.

T.

#74 @Tom: The engine isn't complete. David and I were talking about lighting this weekend and we have a plan for it. I have the basic artwork done up, I just have to send it to him later today. Hopefully, my skills are competent enough for test purposes. :)

#75 @Tom: Yeah... I used the wrong term. The correct term would be "vanishing point" I think. And you can't really change this one so easily. I experimented with OpenGL/DirectX and of course you can't just simply do this by abitary quads either.

What I did was make a lot of recorded actions in Photoshop and use these to generate the textures. Of course I did them by hand and thus they aren't perfect as seen on the concept mock up I made. :) After the exam though I plan on writing a texture generator so you can change the vanishing point by script and all textures get re-generated so it looks correct again.

But I also think, as Tom said, a competent artist would do a much better job than a bit of math magic.. an artist can "trick" to make the perspective look cool even though it might not be completely correct. Me and a friend of mine, who is a good artist, played around a bit with this on paper. :) Also looking at Dungeon Master II gave me a lot of ideas for things like transitions between grounds.

In Dungeon Master 2 the grounds/ceilings are one single texture.. things could get ugly if you have to make transitions using single perspective tiles. Dungeon Master solves this by having special areas where you can only turn backwards, not in 90 degree steps, with a nice border hiding the transition line. So it looks like you're stepping through a door for instance. :)

#76 It is actually quite straight forward if you are using textured quads.
Each quad just has its edges parrallel to the perpspective lines running from your view 'corners' to the vanishing point. Then simply offset by distance along the view path for each block visible and you're done.

#77 @Tom, along with the "POV" values I added to the render engine, and some properly generated artwork, the "vanishing point" and the "point of view" would be able to be done as Oliver had intended -- as it's been said earlier in this thread, to accomplish the look you want, you have to piece together some very well put together artwork ...

@Neo, I've not a clue what you said ... :)


Anyhow, the Dungeon Builder, so far, has only had about 6 hours of work put into it ... as far as the code goes ... there's been quite some time put into how it may work and how it would be best to implement it from a TGB Level Builder perspective ...

As James mentioned, we are working on a simulated light system, using alpha-blended textures that will be overlaid on-top of the actual textures ... this is, for the time being, just an idea and still has to be tested ... it may also be possible to just simple alpha-blend the real textures without overlays ... but I'm thinking with overlays we can use a gradient fading texture to allow for a 'fade to shadow' effect ...

In one of the previous posts, you can see the image map I created for testing out the render system, in the image map it includes two frames ... one is a perspective wall/floor and the other is a 1x1 square, both are intended to be used as 'shadow overlays' ...

The distance stuff, is completely configurable ... you can set the view distance to 4 and it will only render the tile you are in and 3 in the forward distance ...

But again, I re-iterate, to accomplish an outstanding look and feel, you -MUST- have outstanding artwork ...

The 3D look is 100% simulated with 2D graphics, TGB may be using 3D Quads internally, but it only renders them at a static angle, and I am not changing that (at least not yet, might in the future) ...

This entire thing has also been implemented in TorqueScript, and has so far not had any C++ written to accomplish this ...

I am no artist, so i can't accomplish the outstanding artwork on my own, James is doing his best, and we'll see how good it gets as we continue progressing ...

The size of the Forward Wall and Perspective Wall are also configurable, allowing you to use different sizes as well as different scale values -- I am using powers of 2 in the textures for testing, easier to do the math when I have a question about why it rendered somewhere weird ... I am also using a scale of 50 (50% or 0.50) ...

#78 @David:
Imagine a rectangle that overlays your view rect, then pick e.g. the center of that rectangle as the vanishing point. If you draw lines from each of the 4 corners to the vanishing point it gives you the lines to align poly edges too (which is also easy as you just place the points of the quad where the perspective lines and the
z-depth/distance down the view meet). The control rect can be moved around and scaled and it will affect how things are drawn in the view rect without changing anything. But as you said you want to keep it entirely in script so feel free to disregard ;p (I have written a custom scene object that actually does skewing/etc so I forgot it is not standard)

As for your lighting: have a few layers of an alpha shadow sprite (very low alpha and radial gradient) that
are drawn over each other, each further one being scaled smaller (similiar to your walls, etc). This will additively darken the hallway as it goes along as well as cheat-fog characters coming down the hallway etc...

#79 @Neo, yeah I was intending on possibly using 3 images to simulate 'lighting,fog,shadows' ... one would be a gradient that started 100% transparent and slowly faded into a light grey ... then, using alpha-blending, I can set the overall transparency of that sprite and the color (to simulate white, red, yellow, blue lighting, for example) ... and then continue drawing that sprite on top of the walls using the current code, but gradually making the blend darker and darker ... so if the first sprite had an alpha of say 20, the next sprite might have an alpha of 50 ... so the right and left edges have the same 'alpha' (remember, the left edge of the sprite has a lower alpha then the right as its 'semi-transparent') ... this of course, would require yet again, some more debugging, tons of testing, and a bit of math ...

As for your examples, they sound great ... but for now, I want to try to accomplish as much of this in TorqueScript as possible, to allow for it to be as usable as possible by as many as possible ...

If I implement any of it in C++, that eliminates non-Pro users from being able to use it, and for those out there with Pro Licenses that don't know C++, it reduces/eliminates their abilities to tweak and modify things on a whim as well ...

If I get to a point where I start pulling hairs and going ... "Grrr, I can do this in C++ ... but why cant I pull it off in TorqueScript?" ... then I'll re-evaluate that decision ...

I was also thinking of making two copies, when the TorqueScript version is completed, porting all of it over and possibly making it a custom C++ Object exposed to TorqueScript ... lots and lots of possibilities, tons of ideas ... no real final decisions yet ...

Still playing with the idea, but as it seems to have attracted quite a following, I'll keep going and try to make it as usable as possible, with in the scope of my abilities.

#80 Is it possible to have moving clouds, moving sun, or weather effects using this? I'm not familiar enough with TGB yet to know what is/is not possible. But man, I'm interested in this resource!

Also, it looks to me like in some of the screenshots you can see where the tiles end/start, because the images don't "wrap around" properly if you know what I mean. Am I correct in assuming this can be done simply with the right size texture images?


- Houdini