Show HN: Teapong – A two-player game for fans of Pong and the Utah teapot

I would say that it is.

I think that the idea of having each state be its own class is very natural, and that it helps organize the code very effectively.

My failure was in how I made those classes share many components that they shouldn't be sharing, thinking that this would make things more efficient without any proof to support that.

So even though my code uses global variables implicitly, I still think the pattern I used for game state management makes it more organized than an implementation where everything is global.

I hope this answer your question :-)

That's a question that I'm still asking myself :P

Here's an example of what's wrong with my state management system:

- Let's say that state A places the teapot at position X.

- Now let's say that we need to transition to state B, where the teapot needs to be placed at position Y.

- Since both states share the same teapot, and since the teapot stores its own position, it's as if its position is a global variable, so both states needs to maintain variables external to the teapot where they store its position.

Now imagine the same situation, but with dozens of different variables. It makes the code difficult to understand and maintain.

One way to fix that problem is to give each state its own teapot. By not sharing certain objects between the different states, the code is simplified enormously. But I made the decision to share things to reduce memory usage.

When I come up with a solution that I'm satisfied with, I'll leave a comment here!

This looks like you just took pong and glommed some 3D models on it, and the physics isn't really that interesting - especially when you consider all the different reflections and angles that the spout and handle of the teapot could provide, were you actually doing surface collisions rather than a bounding circle ..