3d wolfenstein-ish engine

This is so awesome.How did you do that.Can you make a Game?Thats amazing.

i am SOOO AMAZED at how you accomplished this! at first i thought you'd have used an array object or something to workout where to place the walls but the way you did it makes to so easy to create levels!

Yeah you can add jumping, however it gets a little tricky because I used the built in physics engine for the collisions so working out 3d collisions with a 2d physics engine could be rather tricky..but not impossible...and then its just a case of moving the 3d box's along the y axis...although if you wanted to allowing 3d looking around (like unreal etc) the maths gets a bit more tricky....

I know I'm a bit late in saying this, but this is truly amazing.

I could only imagine what would be possible now if Construct had the ability to load 3D meshes or even other shapes rather than just cubes. We could possibly see something on the level of Doom, Duke Nukem 3D or even better, maybe even Quake.

We could possibly see something on the level of Doom, Duke Nukem 3D or even better, maybe even Quake.

Quake would probably be out of the question. Ashley and others have been pretty clear on just how difficult it would be to make a "true" 3d engine. Doom might be a realistic goal, though.

Well... for someone else, at least. I'm only certain of what I'm not capable of.

ive started making a 3d mario test using this. pretty sweet

david i have one question?

for the events setting x and z of each wall3d, did you find those multipliers like and adders like this (sin(Wall('angle')) * Wall('distance') * 64 + 320) through trial and error, or is their some kind of logic behind them?

and how are "Wall" picked for those action pertaining to wall3d in an always

for the events setting x and z of each wall3d, did you find those multipliers like and adders like this (sin(Wall('angle')) * Wall('distance') * 64 + 320) through trial and error, or is their some kind of logic behind them?

and how are "Wall" picked for those action pertaining to wall3d in an always

It's simple really... you see... he picked the quantum mechanics of the obliterating photon particle beam and utilized them in such a manner that the fabric barrier of stellar and interstellar simultaneous fluctuation was transmogrified into a paradigm shift of reality vs creating x-rays using cello tape.

Sif you didn't know that

~Sol

well each 3d cube is 64x64...hence the multiply by 64 ... and the centre of the screen horizontally is 320...so i added 320.

When setting the z co-ordinate, I had to add + 8.5 because that brings the cube forwards out of the screen, such that it exists in the same 3d space as the camera which is looking at the cubes...thats the only 'magic' number If you remove that number and spin around its like ur spinning the world around and looking at it from a distance...its kinda weird lol.

The sin and cos stuff is just for rotating one shape around another shape.

and how are "Wall" picked for those action pertaining to wall3d in an always

Construct using a paring system, so if you have a tank base and a tank turret, and then use 'always - set tank turret to tank base' it will give one turret to each tank base.

Containers do the exact same thing, except if a condition unpicks an object, all the other objects which are contained are also unpicked.

>

> for the events setting x and z of each wall3d, did you find those multipliers like and adders like this (sin(Wall('angle')) * Wall('distance') * 64 + 320) through trial and error, or is their some kind of logic behind them?

>

> and how are "Wall" picked for those action pertaining to wall3d in an always

>

It's simple really... you see... he picked the quantum mechanics of the obliterating photon particle beam and utilized them in such a manner that the fabric barrier of stellar and interstellar simultaneous fluctuation was transmogrified into a paradigm shift of reality vs creating x-rays using cello tape.

Sif you didn't know that

~Sol

HAHAHAHA

ah k, 8.5 was puzzling me, after posting i quickly realised the other 2.

im trying to make a camera that can look up and down in this world, but i cant get it right yet, i imagine you need to move the boxes along y by their depth when you change the pitch/roll/yaw due to camera changes, making it work is hard tho any tips?

It easy to make objects be on top of each other, you just have to add a y component to the private variables and translate them. However looking up and down is a lot trickier. It can of course be done its just I dont know the maths....it might be better to use a form of matrix transformation instead of my quick and easy method.

This is a great engine, would you mind if I tried to tweak it slightly, maybe even downgrade it to a system similar to old DOS style RPG's like Eye of the Beholder?

<img src="http://www.classicamiga.com/images/stories/jreviews/games/E/EyeOfTheBeholderIIAGA_004.png">

It uses a UI and Mouse clicks to move around in a semi turn based fashion rather than the real time that you've used, but it's something I've always been interested in working on.

I'd like to see a game like the first Elder Scrolls game 'Arena'

I'm sure David wouldn't mind .

Have a go and see what you can make.