I had this idea about a game that demands some spacial thinking to master…
So I started this project to see how far I’m able to push it:
The objective is to move a ball from a starting location through a kind of labyrinth to the goal area. You have got 3 fixed views to get an idea of the environment: x-ray views from front, side and top.
You move the ball around with the arrow keys: depending on the active view (“mouse over”) you can move in all dimensions.
The game already works, but there is only one test-level I made. Your time to completion will be recorded and that’s about it atm.
What do you think about my idea? Do you think it’s fun?
I guess some 3 dimensional perception training could be nice for all you blender heads
What I want to do nethertheless: #add several levels with increasing difficulty #add a title-scene to the game #add game instructions
What I should try: #load levels from external .blend files. --> custom levels created by anybody! #add some sound effects/ ambient music
What I may try: #2player version: race mode #3player version: one player per view (coop)
EDIT: There are newer versions of the game! Check the last posts in this thread.
I think the best option for ball movement would be click-and-drag (much more control and precision and speed), or at the very least let players use wasd, using the mouse and arrow keys is very awkward.
Interesting idea, i’d like to see where this goes.
@Josip Kladaric:
nice! once you get the hang of it it’s easy, isn’t it?
the ball speed isn’t final yet, I will have to check if higher speed will still be compatible with more complex levels.
@Captain Oblivion:
Remember that it’s 3D, so “wads” wouldn’t be enough and changing from one view to the next would be totally unintuitive, controlwise (e.g. different keys for “move ball left” in top and side view!)
So I decided to use just a 2D control, that depends on the view you have in focus. Therefor you will have to state somehow which of the three views you want to control with the keyboard keys (up-down-left-right). I used 3 different states depending on the mouse over section (left view window, center, right) to map the arrow keys to the different axis.
I still think using the mouse in combination with a 2d-control is best: the movement you will see in the active view will change according to the arrow keys you press.
As for click+drag: that would be too simple, wouldn’t it? you will just have to grab the ball, shake the mouse real fast and the level will be half done… I’ll stick to keyboard for now
WASD is exactly the same as the arrow keys except in a non-awkward place on the keyboard. You would still use the mouse to point out which view to move in, you would use W instead of up, A instead of left, S instead of down, and D instead of right. This is the standard control for pretty much any game that uses mouse and keyboard directional control (because the arrow keys are on the right side of the keyboard, it’s bad for your wrists and generally feels awkward to use your left hand, while your right is occupied by the mouse- or you lose time moving your hand back and forth between the keyboard and mouse. Obviously, this problem only applies to those that are right-handed, but that’s the vast majority of computer users.)
If you could beat a level by shaking the mouse, clearly the level was designed in a straight line, in which case holding down one direction would beat it too. that’s bad level design, not the controls being the problem. Mouse control would be the most intuitive, there wouldn’t be annoyance from how slow the ball moves, or if it moved fast how inaccurate it is.
I ran into one major problem, that is due to a blender bug; could need some help! :D:
I implemented level transitions as follows:
with space-key you remove the current level object and afterwards do an add-object of the next level which is stored on an invisible layer. Since the “add-object” (and “kill object”) would be easiest if only done once, I parented all parts of the level (start-arrow, goal flags, tunnel-model etc) to a level-cube (e.g. OBlvl_1, OBlvl_2, …).
Now the problem is, that I cannot control the player ball anymore, because it is parented to the level. If I do an “unparent” after adding the level object with all its children, the dynamics of the ball are not restored; that’s the bug (already commited)
Does anyone have an idea how to avoid this problem?
Another bug I possibly found (or is it somehow intentional?):
I use “space key” to trigger the actions described above. This has to be done once! automatically, otherwise there is no level at the beginning of the game. Therefor I added an “always” sensor to the “space key” sensor and changed the controller to “or”. This works nicely except for the fact, that the “space key” sensor now suddenly fires twice: when pressing the “space key” and also when releasing it. This results in 2-level jumps when pressing the “space key”
If I use the “space-key” sensor with an “and” controller, it only fires once.
So I had to wire the logic bricks the 2 separate “and” controllers, now it works as supposed to. But I don’t like it, I would like to use just one “or” controller for both sensors… why isn’t that possible? (I also tried an expression with “sens1 = true and sens2 = true” -> same problem)
New version of SPG below
-> [Not playable anymore, due to unparent bug]
-> 4 Levels available, switch with “space-key”
The dynamics bug should be avoidable if you don’t remove and re-add the player, but rather just set its position to the level start (since the player is a constant in every level, you can get away with this) just put an empty where you want the player to start, and then get its position and set the player there with python (and probably set its velocity to [0,0,0] too)
once you get the hang of it it’s easy, isn’t it?
