Develop Reference

Basic game logic/ai design

I'm currently working on my 2D game project (Java), but so far any kind of game logic or AI has been crudely implemented. For instance, say I need to randomly position a bunch of sprites a long the top of the screen, I'd be using the Random class to do this. I'd simply use Random.nextInt( size of x axis on which to spawn ); Although this does work I'd be interested to hear how I should really be going about this kind of thing.
As a second scenario (this is why I put AI in the title, although it's not really AI), say I want to have my characters randomly blink in a life-like fashion. What I'd do here is use the Random class to calculate a % (say 20% chance) of blinking and call it every second.
Any suggestions on how I should really be going about this would be greatly appreciated.

Google for a paper titled "Steering Behaviors" by Craig Reynolds. It address just this and you'll find great ideas to start with specifically some nice ideas for giving groups of sprites the appearance of 'intelligent' movement. The key for him in his different behaviors, i.e. flocking, etc. is making properties of any given sprite dependent on those of some other sprite. You could even go so far as to say, like -- any given sprite will blink only if it's two neighbors just have blinked. Something or other along those lines.
Hope this helps!

Are you using an OOP (Object-Oriented approach)? If not, you should definitely look into it. It's really simple with java and can speed up your development time and neaten your code.
I would make a sprite class, and give them a function, say actionSpawn, or actionMove (I like to start my "action" functions with the word action so they are easily identifiable). In this function you would encapsulate the Random.nextInt function, to set the sprite's x and/or y position.
You could use the same approach to make them blink.

GTA2 like Car Physics, but extremely simplified

Okay so this problem has been bothering me for the longest time. Can anyone show me or point me to an algorithm that can control a car like that of GTA2? After 3 days of research all I could come up with was all of these algorithms for using pivot and joints on the wheels and separate wheels and such. Is that the only way to achieve simple car movement like that of GTA2?
I want to be able to use the algorithm on a rectangle without wheels but still be able to have the car drift. Is that possible? By the way, I am usign Box2D for the 2D game.
I know this is more suitable for gamedev but for some reason I can't post questions .

A simple answer that can turn into something quite big so I will try to explain by presenting different points in an increasing order of sophistication. I will be assuming a basic knowledge of physics.
Assume a fixed turning radius (not too bad if you are using a keyboard, quite annoying if you have an analog controller). Nothing like trying out different positions to find out what radius feels good.
Assume that you have wheels that are initially facing forward and as you press the turn key they progressively turn to the maximum possible. This basically means decreasing the radius from infinity to your smallest possible radius (you can figure out the relationship between the angle of the wheels and the radius easily). If you have an analog controller then the radius should be controlled by the continuous values of the analog input.
Let the forces enter! When you are turning in a car, you only turn due to a centripetal acceleration. That centripetal acceleration is caused by a force which is actually the friction of the car with the road. You can consider the friction a constant and the mass of your vehicle constant without major problems then you have a relatioship between the velocity of the car and the critical radius (the minimum radius you can turn given the velocity). The centripetal acceleration is a=v^2/r = Friction/mass so the critical radius r = v^2*mass/Friction. You can consider that no matter how much you turn you vehicle will drift and, at maximum, describe this curve. This should give you a nice simulation but still not the "losing control" feeling. For this see the next point! circular motion
The theory is exactly the same as in the point before but the main thing is that Friction in reality is not constant. In fact, the static friction will always be higher that the kinetic friction. In practice, you should have a static friction and a (smaller) kinetic friction. You calculate r according to the static friction and when your velocity is too big to achieve that r (this is when you would drift) you start calculating the new r using the kinetic friction. This will give you the losing control feeling but the vehicle will still not spin. Friction
In order to see the spin, you would have to consider the forces applied in every wheel (it is the fact that the different wheels are under different forces that makes the car spin) and consider some more advanced physics such as which wheels are the driving wheels and also consider the kinetic friction not a constant. However I believe this is out of your scope.
Alternatively you can do something that GTA2 seemed to do. The moment you know you are going to drift or are drifting too much (you set a threshold here) just programmatically make the vehicle lose control and spin.
Hope this helps, if you have any specific doubt just ask.

I found the http://www.banditracer.eu/carexample/ demonstrated a simple example for using Box2D to show car movement. The http://www.banditracer.eu/ has an open source game that you can observe to see if it has the drifting movement your looking for. You can check out the code and see how they handled the drifting movement and do the same for your project.

Jumping and standing on objects in 2D game

Im making small 2D game and i would like how should, theoretically work jumping and standing on objects.
For jumping should there be some kind of gravity?Should i use collision detection?
Good example of what i want to undestand is jumping in Mario.

I think for jumping it would be best to create some simple model which use "game time". I would personally create some physical model based on gravity, but you can go for whatever you want.
If you want your character to "stand" on object, you will have to create some collision detection. Good start is to approximate object by one or more circles (or lines) compute collision of them and in case the approximation collides determine the final state by some more precise method.

In terms of should there be gravity and collision detection - personally for such a thing I'd say yes and yes! It doesn't have to be complicated but once you have those things in place the pseudocode for the "main loop" becomes relatively simple:
if not colliding with object underneath, apply gravity
if user presses jump key and not colliding with surface //i.e. if we're in the air already, don't jump again
apply upward velocity
That is of course oversimplified and there are other corner cases to deal with (like making sure when you're coming down after jumping, you don't end up embedded or potentially going through the floor.
You might want to take a look at Greenfoot which handles a lot of things like all the Java2d stuff, collision detection etc. for you. Even if you don't stick with it it'd be a good platform for building a prototype or playing around with the ideas talked about.

Standing on objects implies collision detection, you can approximate the characters and the environment objects with primitive shapes (rectangles, circles etc.).
To check if to shapes are colliding, check axis one by one (X and Y axis in your case). Here is an explanation of the "separating axis theorem" (Section 1).

Flocking boids behaviour problem

Yesterday I came across Craig Reynolds' Boids, and subsequently figured that I'd give implementing a simple 2D version in Java a go.
I've put together a fairly basic setup based closely on Conrad Parker's notes.
However, I'm getting some rather bizarre (in my opinion) behaviour. Currently, my boids move reasonably quickly into a rough grid or lattice, and proceed to twitch on the spot. By that I mean they move around a little and rotate very frequently.
Currently, I have implemented:
Alignment
Cohesion
Separation
Velocity limiting
Initially, my boids are randomly distributed across the screen area (slightly different to Parker's method), and their velocities are all directed towards the centre of the screen area (note that randomly initialised velocities give the same result). Changing the velocity limit value only changes how quickly the boids move into this pattern, not formation of the pattern.
As I see it, this could be:
A consequence of the parameters I'm using (right now my code is as described in Parker's pseudocode; I have not yet tried areas of influence defined by an angle and a radius as described by Reynolds.)
Something I need to implement but am not aware of.
Something I am doing wrong.
The expected behaviour would be something more along the lines of a two dimensional version of what happens in the applet on Reynolds' boids page, although right now I haven't implemented any way to keep the boids on screen.
Has anyone encountered this before? Any ideas about the cause and/or how to fix it? I can post a .gif of the behaviour in question if it helps.

Perhaps your weighting for the separation rule is too strong, causing all the boids to move as far away from all neighboring boids as they can. There are various constants in my pseudocode which act as weights: /100 in rule 1 and /8 in rule 3 (and an implicit *1 in rule 2); these can be tweaked, which is often useful for modelling different behaviors such as closely-swarming insects or gliding birds.
Also the arbitrary |distance| < 100 in the separation rule should be modified to match the units of your simulation; this rule should only apply to boids within close proximity, basically to avoid collisions.
Have fun!

If they see everyone, they will all try to move with average velocity. If they see only some there can be some separated groups.
And if they are randomly distributed, it will be close to zero.
If you limit them by rectangle and either repulse them from walls or teleport them to other side when they got close) and have too high separation, they will be pushed from walls (from walls itself or from other who just were teleported, who will then be pushed to other side (and push and be pushed again)).
So try tighter cohesion, limited sight, more space and distribute them clustered (pick random point and place multiple of them small random distance from there), not uniformly or normaly.

I encountered this problem as well. I solved it by making sure that the method for updating each boid's velocity added the new velocity onto the old, instead of resetting it. Essentially, what's happening is this: The boids are trying to move away from each other but can't accelerate (because their velocities are being reset instead of increasing, as they should), thus the "twitching". Your method for updating velocities should look like
def set_velocity(self, dxdy):
self.velocity = (self.velocity[0] + dxdy[0], self.velocity[1] + dxdy[1])
where velocity and dxdy are 2-tuples.

I wonder if you have a problem with collision rectangles. If you implemented something based on overlapping rectangles (like, say, this), you can end up with the behaviour you describe when two rectangles are close enough that any movement causes them to intersect. (Or even worse if one rectangle can end up totally inside another.)
One solution to this problem is to make sure each boid only looks in a forwards direction. Then you avoid the situation where A cannot move because B is too close in front, but B cannot move because A is too close behind.
A quick check is to actually paint all of your collision rectangles and colour any intersecting ones a different colour. It often gives a clue as to the cause of the stopping and twitching.

Text-Based Java Game

I need to make a text-based RPG game with java. The first part of the assignment is super simple. we just use vertical lines and underscores to make a little rectangle and then add symbols inside the rectangle as things move, act, die, etc.
I've never done this before, so I want to run my idea by you:
What do you think about doing something like angry birds but with flying moving targets? There would be a little "bird tank" at the bottom left of the screen that would shoot birds. Another question: I'm not entirely sure how I would create a gun that shoots at different angles in a text-based format. And how would it work with aiming and shooting and timing, and such?
Update:
I think I'm going to try out a tank game. But I'm confused about how to implemenent the angle of the turret.
I would put the tank in the bottom left corner, put I only have text symbols at my disposal. I don't see how its possible to let the user control the turret, and make it move up and down by small amounts (at least, not until we start using images/gui's.)
Any ideas?

First, in order to make your idea meet the criteria of an RPG, you would have to add a few components. Your gun would need to gain experience as you hit your targets, and would have to level up after enough time. It could gain better speed or accuracy. It could also earn upgrade points that you could spend on different birds to shoot. It would probably also be cool if your targets had hit points and you had to hit some of them multiple times to kill them. You could show the damage by changing the color of the text. These elements will give it more of an RPG feel so that you can meet the criteria of the assignment.
As for the mechanics of the game, you're going to have to write some sort of physics engine. It doesn't have to be very complicated, just enough to be able to calculate or modify a trajectory and determine if there was a collision. This engine would have some sort of a tick() method on it where it would advance the positions of the birds and targets and then you could call a getCollisions() method and handle each one. That's the simple way. The more complex way would involve giving the engine its own thread where it runs constantly, as fast as it can. Then, when there is a collision, it fires off an event to a listener, and you set up some sort of handler to apply the damage to the target, award points, etc.
I would recommend you model the world in finer resolution than your text console. Make the text console simply mark the birds and targets by rounding them to the nearest 80x25 console location, but internally use a much higher resolution. This will keep it looking more realistic, even in an environment with such a poor resolution.
For the controls of the game, I would recommend putting a target reticule on the screen. The user can move it around with their arrow keys to aim and press the space bar to shoot. They wouldn't hit the target because gravity should pull the bird downward, or perhaps because the bird is a special shot that splits into pieces. Regardless, they would learn how to lead their targets appropriately, and that would be the skill of the game.
It's a complicated project. Good luck!