This project won’t be developed any further
Project type: jme3 game
Status: in development
License: MIT
SVN: https://jpspj.svn.sourceforge.net/svnroot/jpspj/rollmadness
First Playable (v 0.2): rolling_tracks_0.2.zip
There’s a story behind what player does but i won’t bother you. The player is closed in a ball and thrown down a track (that’s were “Rolling” comes from). The ball is controlled only by pushing it left or right, for a brief time, with a limited amount of energy to employ (so you can move it like ten times during the session).
The player must reach the end of the track and shoot as many target as possible during the path.
Here’s a video of the first test. The red balls are power-ups test shapes. The green balls are target test shapes.
http://www.youtube.com/watch?v=rrc9EAV5Nwo
With a little care (especially on the visual side because the game in jme3 is probably no longer than 500 lines of code) it may become something funny to play.
given the idea factory that is your brain i can't wait to see what this will evolve into…
Juppee! Always a blast seeing upcoming jME3 games on the horizon. Like the SimpleFPS game and definitely like we’ll be doing for the ‘official’ jME3 game demo as well, do you think you could try document some of your critical steps in making this game, as reference for newcomers? Since you’re an early adopter and all, that would mean a lot.
No doubt you’re an innovator; definitely gonna be fun seeing how this game progresses. Already looks like a great KISS game.
An interesting idea could be to keep a development log as a collection of problems met and solutions found. I'll try to do that.
pgi said:Much appreciated :)
An interesting idea could be to keep a development log as a collection of problems met and solutions found. I'll try to do that.
Working on the menu. Well, working on the tools to create the menus. After some thinking, i decided to use… Inkscape.
Behold the SVG user interface :D!
Yes, my 2d drawing skills rival my 3d modeling ability.
The drawback is that Batik is huge (8 megabyte).
I’ve started the devlog, it’s draft and i suspect it is destined to become a very huge document, mostly because I’m using a lot of custom stuff, a thing that maybe will not make this document very useful to start with jme3. But it is funny to write.
Here’s the draft so far:
devlog.html
Test 2
youtube
I’ve finished to layout the game stage and ui framework, now i have to work a bit on the track models format (just naming conventions, the tracks are built with blender) and the game logic. Then i’ll start the titanic task of trying to produce some decent looking audio/video content (does anyone know where to find the sound of a gigantic ball rolling on different surfaces at different speeds?).
I like the way it bounces 
Is that custom code or are you using JBullet?
So you decided to make your own simple UI framework huh. Any particular reason why you opted not to go with Nifty?
Also, no more devlog? 
I liked the looks of the first draft.
Looks cool so far. The devlog was like a tutorial so its good to learn from it
pgi said:Okay, good to know these things so we understand what might make developers lives easier and such. From this, I take it once void finishes the Nifty Editor, your choice might've been different ;)
The custom ui is a fruit of the great balance of lazyness: the effort required to learn nifty (which is very cool btw) was bigger than the effort required to create a custom gui, mostly because I have both limited requirements and limited drawing skills. Being closely related to a sloth, i chose the first.
I found writing the devlog in realtime a bit unpractical because what i write become outdated ten minutes later. I removed the link because what was written there doesn't share but a few lines of code with the program I have now. I'll write something more coherent after the first playable (that I hope to post in a couple of weeks).Cool man, the effort is really appreciated. Though keep in mind, [publicizing] the mistakes can be just as important as the successes ;) I think that was explained very well in this Google Tech Talk - The Myth of The Genius Programmer.
Placing the avatar looks like an art of its own. I found a suitable technique after an hour of struggling.
A better avatar.
Well, not so better… I hate modeling :D.
The plan is to use the black display as the status monitor.
Good luck with this, it looks exciting… I'd suggest trying an ice material for the walls if you've got one… Can the player jump?
The player can’t jump yet but I plan to let the capsule be improved (better weapons, better handling, more shields, a jet pack and so on).
The visual appearance is in the hand of the artist, being me, being very very bad at modeling. A nice thing is that the game loads a scene entirely defined with an external editor that can export static scenes in a JME3 loadable format. I use a basic naming convention to parse it (what is called “player” is the player starting location/orientation, what is called “track” is part of the track, “wall” is a wall, “target” is a target and so on) so I’ll probably start crying for 3D modelers when the game structure is done - at least if i can’t produce anything that looks at least decent.
And the game structure won’t take much to be completed. I’m writing the particle engine, then i have to abstract out the capsule properties, put on place the pick-up logic, wire few things and it is ready to go.
Oook, i’ve lost one day for the particle system. Now I can spit little black balls (whoa). I managed to record the audio this time.
youtube
The test shows one bug (the energy amount isn’t restored after gameover).
Update. Another test, another bug (the first push direction is wrong)
youtube
Oh man, you could make this game so fiendishly difficult if you want to 
Nice job on the placeholder graphics, they definitely paint a good enough picture.
About the steering, are you planning to make any changes to it? I think the turning looks a bit unnatural, considering the player is in a big ball and all. I think it should, what's it called again, "give in" a little when you move your mouse too fast, and hold back on you when moving slow. Heck do I know about how you move a human ball around, but I think that'd feel natural to me.
As an example, there's the BattleZone gameplay:
http://www.youtube.com/watch?v=_Fff-1tFkpU
You'll see how it refuses to keep up with the mouse's exact sensitivity.
The ball's control requires a revision both from the user input side and the mechanical side.
As it is now, it doesn't work because the controls allow the player to slide along the (local) x axis and this also allow the player to push the ball forth/back if he rotates the view by 90
I did an unrelated experiment with ui.
It’s my beloved swing (actually a static print of a component written with the netbeans ui editor).
The other experimenti was this: the capsule of the player is put inside a bigger ball, that balls roll, the player “floats” inside. To render the effect i must simply put a bigger ball where the capsule is and use a transparent texture with some kind of grid-like image on it. The small problem is to synchronized the external ball rotation with the actual rolling on the playfield. I have to check if the PhysicsNode of the player rolls by itself (because of the friction) or not.
Anyway, the testable alpha is coming soon (i have to finish the menu and the logic that move the game from one track to the next if the goals of the previous track have been achieved).
GameStage loop done.
ends at 4:30 (don’t know why the encoder made it 13 minutes long)
Time for powerup and bonus logic, then i’ll build a couple of better tracks and i’ll release a playable alpha.
Well, it’s done. I tested the pickups, had to create a new one (the sprinter) to pass that loop:
there is a lot of work to do on the visual side. Anyway, the next goal is the tutorial. I’ve started it, here’s the pdf of what i have written so far:
rollmadness tutorial
I think I’ll need a couple of days to finish it.