caveman pool

Just published Caveman Pool.

https://market.android.com/details?id=com.exit4.app.cavemanpool&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5leGl0NC5hcHAuY2F2ZW1hbnBvb2wiXQ

Check it out and please give a good market review- even if you don’t like it:)

Well, that was a bust

Just tried it and it’s fun :slight_smile: . But somehow I am not sure if the market thingie swallowed my rating. It’s acting a little weird on this tablet…
I somehow miss a more intuitive way to adjust aiming and power…right now it’s feeling little awkward.

Just stumbled over this, reminds me of your game :wink:

On aiming and power, I struggled with this a little. Other pool games initially use touch for gross aim (aim where you touch) and then use other controls for finer control. The issue with this is that because I wanted to use the whole screen for the game, if the cue ball was at the side or in a corner, you might not have room for the gross aiming part especially when my pop up menus were over the location you wanted to touch for gross aim.

My technique can be done anywhere, without your finger necessarily getting in your view and with a single touch to control gross aim, fine aim, and power. It is not that intuitive, admittedly, but when you get used to it, it works well. Note that I sense fast movements and accelerate the aiming for gross aim as opposed to slow movements which allow delicate aiming.

I am definitely going to improve the “How to Play” popup, adding aiming pictures, an ‘OK’ confirmation button, and a “Don’t show me this again” checkbox.

PS - thanks for the review!
[hr]

That’s hysterical! Thank’s for that.

I certainly see your point - technically it’s ideal but my first touch was straightly speaking very confusing. Some tutorial hints etc could improve that certainly.
The problem with the edges is in deed really bad - it makes a lot of interactions difficult and I understand your struggle. Thinking about this doesn’t give me many alternatives, but this is what comes into my mind:

  • Hybrid model: Tab and “pull” the white ball into the direction you want to shoot, use your current model if the white ball wasn’t pressed
  • Central control: allow setting the direction and strength by pulling the finger from the center. Direction and force is calculated from the finger position in relation to the center. Serious drawback: Finger might cover the important part of the screen
  • modified central control: User can pull a line anywhere on screen, direction and strength is directly used. Drawback: Lack of fine control, especially on small phones
  • Direction central control: show a “wheel” in the center, tapping on it sets the direction where to shoot the ball. Shooting force could be controlled by a power bar or so

My current frustration with the game comes really only from the controls - I want to play at a faster pace and more directly, but I simply can’t control it fast enough.

Just my point of view of course :)[hr]
Ah just something else: I see that your level is truly 3d - how do you import the 3d models and textures? And how did you do the physics?

After some more playing, here are two artwork points about the balls I notice: The Font you use isreally cool - it looks wacky and chiseled - why not using it for the ball numbers? The white spots on the balls are round - a little more whacky would also do good I think ;).
And at last - I would like to have the balls looking more stony - I wonder if you could achieve this by distorting the normals of the vertices a little…[hr]
I encountered a weird bug by the way where two balls intersected each other by about 40% or so without showing any kind of effect. Is that a known bug?

Thanks for your comments and brain storms. Your third approach, grab arrow and drag, was one I was considering, but the loss of fine control is an issue and also the potential for blocked visibility.

I am going to try a hybrid of your suggestion three and my current approach. When you touch the screen, it will be like you are grabbing the arrow, only translated. I will create a virtual “translated grab” location and a virtual “translated center” location. Rotate or stretch as above - just at a different location. Then, I can probably play games with either adjusting the “translated grab” location for gross control or adjusting the “translated center” location for fine control.

I may display a little dial on the touch, but I don’t think that is necessary.

Darn, my hope was that although the control was unusual, that the player would quickly get used to it. I am used to it, but I have obviously had to play A LOT!

It’s crazy but, it’s all my own code, rendering, importing, game object interactions, and physics.

I use freeware modeling tools with very simple old school model formats from Quake and Quake2. Walls and such are brushes imported from Quake1 .map format created in QUARK. Holes are models imported from Quake2 .md2 format created with Misfit Model 3D. Balls are generated programatically.

Physics is actually all 3D physics even though only 2D physics is required for this game. I originally wrote the physics for Lava Ball 3D which required 3D physics and have just re-used it since. The scheme I use for game object interactions is actually something else I am kinda proud of and originated in Rebound.

BTW, pool breaks are a bitch physics wise. There really isn’t any easy way to avoid the fact that breaks SUCK for causing iteration in your physics code. Lots of really short iterative collisions with big velocities just blow.

Ah, another purist writing lots of stuff on his own :smiley: - thumbs up and impressive ;). I am often asked why I don’t use frameworks (I do use libraries though, especially physics). And for physics, I know that iterations and high velocities suck (or, in other words, the stiffer the system, the suckier) :wink: (see http://www.youtube.com/watch?v=Em1ADpArHCo - I did that a couple of years ago using ODE physics, but in the end, I couldn’t make the racing stable enough at high speed - should have used raycast vehicle physics instead).

The pool table actually IS reminding me of a quake level somehow. I am missing some artsy/fancy texture shading though, but I somehow like your style because it’s consistently the same quality (artwise, consistence is more important than style & quality in my opinion).

Good luck with trying out a different control system - I know it’s hard and can be disappointing :(. I hope it works out.

Just confirmed a behavior that I am not sure of if it’s correct: In caveman pool play mode, if I get a scratch, balls that were incorrectly dumped are not put back on the table, otherwise they would reappear. Is that supposed to work that way?

Thanks. Fixed and will include in next market update. I never realized how hard it is to intentionally scratch and sink a ball at the same time:)

EDIT - Another Caveman mode bug is that if you exit while in green or blue state, the game doesn’t restore your state correctly on the resume. Your first shot is basically taken in the Red state even though there are no red balls, giving you a guaranteed miss. It corrects after that, but still. Damn! Anyway, I fixed this as well for the next update.

Another update for Caveman rules is that if you sink the last ball in a state and sink balls from the next state in the same shot, I should leave those down.

Good idea. I just tried it. Works pretty well. A kinda bump map effect. It was a bit dithery though. I need to tweak it a bit. I’ll probably keep it very subtle.

I have seen this infrequently on the break. Did I mention that the break sucks for collision detection yet:) I haven’t really tried to track to too hard yet.

I am more concerned about a very occasional ball through a wall bug that I was getting before. I put in a fix for it, but it was so infrequent that I don’t know if I found the problem or not. This is a bigger concern because it actually breaks the game when the lost ball becomes unplayable and the game logic still thinks there is a ball around. Basically, current game ruined.

EDIT: Also keep your eye out for any balls that seem to be elevated off the table. I had some issues with accumulated imprecision in my 3D physics causing the balls to acquire velocity/position in the Z axis. I think I fixed these problems by clearing any Z axis velocity every frame, but if you see it let me know.

Update.

Not a bad first week. The game has 623 total installs and 265 net, but since net is lagging total by a couple days, I think the net is something like 75%, which is great!

While installs are good, what I am really happy with is the admob stats. They have been growing every day. Yesterday I had 871 Impressions on what I estimate to be about 400 net installs. That means people who have it installed are actually playing. From those impressions, I made a buck yesterday on 27 clicks. This is a good start, but not fantastic.

I think the fact that people are playing is a good sign for my next step. In the next couple days I am going to release and upgrade in-app purchase. The upgrade will give you ad free, nine ball, eight ball, seven ball, and two player versions of each of these along with some new table themes. I am selling the upgrade for a buck fiddy. I am excited to get this done and see how it does. Right now expectations are high, but we shall see.

When the upgrade option is in, I will hit up some sites to try to get reviewed.

Regarding aiming, I have tried other techniques and continue to fail. I think I am going to keep this for now, considering that it seems like people are playing, I don’t want to rock the boat by putting in more f’d up aiming.

Regarding the ball texture idea in this thread, I put it in and it looks pretty cool. I am adding an option for the player to select the amount of ball texture, either smooth, stoney, or rocky. Seems to work good.

Regards,
Charlie

Just released a new version which supports upgrading to the full game and I sold an upgrade! ONE!

<edit> 13

Woop!

I’ve got a soft spot for this as I wrote something similar as part of a thesis at uni. It’s a great vehicle for work on rigid body physics simulation (in no way chosen because I wanted to spend my time in the bar claiming I was doing “research”).

Anyhow, had a quick play around this morning and I’d throw in the following suggestions for change:

  • Needs some visual feedback on pressing the menu buttons. OK, I’m willing to accept there may be some audio feedback, but I’m still playing things with not sound. Maybe a highlight when the finger is pressed on a button?
  • I like the approach to the “edge controls” issue, but I agree with zet that it’s not initially intuitive. This could be quickly solved by having an overlay on first play that just scribbles the control scheme on the screen (including a note about how to add spin - I had to drill into the instructions to find this out).
  • On the subject of spin, can you make it (potentially an option rather than a default) a two step process? i.e. position then shoot. At the moment you can use a two step process to be accurate with your shot, but not with spin.
  • For the shot strength, is it linear and is there a maximum and minimum? At the moment the arrow doesn’t really give me the feeling that I’ve got a good level of control. One option might be to also give colour feedback (i.e. the strength of the shot changes the colour between green and red.

Very pleased to hear you’re doing the physics yourself. Multiball interaction for the break is indeed a real problem. Somewhere you have to compromise, whether it’s on the accuracy of your single ball collision (e.g. faking the collisions with springs on overlap to calculate the forces) or by just assuming that you’re not going to see the problem that often (tbh, it’s only really the break where you’ll see the multi-ball problem).

Overall though I really enjoyed it. As I said, once I was used to it I liked the control system. Nothing worse than a control system that messes with you when you get objects into a certain position (edge of screen, near buttons, etc.). Presentation style is good and the gameplay just works.

Thanks for the post and the good comment on the Market. I can always use those:)

Good idea regarding faking collisions with springs on overlap. I hadn’t ever heard of that. The problem I have always had with simply detecting the overlap is what the heck to do about it. Changing object positions is never something good/easy to do in a dynamic collision system. But, I could just check for the overlap and, when I see it, apply some velocity to resolve. Checking for overlaps is lightning quick, so this is something that I could do every at the end of every object Move() function. Easy to test to. Create a bunch of overlapped balls and watch them scatter:)

Regarding spin, I currently like that it is not accurate because, to tell you the truth, my ‘spin’ physics are all BS. I don’t even know the physics of why spin works:) I just made some stuff up. Like, with topspin the cue ball acts heavier and with backspin the cue ball acts lighter. If I give the player a sense of being able to apply absolute control to his ‘spin’ shot, then I will really need to dig into the ‘spin’ dynamics more. For now, I don’t really want to be accurately simulating masse’s and curve shots.

Face it, cavemen didn’t know how to masse.

EDIT - come to think of it, that is why I settled on calling it Caveman Pool. It excused everything that was inaccurate that I was doing. Big balls, tiny table, using rock textures, some made up rules, etc. I wanted to be able to distance myself from too many pool purists. They wouldn’t like the game anyway. “Caveman” gave me an immediate out!

Thanks
Charlie

Heh. Fair enough. I’ll just keep in mind the word “ug” when I’m playing and everything’s excusable :wink: If I have time at the weekend I’ll see if I can find the old code I wrote for the multi-body problem … it must be on some hard drive somewhere. The spring approximation is just the easiest one I can remember that gives a convincing looking result. I also own an old book that covered a load of studies of billiards physics but I think it may be stuck somewhere in storage. If I do find it I’ll try to get some useful info to you - even if you don’t implement it it’s all good material for the next game :slight_smile:

For those interested: Gamasutra has a good tutorial as well.

It doesn’t cover how to organize your looping for collision detection, but it does give all the math for simple sphere/sphere collisions and reactions in a really easy to understand format.

Learn that and Quarternions and making a pool game is easy.

New version. Added a simple global leaderboard. Added menu music. Fixed a major bug in the billing process that made restore transactions fail.

I now have 12 upgrades in six days, or two a day. I am making >$1.50 a day on ~2000 admob impressions plus two bucks in upgrades makes $3.50 a day for a relatively new app. Not bad.

Now that I have the in-app upgrade figured out, I think this is definitely the way to go rather than the free/paid model. Managing a single app is so much easier.

Now, on to the next game.

Regards