Monday, 28 April 2014


Getting in the mood for my next project... got myself an arcade fighting stick! (also works pretty well for sensi!)

We've Come a Long Way

In just a few short months!

Thursday, 24 April 2014

Banana Shots!

Otherwise known as "aftertouch" which is just as well because the banana aspect isn't implemented yet. Anyway, here is the height aspect of the aftertouch system.

I don't know why this became synonymous with Sensi because KickOff certainly had it years before, and I'm pretty sure Microprose Soccer had it too, which was like one of the first footy games ever.

There are three possibilities after the ball has left your foot:

1. Release the D-pad completely: adds a modest and constant amount of lift depending on the power of the shot;

2. Press the D-pad in the direction of the shot: keeps the shot as low as possible;

3. Press the D-pad in the opposite direction: add lift in proportion to the length of time the D-pad is held.

Short explanation: we can now do big loopy shots and clearances and generally hoof the ball miles in the air! w00t!

The Menu Please!

A mockup for the start screen and menus.

Wednesday, 23 April 2014


I said at the start that part of the reason for having a blog was simply for motivation and inspiration.

Well, it works bitches! Since the last post (after a couple weeks of toil in silence) the issue has been solved in the past couple of hours! Fuckin' magic.

Tech details to follow.


I've been stuck on the same problem for a couple of weeks now. It's really annoying. The game has reached a level of complexity where it's really tough to address difficult issues in one or two hour spurts every so often.

Basically, because of the complexity of the AI system (to allow for more interesting stuff later), it is a big job in itself just to try out a particular approach. There are 4 different levels of state machines :

1.  the player at the physical level  - standing, running etc. (handles "locomotion" details)

2. the player at the decision making level - the "brain" which instructs the physical level player to go into a "running" state for example. The brain can be in a "covering" state where it basically analyses where the ball is and tells the physical player to run to a suitable position. Or a dribbling state where it tells the player where to dribble to, or decides to pass, shoot or clear the ball.

3. the team states. For example when a team is in a "defending" state the players are aware of this and can go into a "cover" state as opposed to a "support" state for an attacking team.

4. the match states - for example "kickoff", "throwin" etc. which feeds into both teams so they can select the correct state for themselves and their players.

So you can see, in tweaking the architecture of how the whole thing works together, it sometimes gets rather intimidating and something you'd want to tackle (excuse the pun) in more concentrated blocks of work (as opposed to 30 mins tonight, and then an hour in 5 days when you've completely lost your flow of thought already.)

Anyway, it's annoying because the thing is so close to  actually being a complete game of football. The specific issue I'm having now is merely the transition of possession when two players are vying for control of the ball at the same time. It sounds trivial but there are a lot of domino like effects and implications for the system of state machines in handling who is actually dribbling the ball.

If a player can't recognize correctly that he should be dribbling as opposed to pressing the ball, he'll constantly chase after the ball whilst dribbling at the same time, resulting in him running blindly in a straight line - ARRRGHH!

Monday, 14 April 2014

Input Switching

A quick first try. Works quite well for a 20 minute hack up! The joystick control is switched to the closest team player to the ball, as signified by the squad number.  In future we'll make it more intelligent by assessing where the user is pushing the joystick to switch to the player he *wants* to control and not merely the closest to the ball.

It's easier to play in high resolution!!

AI vs AI mark 2

There are invisible walls around the pitch because throw ins etc are not implemented yet, and all shots are calculated to hit the post!

Thursday, 10 April 2014

Stadium Teaser

Using the graphics from Yoda Soccer for now.

Short Passing

Just a quickie. Haven't had time to do much , but the players can now pick a pass to the first team mate who happens to wander into their "short passing zone." Angle and weight of passes are quite accurate.

The next step is to give the player in possession a realistic objective based AI (instead of just wandering randomly and passing to the first available teammate) and also give the other players better supporting AI.

Here it is in old skool resolution:

Wednesday, 9 April 2014


Well Hello Mr Euler

The big no no of Euler integration is right out of Physics 101.  Briefly, the method looses accuracy as the time differential gets larger, due to its inherent assumption of constant acceleration.

When the timestep is very small and constant, this error is negligible. However, in computer games we can not guarantee the uniformity of the time step very well and, for most real objects, acceleration is not constant.

For something like the ball, which we want to behave pretty realistically as a physical object, it's probably a good idea to use a better integration method. If you are interested in the technical details, google "Verlet" and "RK4."

Anyway, for a game as simple (relatively) as Senseless Soccer, the Euler method is *almost* good enough. But you do get the odd visible hint of its shortcomings ever now and then due to the frame rate/time step measurement fluctuating for whatever reason. It manifests in the form of players running through the ball, the ball looking like it just teleported and bouncing off the posts too late or too early etc.. So lets implement a slightly more robust method for the ball.

Contrary to how most of the online tutorials come across, it's quite simple!! To smooth out the errors we simply take the velocities across 2 time steps, and average them to get a better estimation of what the current position should be.

The other methods average the values across a larger sample for even greater accuracy, but for our purposes this improved Euler should be fine. It may be some sort of psychological confirmation bias, but I think the ball looks more realistic already!

Incidentally, for the movement of the players we stick to simple Euler integration (of course the other methods would work fine too, but just aren't necessary). This is because the players always move with a constant velocity. There is no acceleration involved. It would be possible to implement a game where the players do have an acceleration component (so they couldn't change direction or stop immediately) but if you imagine the space ship in Asteroids as a player, you can see how infuriating that gameplay mechanism would be for a footy game like this!

Monday, 7 April 2014

Sunday, 6 April 2014


One of the quirks of sensible soccer is that the player can only run in eight directions. This was a necessary mechanic back in the day due to the joysticks and gamepads being strictly 8-directional.

Believe it or not, the modern style FIFA games worked pretty much the same way until quite recently (you can see them making a big deal out of "360 degree movement" in their ads) where they take advantage of the analogue "thumbsticks" on modern controllers.

Such a system wouldn't really work with a retro style sprite based game, as you'd have to have either a huge amount of sprites to cater for small differences in the angle of movement, strictly top-down sprites that can be rotated by the game, or ridiculous looking players who look in a slightly different direction to where they're headed.
So we're sticking with the simple sprite-based 8 directional movement scheme. It'll be slightly unrealistic for players like Rio Ferdinand, who only seems to be able to move in 4 directions these days, but what can ya do.

This does throw up a few quirks though. For example, with the movement of the AI players, you can't simply calculate the best direction to run in and update it every frame as this results in a very unrealistic zig-zag path as they attempt to reach their target.

[note there is more complexity to this when you consider static vs moving targets but we'll simplify it for the sake of explanation]

So to get a relatively realistic behavior that mirrors how humans use the controller, we calculate the heading to the target, round it to the nearest 45 degrees and set the player off on his merry little way. Obviously, if the target didn't just happen to lie on a 45 degree angle, he'll never actually reach it and the whole thing will fall apart. To counter this, we add a check to compare the distance from the target each frame. If the new distance from the target is larger than the last distance, this is a good time to recalculate the heading to the nearest 45 degrees. This *roughly* simulates how a human player would manipulate the controller to get where he wants to go.

This is an extremely simple solution to what is a huge field in game design (path finding etc) but it's interesting nonetheless and should be a good enough solution for our purposes.

Interestingly, the original sensi solved this problem with a complete and utter cheat. Its computer controlled players are not restricted to the 8-directional movement. It's not so galling visually when the computer does it, but there was always a subconscious "hmm that's not quite right" factor without knowing exactly what was up. If you go back and play or watch it now, it's quite obvious when you know what's happening.

Who knows, perhaps there are other reasons for the "cheat" that will force us to adopt this strategy later on. Living and learning!

Wednesday, 2 April 2014

Mindful Passing

When a player grabs possession, he has a few decisions to make. One of them is if there is a good pass available. The first step is to gather all the players in a possible receiving position. The mechanics of this kind of game means that the player is always moving when he has possession and must pass in the general direction he is moving. It's only fair the AI does the same.

So the small circle represents his short passing range and the large circle represents his long pass range. Any team mates within these circles will be considered as a possible passing target. Of course, if the player is under pressure and no passes are  available, he'll have the option of hoofing the ball upfield blindly. So for Man Utd, the circles are essentially redundant.

I've zoomed way out so you can see what's going on: