Please don't. JRE (and plugins) is a huge annoyance for users. You may want to look into JS and the HTML5 canvas instead. There's plenty of material available for that. Just google HTML5 game development and see what comes up.
Let me analogize this: You're suddenly asking if it's possible to make a car more efficient by removing the wheels.
You can play around with the loop, but there's no reason to. It's already possible to surpass human limitations for responsiveness. If you're handling input sanely and your frame rate is high enough that the player can see what's happening then the only really good way to screw up responsiveness is to render several frames behind or possibly to just have a crappy control layout. Control issues are usually related to poor game design or implementation issues with things like colliders not matching models or sprites. Networking tricks can also cause trouble if they're implemented incorrectly, but these are all cases where the output is not correctly representing the game state rather than cases where the rendering or input is not being handled fast enough.
At 60 FPS the game is presenting you information every 16ms or so.
Even if you float a frame (so that the CPU and GPU can work better in tandem) you only lose a little temporal fidelity. Stretching beyond one frame becomes a timing issue, but 0.016 seconds is barely even detectable, especially for fast moving objects.
Moreover, you're talking about a 3-stage process that loops. Your options are limited here:
But then when you consider that they're looping:
ABC == BCA == CAB
ACB == CBA == BAC
You've only got two options. Treating rendering as the divider you have input-update or update-input.
If you're polling then default to polling before updating because it makes sense to respond to input when you have it. If you're on an architecture that will delay on polling then you may consider moving it to after updating depending on how much time your GPU is taking compared to how much time the CPU takes.
On the other hand, if your input is handled by something similar to messaging then you don't even have to mess with it as updating includes processing queued inputs.
Regardless, even if you poll in the 'wrong' order you shouldn't be able to detect the difference without instrumentation.
tl;dr - If you want your game to feel responsive focus on precise collision and well designed character reactions instead.
Ignorance is not a resource. If you want progress then inform yourself about the problem space and learn why others have done what they did to deal with it.
More to the point, why are you writing an engine if the features are things that you can get from other places? What is it that you actually want to accomplish and how is this the most effective way to get there?
Do you really need a vector of pointers? What do you mean by, "popping in and out from the stack"?
Hmm, I was thinking that I'd rather have the child nodes in the heap instead of the stack so I can control them manually? I don't want them to be destroyed immediately unless I tell them so, which I guess that's what will happen if I put in the stack and they went out of scope or erased/removed? and there will hundreds of nodes allocated, and I don't want to mess with the stack memory for this one? Please correct this lost soul if he's mistaken.
It sounds like you're getting ahead of yourself a bit. Vector allocation is already on the heap, but I don't think this is a heap/stack issue. It sounds like you want to do something unusual with lifetime management. If the 'node' is a POD then just use vector without pointers. The indirection you're introducing here is going to make iterating the vector very costly for no reason. It sounds like these objects have destructors though? I kind of want to know what's going on here, but even in that case you'd probably be better off doing manual mark and sweep if you need delayed destruction (why?).
Well, right up front it sounds like you're just using the wrong container, but setting that aside it sounds like you're taking a naive approach to spatial sorting. What are "chunks" here? Do they move or change in any way?
Why is near-to-far sorting helpful? Do they really need to be in perfect near-to-far order, or can you just throw them in "really close", "close", "not so close", "far" buckets and go from there?
Like Briandigitalis points out, a small or single person team can't afford to hire all specialists (business, Artists, Extra programmers) required. I wish I can hire all the business-risk analyst, but for obvious reasons I can't afford to do that. So the next thing to do is to improvise which is do most aspect - meant for specialist - on my own
You don't need to hire someone. You do need to have someone with the skills required to do what you're doing. I'm guessing that you have at least one programmer around the place, since you're doing programming. Well, if you're conducting business then someone needs to understand how business is conducted.
Risk analysis is one of the major areas of study in the field of project management.
Commonly risk is measured systematically by breaking the project down and trying to list all of the potential setbacks and points of failure, along with a cost and probability for each. You then multiply those cost values by the probability of the risk. High values are risks that most need to be avoided and/or mitigated.
Unfortunately, getting accurate values can only be accomplished through experience. If your organization doesn't have a history to draw on for this then you have to look to similar organizations and try to get data that can be used to make reasonable estimates. This also applies to scheduling. You can make guesses, but they'll almost always be too short. The most reliable way is to base your estimates on data from previous projects. (This falls under the heading of "scope management".)
In any case, this is work for a project manager and not necessarily a programmer. If you're in a fully agile environment it's possible (though unlikely) that you don't have someone with these skills, so that's worth looking in to. If you're interested for your own sake then you may want to poke around for an introductory text on project management.
Okay, so you're simulating a curved surface. Let's try a cheap method first and see how it works.
IF the ball is in contact with the paddle AND the ball's motion is toward that paddle's end of the board (left paddle while moving left, etc)
negate X speed
find offset distance from center of paddle: center of paddle is zero, top and bottom are negative and positive, depending on which paddle (more on this in a moment)
add that offset to the angle of the ball
The idea is like this:
45 may be a little too steep, so use a const variable for that value so that you can change it later. Basically you want to do what's called a LERP, or "linear interpolation".
When you deflect you start by finding the Y distance between the ball and the center of the paddle. You divide that by the distance between the center of the paddle and its extremes to get a normalized ratio. Then you multiply that by the maximum deflection angle to get the angle to deflect at. Remember to flip the X speed first, and remember that the right-side paddle will need to have its angles reversed.
Walking through this, let's say that the ball is moving at 150 degrees (down-left). The paddle is 100 units tall. The center of the paddle is at Y:150 and the center of the ball is at Y:190. (This is the left-side paddle.) You detect that the paddle and the ball are touching.
The ball is touching the paddle AND the ball is moving left, so we trigger the collision response: