That is tough, and fun! The only suggestion I have is to add color to differentiate between the upcoming blocks and the background blocks. As it stands now you can only tell with movement due to parallax motion (maybe that’s the idea, though).
Using a depth of field shader like the one in the Shader Replacement example project would really help the player perceive distance. This would require Unity Pro though.
Sorry, I totally missed your question FoxDie73! Here my late answer:
A level consists of slices. A slice is a “wall” of obstacles.
When the level is loaded, first the positions of the slices are determined. Then they are turned to face the previous slice and lastly, the wall-meshs are created procedurally.
The jet-thing has an invisible tractor in front of it. When you do input, the tractor is moved around on a 9x9 grid perpendicular to the movement direction. This tractor is connected to the jet via a hingeJoint.
This tractor has a parent tractor, which is responsible for the forwards movement. Basically I just lerp between oldSlice and newSlice.
Great idea, thanks!
Havn’t got Unity Pro yet, so I’ll have to wait with that.
Please check out the new verion in top post - thanks!
Thanks for the explanation Der Dude. I am a total noob when it comes to scripting. I’m trying to do a similar thing with blocks coming down a path. Can you point me in the direction of any tutorials on how to create that procedural wall/slice you mentioned.
Yup, looking really good. Now if I could make another suggestion, maybe instead of blowing up when you hit a wall, you break through and lose points instead of flat out losing the level. And if you go into negative points you have to start over.
Interesting concept. If I wasn’t epeleptic before, I sure am now.
I must say I agree with a depth of field would do the game some good.
Just as a personal preference, I think I’d prefer the ship to make a more hasty movement with a greater feeling of tiles being used. Now, I understand people might say that it sounds unwise, but I think it would give a greater feeling of control.
Anyway, it’s a nice project and I hope you’ll keep working on it.
Thanks for all the kind words! Amazing what two 64x64 textures can do for a project
Check out the procedural examples in the resources section. Thats how I got started with editing / creating meshes.
I wouldn’t suggest it however, if you are still a scripting noob as you say. The best advice I can give you is to start with small, realistic tasks.
If you have any more questions please pm me so we keep this thread clean.
I’ve been thinking of a way to keep the frustration rate low as well. I wanted to go with a standard 3-life-model, but your suggestion sounds much better!
Did you register here just to post in my thread? I feel honored
The funky stuff in the background isnt intentional. I just havn’t figured out a way to get rid of it.
As for the controls - well thats something I keep on tweaking. Making the ship shift faster also makes the game easier. But seeing as its really difficult right now, I just might kick it up a notch. Thanks for the suggestion!
I played again and thought of two more interesting twists that might make for more interesting play:
other racers. Not necessarily multiplayer, but a number of other racers who are trying to get through the maze with you. Only one racer can get through a hole. Once a racer goes through a hole, it’s closed off.
multiple z-positions. Everyone would still be going the same speed, but if a status meter was full, they could accelerate further forward or decelerate backward along the path of the tunnel a few spaces (but would return to the default center position before long, so timing would be key). Then slowly recharge the status meter. The advantage to riding up front would be cutting off avenues for your opponents. The advantage to riding behind would be to have a bit more time.