"Having one less character to type is NOT a good reason to prefer float over double..."
The extra precision can surprise you by fixing a lot of weird buggy stuff that you hadn't managed to trace back to floating point precision and, unless you're targeting some really specific old hardware or trying to simulate the universe or something, doubles don't cost you anything so might as well use em!
That's the problem with taking examples from badly written books - when your focus is on learning a bit of path-finding or something and the fact that the author riddled his code with floats just doesn't register!
Out of interest, switching to double fixed a few bugs like the rounding of vector angles to their nearest 45 degrees.
Monday, 15 December 2014
Saturday, 13 December 2014
Wednesday, 10 December 2014
Under the Hood
The past few late nights have been spent splitting the project into reusable components. It was already structured that way but now we have a shared game library that can be linked to for use in future games.
The lib can be linked statically or dynamically.
An example of the line between the game and the lib is the Player Sprite. The Player Sprite is part of the game and inherits from Sprite which is part of the generic library. Sprite then inherits from a generic Renderable object.
The lib also contains stuff like math tools (vectors), physics, input and Window management. Anything that could be reused for another game really!
P.S. Finally made the jump from bog-standard make to cmake for the shared library. It's just as cryptic but a little easier to use I guess!
The lib can be linked statically or dynamically.
An example of the line between the game and the lib is the Player Sprite. The Player Sprite is part of the game and inherits from Sprite which is part of the generic library. Sprite then inherits from a generic Renderable object.
The lib also contains stuff like math tools (vectors), physics, input and Window management. Anything that could be reused for another game really!
P.S. Finally made the jump from bog-standard make to cmake for the shared library. It's just as cryptic but a little easier to use I guess!
Thursday, 4 December 2014
Joystick Input
For future integration in-game, interface tweaked for joystick input (like SWOS).
Moving the joystick highlights different players or the ball (flashing border), pressing fire locks on to the currently selected object(fixed border) to be able to move it around. Pressing fire again unlocks and returns to the "select object" mode.
Moving the joystick highlights different players or the ball (flashing border), pressing fire locks on to the currently selected object(fixed border) to be able to move it around. Pressing fire again unlocks and returns to the "select object" mode.
Monday, 1 December 2014
Quick Tactics Editor in Java
Utilizing the simple grid system from the game, this makes a nice tool for visually setting up tactics and player positions for different situations.
Each player icon represents a player position structure, which is basically just an ordered list of numbers specifying which sector the player should try to get to for each ball sector. See this post for info.
Positions can be created, copied, imported and exported so a full tactic is simply a collection of 10 unique positions in a group.
In future, we'll add more detailed tactics and strategies like passing style, positions for set pieces, marking style etc.
Subscribe to:
Posts (Atom)







