Sorry your browser is not supported!

@tiresius
You're welcome. Also I was impressed but your catapult idea.


I didn't noticed any bounce effect I think it must give ball constant recoil power, so ball will be eternally jumping to certain heght when on the pinky.

@tiresius: When it comes to playing around with gameplay constants (player mass, accelleration etc.) I'd recommend watching this talk by Bret Victor: http://vimeo.com/36579366

The idea of manipulating the constants on the fly with immediate feedback is extremely helpful and probably worth the effort. For instance you could add a few simple mouse-controlled sliders in your game temporarily to vary the values. Just a thought.

Tweaking physics is so time consuming. You could spend hours adjusting motion and bouncing properties. Slider controls is a good idea that I implement all the time. If not sliders, at least an INI file which loads properties during program launch or restart.

I've been thinking about this feedback a lot. A LOT. I apologize for the long post but I feel the need to explain.

There are several reasons why the ball physics are the way they are. The main reason is I wanted a similar feel to Marble Madness from which this game draws its inspiration from. That type of marble doesn't really bounce, it drops heavy, and is not fast going up ramps. It is not controllable in the air (like Super Mario, or other platforms), where you jump or where you get tossed is your trajectory.

A second reason is I am using Newton Physics engine and this entire game started with Walaber's initial "Demo1.dba" file he put out 9 years ago. That used omega forces to "spin" the ball around. The ball is actually rotating itself with a force, like a hamster in a globe. This is a reason why the ball spins so much on ice. I could clamp the angular velocity to not make it go that crazy, but I never tweaked it.

By using omega forces, in order for the ball to "grip" the tiles properly and not slide all over, it needed to be relatively heavy. It is heavy, with the ground having a low elasticity, high softness, and high friction. This prevented the marble from "spinning" on the tiles, and it looked the way I wanted it to. Even with the way it is, you can still see the marble "stutter" a little bit when an edge gets loose and the marble spins faster than it should. You also see this when the marble goes slightly airborne onto a descending ramp, or when you try to skid to a halt after moving quickly.

The physics have been this way for such a long time, I was comfortable with them. I don't much like the marble games where ball control can continue in the air. I also don't like marbles moving too fast by default and whipping around the level too quickly. Games which allow that usually have ball control in the air to compensate when things get crazy. The marble would move at a consistent speed, and require the need to outsmart enemies that are faster than the player.

Last release (January 2011) people complained about how slow the game was, so I sped the simulation up by 30% and made the camera more responsive. That seemed to help, but it sounds like people still don't like the physics. This is a hard thing to hear for the creator of a physics-based platformer !!

So I've thought about this a lot, and particularly what changing the physics model means to the game. I still think I can accomplish what I want with a "push" model instead of a "spin" model. I can make the ball lighter, make it so the pushing force from the player doesn't work as much in the air, and adjust all the mechanics to follow suit with how it should look.

I can adjust the bounce of the railings with a single line of code. I will have to adjust ice to be "something" different, and make it so it is still slippery enough but not be annoying.

I have to think some more about making the moveable objects, or anything besides the player, beholden to the forces such as fan wind and other widgets in the game. I think boxes would be important for blocking wind and other uses, but perhaps planks/sticks/balls can be pushed about (?). The same concern goes for enemies. I can barely keep an enemy AI from falling off the edge, I doubt I can make it smart enough to counteract any forces it finds. But I understand the leap it takes the player to recognize that only they are affected by the physics in the game. It cheapens it.

Not having objects reset after a player goes to a restart point is bothering me as well, and I'm still coming up with a way to get that working properly. It will take some work but I think it is necessary for the game to do so. Mr Kohlenstoff, I asked you a while ago how you did it for Doyle, and I still have that information handy.

I've never been happy with the bounce effect (I don't know what you are seeing MrHandy, it should at least be bouncing), it is still erratic and the bounce angle cannot be counted on in a predictable way, because I've left everything up to the physics engine and tried to intervene as little as possible. But I believe I will have to do the bounce effect manually, and that will take some coding to get it right.

I've been around the block long enough, so you don't have to worry about me tweaking values in code over and over again. 7800+ lines does not compile quickly. I already have a config.dat file, and I will be porting all my constants related to physics behavior to this file so I can easily tweak and then rerun the game at least.

A lot of changes coming, I'll try to get them out as soon as I can... before people forget about this game again.

Thanks again for your feedback. There is a good chance the new physics model will "break" the current levels, but feel free to make some and share here if you wish.

You should play around with Newton tweaking, that's all I wanted to say.

Also, I'm not sure if you actually need to change too much. Shouldn't there be a way to stay with the current physics system and change parameters in a way that the game is sped up a bit? Even if it is just "multiplying all forces by 2".
On top of that, this was just the opinion of very few people. Before making big changes to the game you should maybe gather more feedback than what you've got here throughout the last few days.

When it comes to the ice tiles, you could probably avoid problems by just not placing any respawn points on top of ice, I guess. Because the ice itself is fine the way it is, given that it is used well in a level.

Your previous post sounded very frustrated, and I think there's no need for that. The game is fine, it is fun, has some very nice elements and looks good. It seems like you're very close to a quite cool, high-quality product which just needs a bit tweaking here and there.

No updates so far?

Hello everyone!

Thank you all for your support and interest in this game. It is with a heavy heart and a heavy mind that I've decided to shelve Marble Maze Construction Set, at least for the time being. (And I apologize for the long post...)

I do this as a hobby. When a hobby ceases to be fun any more it is time to step back and re-evaluate the situation. Truth is, for the past 12 months the work on this game has become just that, WORK. Over that time I've avoided making steady progress, lost myself in other creative pursuits, and found I was no longer excited about this game. In a sense, this game became a burden. It was a weight on my shoulders, with me feeling I was eternally locked into this project, mostly due to its long history of development (older than my oldest child), all the ups and downs during development, and the scope of what was left to be done.

There are several reasons why so many long term projects on this forum (and I'm sure many others) linger and do not get finished. One of them is: it is extremely hard to maintain momentum on something so big on your own.

If this latest version of my game had received a "Geisha House-style" following and interest, I could see feeding off of that excitement and perhaps another half a year of effort getting squeezed out of me. But there is far more than that needed to get this game done.

As stated in the first post, I bought DBPro over 10 years ago to make this game (initially a 2D version of it). Through the hard work of many others, I got as far as I did by using a great 3rd party physics library and other extensions of DBPro that I could not do without. The language was also a welcome break from my early pursuits of trying C++ / DirectX SDK and others like Java+AWT. While some limitations have always bothered me (no arrays in UDT's) I enjoyed the language and felt comfortable in it, like going back to my old QBASIC days. I will always be grateful to TGC for re-opening the door to game programming, which I was worried was closed forever with my frustrations from other languages. I have become a much better programmer over the past decade, and comfortable with a wider variety of languages and coding techniques.

The future? I am going to get back to more manageable and smaller projects that I can accomplish in a reasonable timeframe. In doing this I hope to get back the love of game programming, and get excited about the hobby again. For me, that means creating more simple mobile and flash/web games. I've evaluated the TGC and Blitz products in this area and, based on where I am now as a programmer and my interests, I will be pursuing the latter.

Thanks again for your interest in this game. If you've read this far, thank you also for listening to this old forum-goer. I will still be lurking on the forums and keep tabs on the other WIPs, and of course whatever TGC is doing (be it AppGameKit updates or the upcoming Darkbasic Elite). I wish you all great luck and success on your projects and I hope your dreams and desires for game programming are fulfilled to the greatest extent.

Good point. Without some form of positive public pressure it can sometimes be hard to stay motivated, especially with a project of that scope. I had the same problem with Dangerground, so a year or so ago I had a discussion with my partner and we came to the conclusion that stopping it alltogether is the best solution.

It is quite sad that your MMCS has been terminated now, it was one of those somewhat simple yet well executed and fun games. Building maps and sharing them here was fun as well, I really think more games should allow that.

So, whatever it is that you'll ultimately end up doing, I wish you good luck with it.

Aw man.

Well, thanks for letting us know instead of just dropping it silently! This was a great project and while it's unfortunate you're putting it on the back burner, at least you showed your dedication the whole way through!

i find that after code gets to a certain length that it is hard to keep track of every single bug. I guess that is what separates good programmers with great programmers. I think that if people on these forums programmed the way they do know 15 years ago they would be making a fortune. That is because more people know how to program, and there is more people out of work. I turning my love to program to teaching know, this is the only job I liked and it is very fun to teach kids concepts that will make them wonder endlessly through code not really being a coder.

I think it has to do a-lot with luck also you can suck at programming and still make a killer game.

Thank you for the well-wishes.


I don't know about making a fortune but I definitely would have made less mistakes and wasted less of my time chasing after corrections to those mistakes !!

It is true that a big project can get away from you with bad coding practices. I tried from the beginning to make my code as modular and as extendable as possible because I knew a game like this would have a lot of moving parts (no physics pun intended). I don't think that ended up happening here. I think it was motivation, not implementation, that resulted in this.

Something I found helpful was sharing as much code as possible and, more importantly, #constant definitions and UDTs between the game itself and the editor. This was the makeup of my source code:


Also I coded my game logic using Finite State Machines because they are easy to extend and fairly straightforward to use. Here is what the "game engine" logic looks like at the highest level. A lot going on in the functions but I think someone not familiar with the game itself can still see the flow.