Really obnoxious description, sub-par game.
I dunno, the concept of this game was novel in the first one, but with so many sequels, this game ends up as a pretty bad attempt to breathe some new life into the formula. The big problem is that the main new addition, the combo upgrades, is completely nulled out by the level design. You never have to make a decision about which to take and which to not take, because often they're all clumped together or unavoidable in a tight passage.
And holy crap, the description for the game is incredibly obnoxious. Saying "50 levels at a time, with 12 options" would make you assume that there are 600 levels. But, no, there are only a hundred levels.
And a year in planning, 8 months production? That's either bullshit or you work ridiculously slowly. The engine for this game would take a day or two to make. With the editor and whatnot, we'll say a week, tops, if you've got other stuff to be working on as well. And then there are a hundred levels...so you only make one level every 2 or 3 days? Come on. And how the hell did it take a year to plan this?
You've been making tiny little games for a long time, and these seems like pretty much the only large projects you make (other than the Four Second games). But all of the Ball games are practically the exact same game.
I love Float, btw.
I respect your opinion, but I have a few disagreements here and there. First off, yes, it really did take that long to plan the game. I had to make a bunch of tough decisions on what to include, and how to get to each of the level sets. It wasn't a straight shot like the previous games, you can see so in my whiteboard picture: http://www.jmtb02.com/wb2.jpg. Also, power ups were hard to come up with. It wasn't a sit down session with a final outcome of tons of power ups ready to go. It was really a "okay, what the hell am I going to do with power up A and power up B?" I wish it was that easy :).
Secondly, 8 months of production takes into consideration the fact that the engine had to be redone twice. I wasn't happy with the first one, and actually went to level 20 before scrapping the entire engine and starting over. There were many trials and errors made, and the production extended to backgrounds, level design, a huge engine, and core programming planning. I don't just sit down in one night and come up with these things, although I wish I could with this series.
I also had to take into consideration what people liked and disliked from the previous games. I really wanted to cater to the people who'll play this game multiple times, hence the multiple paths. I also had a lot of complaints about the length of the previous games, so I decided to shorten it down to a total of 50 levels at a time, which works out easier for people who want a shorter game. With that in mind, I was catering for two separate audiences: first time players and veteran gamers.
And with that, there were new features I had no clue how to program. I had to learn how to work with game-saving, a drag-n-drop achievement system, and an easy way to work with dynamic hitTesting of levels. I am not the most fluent programmer by any means.
As for being obnoxious, I apologize if that is unclear.
I couldn't quite grasp your last paragraph. It seemed like you were arguing that it was one of my only large projects, then you said it was the same as my other Ball Games. I just don't quite get it.
Anyway, if you want to talk about this stuff a bit more, go ahead and PM me and we can chat. I was a bit thrown off by the 0/10, which I am not sure why it was deserved.
It's okay, I guess.
Not really wonderful. Pretty bland...and the recording of your head didn't fit in very well.
Oh, and the random() function can return 0. random(4) is 0, 1, 2, or 3.
Oh. Your'e right. I'll have to fix that, then.
This kind of thing is a great way to get into Actionscript. For the final version, here are some things to work on (both to make the game and your ability better):
Improve on the use of hitTest()-use points on the character. You could, as an example, make the character's origin point right in the middle horizontally, and at the base of his feet, and use this code: _root.floors.hitTest(_x,_y,true); to find out if he is standing on anything. The only problem with using a flat hitTest() check is that it checks his entire bounding box, and when he's running, that box changes size. An alternative here is to use your original usage of hitTest(), but instead of checking for the whole character, check for an unchanging, invisible movie clip inside of him.
Add a jump animation. This is obvious, but I might as well mention it.
Length-I'm sure you're all over this, but again, I might as well mention it.
Good job with this one, and good luck with becoming awesome with AS.
I will probably keep it the same, or maybe make it check for an invisible box inside, I'm not really sure yet. I tried to add a jumping animation in, but I haven't quite got it yet, it goes gay everytime, but I'll get it soon. yes I'm all oer the length and thanks for the good luck, I'm pretty sure I'll need it.
It's good, but it could be fantastic.
I say that you should make a Krazy Kar 2, but do this first.
Look into rigid body simulation. That's what would make this game an ass kicker instead of just a neat little gizmo.
If this game was powered by rigid body simulation instead of its current method (which is pretty lacking, even though I feel bad saying it), it would be 500 times as fun. It would be a real challenge, though. Keep your chin up.
newgrounds.com — Your #1 online entertainment & artist community! All your base are belong to us.