OK, so my first iPhone project was supposed to be a throwaway game, that I was going to spend a week or so on to get a feel for the process and try out some new techniques, and then shove it into a dark corner of my hard drive, never to be seen again, and certainly not submitted to the app store. It was a fairly basic maze game, with the twist that, as the name suggests, it’s actually 3D: not a 3D representation of a 2D maze like the other maze games out there, but an actual 3D maze consisting of multiple floors where you have to climb up and down ladders.
The flaw in this plan was that, after some days getting the basics in place, when I was testing things, I kept finding myself going “let me just find the exit” instead of simply stopping when I should. Eventually I realized that while it’s not exactly going to set the app store on fire, it’s actually rather fun and interesting, which I wasn’t at all intending; it was supposed to be just an experiment. But bowing to the inevitable and figuring I shouldn’t keep it to myself after all, I said “what the heck” and starting making a real game out of it.
The main graphical focus here is on combined meshes constructed on the fly with dynamically created lighting/shadow effects and an emphasis on getting high performance (check out the FPS, woot). I spent quite a bit of time on the controls so it has a nice slick feel, and put in some navigational aids for fun, like the options to show a compass and leave a trail of breadcrumbs behind so you can tell where you’ve been, at a cost of making your time run faster.
The last couple shots are from the computer version, which is pretty much the same aside from the controls and higher-res textures and sound; I’ll probably make higher-res meshes too. The last bit shows a normal-sized maze in the editor…takes about 5 seconds to generate on the device, and .15 seconds on my G5.
Anyway, it’s been fun and educational, even if I ended up spending way more time on it than I planned…
I like the idea … Whereas some RPG games half-try to avoid indoor lost of orientation, you push it to an extent and turn it to a gamedesign.
That’s cool, really
Go for it !
edit : you could even push it to a VERY extent, and add some claustrophobia elements into it … Like playing with people’s innate claustrophobia … I don’t know, like walls becoming smaller (but not harmfully), a fog slowly installing, or the avatar’s breathing sound increasing when the walls are becoming very close between each other …
You should push it very far, imho, would be a great concept ^^
Thats pretty awesome! I am pretty new to Unity, so please excuse the nooby sounding question.
Did you model all the parts of the maze seperately in your modeling program of choice, and then import those parts individually into unity and put them together? Or did you model the whole level in a 3d modeling program?
Pretty much, except I only imported the parts, and the script I wrote actually puts them together. The walls, floor, and ceilings aren’t modeled; they’re simple generated planes made by script (4 vertices/2 triangles). The various bits and bobs (ladders/pipes/vents/etc.) were modeled though.
The mazes are all dynamically generated (including the background maze on the title screen), so they are different every time. I wrote a (rather lengthy) routine that creates the maze, then goes through and calculates the lighting and where to put all the walls and ladders and stuff.
I read this for mazes, and the best resources so far for mesh construction are the CombineChildren scripts and the procedural examples. It’s much faster to build everything on the fly instead of instantiating a bunch of objects and then combining them later, not to mention it uses less memory. But, as you would expect, it’s somewhat more complicated too.
(Tip: use MultiplyPoint3x4 instead of MultiplyPoint like MeshCombineUtility does…it’s a fair bit faster and does basically the same thing. I don’t understand it enough to know why UT didn’t use it for that script to speed things up a little, but so far I’ve never had any problems. Tip #2: I normally don’t manually compute normals, but just call Mesh.RecalculateNormals() when I’m done. Again, faster and usually ends up having the same results anyway.)
Looks good Eric - glad this test project god out of hand
I was wondering about the controls though. Not owning a device to test on, I have absolutely no base for comparison, but how come you didn’t go for tilt-control for movement?
Actually I did. Some people prefer touch, some people prefer tilt, so I figured why not include both. My personal preference is to use tilt for up/down looking and touch for turning (forward/back is always touch).
