Tuesday 8 December 2015

Sexy Nets

Playing around with a little opengl and verlet physics to feed my passion for sexy nets.

 


Thursday 26 November 2015

Overkill?

Note: this feature does not work on mobile browsers.

 

Alternative "modern" design:

Saturday 31 October 2015

Thursday 29 October 2015

Another Triumph of the Open Source Paradigm

Been playing around with a bit of web development for the various senseless websites and stumbled across Aptana Studio.

It's a comprehensive web IDE in the style of Eclipse and it's absolutely fantastic.

Highly recommended.


CSS ftw!

Added a few small nicies to the website. Most notable the popups on the screenshots section.

http://higgis.at/senseless-soccer


Sunday 18 October 2015

Pitch Sizes

The engine (tactics, rendering, match) allows for variable pitch sizes. In combination with different surfaces and weather condition, should make for some interesting gameplay!


Thursday 15 October 2015

Tactics Editor

Somehow managed to lose the Tactics Editor code so spent the evening re-coding it.


This is not intended for the end user, but as a labor-saving tool to generate the player position files.

I don't think I will copy SWOS in including such a tool in the game, I think it is a bit of overkill. Rather I will combine the ideas from SWOS with the ideas from Football Manager.

There will be a list of pre-defined positions that you can pick from for each player :

LEFT_BACK                    
LEFT_WINGBACK                
RIGHT_BACK                    
RIGHT_WINGBACK                
SWEEPER                      
LEFT_CENTER_BACK              
RIGHT_CENTER_BACK            
ANCHORMAN                    
LEFT_DEFENSIVE_MIDFIELDER    
RIGHT_DEFENSIVE_MIDFIELDER    
LEFT_CENTER_MIDFIELDER        
RIGHT_CENTER_MIDFIELDER      
CENTER_MIDFIELDER            
LEFT_MIDFIELDER              
LEFT_WINGER                  
RIGHT_MIDFIELDER              
RIGHT_WINGER                  
ATTACKING_MIDFIELDER          
LEFT_ATTACKER                
RIGHT_ATTACKER                
LEFT_CENTER_FORWARD          
RIGHT_CENTER_FORWARD          
CENTER_FORWARD
DEEP_CENTER_FORWARD

These will have the pre-defined sectors (where the player will try to go to depending on the ball position). Each position has a set for attacking and defending. The position also implies a FM style "role."

Each position can then be modified through player instructions (slide bars) for pressing, passing length, shooting length etc.

A "tactic" then, is a specified set of 10 of these position. Here, for example is how you'd make the popular 4-2-3-1:

LEFT_BACK                                  
RIGHT_BACK                                
LEFT_CENTER_BACK            
RIGHT_CENTER_BACK                          
LEFT_DEFENSIVE_MIDFIELDER    
RIGHT_DEFENSIVE_MIDFIELDER                  
LEFT_WINGER                            
RIGHT_WINGER                
ATTACKING_MIDFIELDER                
CENTER_FORWARD

Sunday 11 October 2015

Dribbling

Here's how the dribbling would go for a player with less skill. It's still possible to turn with the ball, but only when timed properly with the ball under control. No sticky feet.


Goalkeeper Progress

Somewhat robust, yet not unbeatable. Half way there! Next step: catch type saves.


Sunday 4 October 2015

Sunday 27 September 2015

Shot Prediction

Phew. After a long, exhausting day taking a refresher course on geometry/vectors, we have a shot prediction calculation to give the goalie some diving AI.

Thanks to Mr Chong for his article:

http://code.tutsplus.com/tutorials/predicting-collision-points-with-math-in-as3--active-11218

The goalie isn't programmed yet, but the important thing is we can predict where the shot is going to cross the goal line (or any other line for that matter):



Here's some code:

1:  Point CollisionDetector::predict_intersection(const Point& position, const Math::Vector3 &direction, const Line &line, bool right_normal){  
2:   Point intersection;  
3:    
4:   // head of ball is position  
5:   Point ball_head = position;  
6:   // tail of ball is position plus direction  
7:   Point ball_tail(position.x + direction.x, position.y + direction.y);  
8:    
9:   // head of line is start of line  
10:   Point line_head(line.x, line.y);  
11:   // tail of line is end of line  
12:   Point line_tail(line.x + line.w, line.y);  
13:    
14:   Math::Vector3 vball(ball_tail.x - ball_head.x, ball_tail.y - ball_head.y);  
15:   Math::Vector3 vline(line_tail.x - line_head.x, line_tail.y - line_head.y);  
16:    
17:   // toV2b is vector from point to start of line  
18:   double perp1 = vball.perpProduct(vline.normalised());  
19:   Math::Vector3 toV2b(line_head.x - ball_head.x, line_head.y - ball_head.y);  
20:   double perp2 = toV2b.perpProduct(vline.normalised());  
21:    
22:   /*  
23:   * length is calculated from the similar triangles ratio  
24:   * it is later used as magnitude for a vector  
25:   * that points in v1's direction  
26:   */  
27:   double length = perp2 / perp1 * vball.magnitude();  
28:   Math::Vector3 length_v1 = vball;  
29:   length_v1 = length_v1 * length;  
30:    
31:   /*  
32:   * extend to locate the exact location of collision point  
33:   */  
34:   intersection.x = ball_head.x + length_v1.x;  
35:   intersection.y = ball_head.y + length_v1.y;  
36:    
37:   return intersection;  
38:  }  

Friday 25 September 2015

The Behaviour Stack

A bit of technical stuff.

So the game was designed from the beginning with a focus on the AI sub system. I wanted it to be
flexible enough to add some really interesting AI later, both to make the game more challenging to play (and develop!) and also to make cpu v cpu matches more meaningful in a career mode.

Taking advantage of the state machine pattern, the player is a state machine in itself and it has states such as "running," "dribbling" etc. with only react to outside conditions and update the player animation. For example, if the player's velocity is non zero, he automatically goes into the running state. This merely loads in the correct animation frames and updates the animation each frame. Likewise, the running state transitions into the dribbling state if the ball is under the players control. The only difference is that the ball is knocked forward on contact.

This has nothing to do with AI so far.

The player *has a* brain object. The brain is responsible for surveying the game environment (and team instructions) to make decisions and trigger "behaviours." A behaviour is a locomotion controller such as "seek," "interpose" or "jump."

For example, the seek behaviour is triggered when the brain wants the player to run to a specific location on the pitch. It is only the behaviour object which has privileges to directly update the player's velocity property.

A special vase in the behaviour space is the jump behaviour. Since the jump behaviour must set the players z velocity, it is correctly placed in the AI::Locomotion space, but can create an unwanted side effect if the brain decides to initiate a seek behaviour before the player has come back to earth. We then end up with a player floating around in mid air (as pointed out before, for playability reasons, the player does not react like a regular physical object, merely a sprite moving around the screen with no acceleration or outside forces and therefore there is no gravity applied to him to correct the problem).

The solution for this was to think in terms of real world objects (OO ftw). What's really going on is that your brain knows it wants to run somewhere, but you can't execute the physical movements (behaviour/locomotion) necessary to achieve the goal whilst you are in the middle of the jump.

So now the brain manages a queue of behaviours and each behaviour object has a method to check "canStop()." Most behaviours are able to stop immediately, but in the case of the jump behaviour, it will only return true when the player is back on the ground again. When false is returned, the brain adds the behaviour to the queue and, each update, if there is anything in the queue it will try to switch tot he next behaviour in the queue.

Thursday 24 September 2015

Goalie Jump

The goalkeeper can now do his first variety of basic save - a straight jump in the air.




Camera

Turns out there was a wee glitch in the camera (see previous vids) where it stuttered with small ball movements. It's a bit smoother now:


Tuesday 22 September 2015

Hybrid Gameplay

Edit, lets put the video first. Most people don't read this shit anyway ;)


So, the idea is to have a dribbling system that combines the scheme from Sensi with that of Kickoff.

On of the big differences between the two games was that kickoff had a kind of pinball, very difficult to master, dribbling system whilst in sensi the ball generally stuck to your feet as you ran.

In Kickoff, the player knocked the ball forward on impact and it was not possible (except for very specific and skillful situations) to turn whilst running with the ball, but in sensi you could weave around at will without losing the ball.

This was probably the biggest difference between the games and a huge bone of contention between the respective "fan boys." With the dust settled, lets look back with impartiality.

It is my view that sensi appealed to younger and casual players (a much bigger market) as it was immediately gratifying to play. That's not to say it didn't have depth, it certainly can be claimed that it achieved the goal of that age old mantra: "easy to play, hard to master."

Kickoff, however, was the most infuriating experience until you really got good at the game. The ball was very difficult to control and scoring was almost impossible. But once you mastered it, boy that game was so gratifying. Scoring a goal against your buddy actually meant something. In your face!!!! It also had a somehow elegant gameplay side-effect that the faster you ran with the ball, the harder it was to control and the more likely you were to lose it (just like real footy).

Anyway, the idea with senseless, is to make a dribbling mechanic that falls somewhere in the middle. We'll have the nice "physical" aspect of the ball as it's knocked forward with every touch but, depending on the skill of the player, you will still be able to turn and weave freely if you time it right.  Players with a higher rating for dribbling will knock the ball forward a shorter distance, and will be more like to keep the ball under control after turning. Perhaps players like Messi will have the ball stuck to their feet like in sensi.

Sunday 20 September 2015

Ball Physics

Just tweaking the ball physics. Looks and, more importantly, feels great!

Gamedev

An interesting development aid - almost the whole pitch on screen! :)



Saturday 19 September 2015

Aftertouch Reimplemented

Good enough to kick on with the match engine!


Short Passing Tweaked

Tweaked the receiving player to connect with the pass better.


Short Passing

The idea is that by tapping the fire button, you can pass to the nearest player. This gets around the 8 direction limitation for a slick passing game.


Friday 18 September 2015

Importance of Air Resistance

A while ago I saw a great lecture/presentation by Dino Dini (creator of Kick Off etc) and he made a comment about the importance of air resistance. Didn't quite understand what he was getting at. I do now!

The ball is being kicked with the same force in both videos. Without simulating air resistance, you can't get a realistic long/high goalkeeper kick without the ball flying off the pitch (or bouncing once and then flying off too quickly for players to react).

So, according to Dino, games that didn't simulate air resistance had to hard code a fake vertical bounce to keep the ball in play. Interesting stuff (for a nerd).





Thursday 17 September 2015

Just a Kickabout

Footy Games

While we were all arguing over FIFA and PES, the best footy game was released in Japan, in 2004!!!

I give you Football Kingdom. Just check out the net physics on this thing! Ten years ago!





Compare with FIFA 2005:
 

Website Bugfix

The ratings popup on the database website now works with more than one table on the page. Woot.

http://www.higgis.at/senseless (user/pass: guest)


Has Anything Changed?

Wednesday 16 September 2015

Dev Debug Features (or "I Has Made Progress Bar!!111oneone")

Just a couple of interesting devel features to track the fire press for shot types, and drop the ball on the screen with the mouse.

The flickering is just from the capture app, honest!

 

Under the hood, the progress bar is simply a "draw rect" and "fill rect" call, so it's extremely fast.

Thursday 10 September 2015

Mouse Mat

With a good optical/laser mouse, I'd always thought the mouse pad was obsolete. Wrong! A good pad makes a hell of a difference, and not just for gaming.

I decided to try out a Razer Goliathus and now I'd never go back! Absolutely fantastic. Highly recommend you give this a try.

Personally, I prefer the control edition.

http://www.razerzone.com/gaming-mouse-mats/razer-goliathus-control-edition


Ron Gilbert

Just before he created the greatest adventure game of all time, Ron Gilbert wrote this:

 http://www.grumpygamer.com/why_adventure_games_suck

#genius 


Decoupling the Physics

Proof of concept (see http://digital-minds-blog.blogspot.com/2014/12/fixed-delta.html)

The point is to keep the gameplay speed consistent regardless of how fast the users PC can render the graphics. So, as a test, the game should run at the same speed with monitor VSYNC turned on and off. VSYNC turned on kind of emulates a PC with lower rendering rates.

Not only would it mess the game up on different PC's, but it would make online play impossible!

You can see the problem when the loop depends on the frame rate:




Here it is decoupled:



A nod to Glenn Fiedler for a great article on the topic:

http://gafferongames.com/game-physics/fix-your-timestep/

Here's the game loop:

1:    //  
2:    // calculate timing metrics  
3:    //  
4:    double new_time = SDL_GetTicks();  
5:    double frame_time = (new_time - current_time) /1000;  
6:    
7:    if ( frame_time > target_frame_time)  
8:      frame_time = target_frame_time;  
9:    
10:    current_time = new_time;  
11:    accumulator += frame_time;  
12:    
13:    //  
14:    // update physics as many times as possible in remaining frame time  
15:    //  
16:    while ( accumulator >= physics_step ){  
17:      getDefaultCamera()->update( physics_step );  
18:      for( unsigned int i = 0; i < physics_list.size(); ++i ) {  
19:    
20:        physics_list[i]->update( physics_step );  
21:      }  
22:      accumulator -= physics_step;  
23:    }  
24:    
25:    //  
26:    // do rendering  
27:    //  
28:    translate( getDefaultCamera()->getViewport().x, getDefaultCamera()->getViewport().y );
29:    render();  

Wednesday 9 September 2015

Saturday 5 September 2015

Goalkeeper Positioning

Finally got around to giving the goalie some movement and "rushing out" AI.



thumbnail for sharing

Tuesday 30 June 2015

MacOS Application Bundle

FINALLY got it working as an app in OS X. Very easy once you know how, not so obvious to begin with!

how it looks in finder
with "show package contents"

Tuesday 27 January 2015

Finally having the 600 over the 1200 pays off!



pff it seems not everybody is an Amiga nut... OK, I'll explain myself. Whilst the Amiga 1200 is undoubtedly the better Amiga, it is significantly larger than the 600 and wouldn't fit on the shelf!

Saturday 24 January 2015

Thunderhawk


Should have been the killer app for the Mega CD. Way ahead of it's time and showed what was possible on the system. Unfortunately everybody else was obsessed with postage stamp sized "FMV" windows and the Mega CD died a slow death. This game also has a phenomenal rockin soundtrack, really putting the CD media to good use!

Wednesday 21 January 2015

Cross Platform FTW!

Mac:




Windows 7:




For anyone interested in the details.

Windows:
1. Install MinGW and make sure to get the basic gcc, c++ and make packages.
2. Install FreeType for Windows.
3. Download the SDL2, SDL2_image and SDL2_ttf MinGW development files -
  a. Copy headers to the MinGW/include dir.
  b. Copy the libs to the MinGW/libs dir.
  c. Copy ALL of the the dll's to the game exe dir (easiest solution). Obviously, do this after step 5.
4. Configure Eclipse search directories as above, and link to mingw32 and sdl2main.
5. If you have been good with your cross platform coding, the source builds perfectly without modification.
6. Spend half an hour wondering why the game seems to be running properly with all debug output showing, but there is no game window. Then remember that you set the window to startup with x=1280 for testing with dual monitor, and now you only have one monitor. Change the x back to 0 and voila.

(alright, so step 6 is only for me)

Mac:
1. Download the SDL2 sources, extract, run "configure," "make" and "make install."
2. Thank me for step one, and not having to bother with Frameworks, sdlmain etc. as most of the online tutorials say.
3. Project will build in Eclipse without source modification (if you've been cross-platform friendly)
4. Voila.

Monday 19 January 2015

OS X

I remember starting with Senseless Soccer in X Code, fannying around for hours with "frameworks," search paths, SDLMain.m  etc. to get SDL working.

Well I've just done the same damn thing to build the latest version of Sensi for Mac, this time using Eclipse.

I can save you 3 hours and 50 minutes of the 4 damn hours it took me to finally work it out:

Do not, I repeat, DO NOT pay any attention to the guides on the interwebs! You'll spend hours fannying around with frameworks, search paths and SDLMain.m and in the end, it wont work! It is much easier than the internet wants you to think.

You don't need to bother with frameworks at all!

Simply install SDL from source as usual (run configure, make, and install.) Set up Eclipse exactly as in Linux (just add search path and tell it what libs to link to), import your Eclipse project and build.

Voila (as long as you've stayed away from system specific code in your project source).

Yeah, it's that easy.

Not my screenshot, I just liked this guiy's colour profile!

Sunday 18 January 2015

SDL and Eclipse

Thought I'd share this in case anyone else has the same problem:

In Eclipse CDT I had the strange problem where the project would run in debug mode in eclipse, and normally from a terminal, but not when using "run" from eclipse.

In this one particular case, SDL failed with "no available video device."

The solution is to add the DISPLAY environment variable to your run configuration. I have no idea why this isn't needed to launch a debug session as well:


Note: in older versions of Eclipse, this option can be found in Properties -> Run/Debug Settings. Select the configuration and then "Edit..."

A window similar to the above screenshot will come up where you can add the environment variable. Remember to do it for all configurations.

Monday 12 January 2015