You should start making games, but you should probably hold off on starting your pet project until you know what you and your tools are capable of. Try and remake classic games like tetris, pong, arkanoid, chute, and asteroids. They should be pretty easy with modern tools. As you build them you will learn how these tools work and how you can use them to build your dream game. You will also make mistakes along the way. Throwing out a half functioning test game is a lot less painful than throwing out your pet project.

BTW: Don't tackle Unity unless you have a strong foundation in Object Oriented Design.

Drawing the tiles in a grid pattern is no that hard, the real difficulty comes in handling draw order so that the sprites overlap each other in a meaningful way. I don't know how to do this in Game Maker since I have never used it.

If I wanted to make an isometric game I would use Unity. Its camera has an Isometric option, and since it is a 3d engine the draw order is already handled for you. If you are going for sprite art you can face all your characters at the camera with the transform.LookAt() command.

Here is an example of something I made with unity:
http://www.monkeydev.com/unity/flatearth/index.html

There may be better isometric tools out there, this is just the one I would use since I have the most experience with it.

define the following constants to something that makes sense in your game. Note I am using C# syntax.

Code:

float lowVeloTurnRate;
float highVeloTurnRate;

float lowVelocity;
float highVelocity;

Every update use this to calculate your turn rate:

Code:

float turnRate;
if( curVelocity < lowVelocity){
   turnRate = lowVeloTurnRate;
}else if( curVelocity > highVelocity){
   turnRate = highVeloTurnRate;
}else{
   float frac = (curVelocity -lowVelocity)/(highVelocity-lowVelocity);
   float afrac = 1.0f-frac;
   turnRate = frac*lowVeloTurnRate + afrac *highVeloTurnRate;

}

Right now I am experimenting with ball pickup dynamic and biker shield. The lance will have 3 states: inactive, grab, and charge. While inactive the bike will travel at top speed and be protected from enemy strikes by a shield. While in grab state the bike's speed will be reduced and the shield is disabled. The grab state will be able to pickup and hold a ball so long as it is not being held by another player. When grab stat ends the ball will be flung forward. While in charge state the lance is building up energy for a strike. As a result the bike's speed is reduced and the shield is disabled. When the player leaves charge state the energy built up in the charge is projected forward in a lance strike. If the ball is in this forward path it is launched forward. If a shielded enemy bike is in this forward path the bike is pushed away along this path. If an unshielded enemy bike is in the forward path the bike is killed and must suffer the re spawn penalty. The lance strike is the only way to break the ball grab of another bike.

AI must exhibit new behavior based on if a friendly or enemy bike has grabbed the ball. Also the AI will want to attack other bikes for the fun of it.

I have looked at tPlayer, and I would be a dirty dirty liar if I said I understood it all, but here are a few things:

line 318:

Code:

Vector3.Lerp (this.Animation_Align, this.Motion_Align, (0.01f + Motion_Speed.magnitude * 0.07f) * Time.deltaTime);

Vector3.Lerp does not change the argument vectors you need to write it like this:

Code:

this.Animation_Align = Vector3.Lerp (this.Animation_Align, this.Motion_Align, (0.01f + Motion_Speed.magnitude * 0.07f) * Time.deltaTime);

You seem to be using "Motion_Speed" as your momentum value but not factoring in changes in speed due to wall collisions and the like. This allows the player to run into a wall to build up speed then change the angle and shoot off at max speed.
Line 348:

Code:

//adapt to character controller//this.rigid.transform.Translate (this.Motion_Speed.x * Time.deltaTime, this.Motion_Speed.y * Time.deltaTime, this.Motion_Speed.z * Time.deltaTime);

MoveController=new Vector3 (this.Motion_Speed.x * Time.deltaTime, this.Motion_Speed.y * Time.deltaTime, this.Motion_Speed.z * Time.deltaTime);

//MoveController= transform.TransformDirection(MoveController);

//this.body.Move(MoveController);



Displace=MoveController+Displace;

this.body.MovePosition(Displace);

Code:

Displace=MoveController+Displace;

Vector3 oldPosition = body.transform.position;// store old positoin

this.body.MovePosition(Displace);

Vector3 realMovement =  body.transform.position - oldPosition;// compute how far the user traveled

Motion_Speed = realMovement/Time.deltaTime; // find speed in secconds by dividing Time.deltaTime

Note: body.MovePosition(Displace) will move the player the Displace distance if it hits nothing in the process. Otherwise it will only move as far as the collides in its way allow it. By storing the old position and comparing it to the new one (post move) you can determine the player's actual movement in the game world.

  No fair Gallefray probably has access to a Tardis and multiple genius level Time Lords. How are us mere mortals supposed to keep up with that?

I mean welcome to TIG Source Compo Gallefray, good luck with your entry.

If you enjoy the game that is great. I just got done helping a friend with his statistics homework, and am seeing the world in a very computational way. I am already thinking about how I would write an AI that would lay out the cards and pick them in the most optimal way.

I am not sure the average human mind can effectively use strategy in this game. Mine sure can't. Your victory computation system means regardless of what card you play there will be 3 cards that can tie it, 16 cards that can beat it and 16 cards that it can beat. To determine the value of each card you would have to add the cards in you hand that can beat it and subtract the cards in your hand it can beat. This process would have to be repeated for all 12 cards. I can't store and compute that many numbers in my head. Even after this amazing feat of computation your best case scenario is realizing one card has a 3/23 chance of winning or loosing.

In most card games, the player knows from the face value of a card how powerful it is and can plan strategy accordingly. Your mechanic while interesting is not user friendly.

Just to confirm the desired behavior is as follows:
Sonic will have 3 states:
-Jumping/Falling
-Grounded slow
-Grounded fast/sticky

In Jumping/Falling Sonic will be effected by universal down gravity until he hits an object which he can run/stand on.

In grounded slow if he walks off the edge of an object he goes to the Jumping/Falling state. He remains in this state so long as he is moving slower than a certain speed at which point he transitions to the Grounded fast/sticky state.

In Grounded fast/sticky state sonic will adhere to the surface he is currently touching on regardless of gravity or direction of travel. Sonic's speed will be effected by user input and gravity (if it pulls with or against sonic's direction of travel). Sonic will leave this state if he jumps or if his speed drops below the grounded slow thresh hold.

Currently there is a bug in which the Grounded fast/sticky state does not respond properly to gravity and user input.

There was a game like this called Fuel http://en.wikipedia.org/wiki/Fuel_%28video_game%29. It was a technological marvel but commercially unsuccessful. I don't know if it has all the features you want, but it does have a massive map.

I played your demo and it brought up more questions than it answered.

Gravity appears to always point down (negative y), and sonic gets stuck to the surface he is traveling on until he jumps off. Is this desired behavior?

Should he be able to walk or stand on an upside down surface when his momentum is not sufficient to cancel gravity?

Should running at high speed on a convex surface fling him off into space the moment gravity no longer pulls him towards the surface?

In Mario Galaxy the gravity vector varies depending on where you are in the level. If you want that sort of behavior you will need to change how gravity functions in your game.

If you want to keep absolute gravity but have Sonic run up walls and go upside down in a realistic way (like he does in his licensed games), you are going to have to factor in his 3d momentum into his movement. I will look at your code later tonight and try and give a better answer.

Here is a concept sketch of the jetbike:

I haven't had the guts to split from the comfortable world of draw a regular paycheck to go fourth and live the dream. But mad props to you for doing it

Usually when I am lacking in motivation, I think back to all the failed job interviews I have had with game companies, and how awesome it would be when my game becomes a success. It may not be the healthiest way to approach motivation but it fills me with enough  to keep coding when sane people would get board and give up.

Since you are using Unity could you post the game in it's current buggy state? It would be much easier for us to debug if we could see the unwanted behavior and interact with it.

If the camera is where it needs to be try using Camera.main.transform.forward and Camera.main.transform.right to get the vectors in the game world. Also remember you can use transform.InverseTransformDirection() to get these vectors in your character's space.

@sonjool
Game play wise the lance will only strike forward. Art wise I would like it attached to the humanoid rider which will be separate from the bike.

@motorherp
I played a game in an arcade much like this one where you could actually pick up the ball and other players could knock it out of your control. I don't want to copy it too closely, but I agree with you, a bit more ball control would add to the play experience. Unfortunately I would have to program more complexity into the AI. right now the AI has two behaviors: line up to ram the ball and ram the ball.

I check on this thread earlier and could not make heads or tales of your question. The Mario Galaxy example really helped clear it up. This is a design problem not a math problem. The makers of Mario galaxy painstakingly figured out what location was best to view the action for each level while the player is in a certain position. They used certain math tricks like interpolation to transition between two camera positions/modes, but for the most part they did not rely on one catch all algorithem to determine where the camera is at every point in the game.

You may want to post some drawings over what you expect to happen in different circumstances. Vector math is very hard to understand from just text.

I like the Boomer from Left 4 Dead. The entire game is built around encouraging the survivors to work together and move together. The hunter picks off those who stray too far from the group, and the smoker pulls players away from the group. So the counter is to group as tightly as possible, so you can respond to distressed teammates quickly. Then the boomer shows up and all bets are off. If the team is clustered together the boomer can get multiple survivors in a single spit or explosion. Also the boomer's explosion puts into check the player's instinct for shooting the moment they see an enemy.

Good enemy design forces the player to play differently than they normally would, so the entire game does not consist of a single type of interaction. The Boomer does this quite well.

Good to see another Jousting game in this compo. I am looking forward to seeing where you take this.

I have added two teams of two bikes each. No lances yet but the game is playable. It would be nice if I could change out the place holder art with something cooler. Hint Hint. Now have an artist working with me.

Here is a new screen shot:


The playable link is in the first post.

Rag doll physics will be determined by Unity's physics engine, but the jet bikes are character controller type objects with a "Repulsion field" to effect rigid bodies. I plan on having a lance kill work buy switching the kinematic flag on the rigid bodies of the victim then letting the "repulsion field" of the bike fling them.