Created by David Kaplin
With Contribution by Chris Quackenbush
Game architectures without the proper structures can, and usually do, end
up as a monolithic mess. One false move, and everything falls to pieces.
Instead of building upon the previous architecture you are forced to
dismantle it or make a bigger mess for the next architect. As I have
dismantled a couple of the previous games, I have discovered
little reusable pieces that should be able to help future architects build
less coupled, readable implementations of their problems.
What is Heurgame?
Heurgame is a set of abstractions and utilities that
should allow greater flexibility in building game software.
What isn't Heurgame?
Heurgame is not a Game Engine. It does not employ any normal components of
a game engine such as Physics, Lighting, Sound, or Rendering. The only system
that comes close to a that of a Game Engine is the networking component. Even
that component is optimized for programmer understanding, not speed.
- Flexibility - Handle any potential possibilities...
What if people could play at the same time?
What if the second person went twice in his second turn?
- Modularity - Separate Logic, User Interation, Network Interaction, and in some cases Behavior.
Use Events to tie things together.
Bind as loosely as possible.
- Readability - Write for the next architect, not yourself.
Be defensive when defining interfaces.
A type error at compile-time may save you from a heisenbug.
- Automation - Write the boring stuff once, so you never need to write it again...
- Smart Multi-threaded server:
- Logging System:
- Multi-player and Security Conscious Welcome Screen :
- Validating Input Fields:
- Generalized Event System:
- Tookit independent user interface:
- Generic User Interface items:
- Adaptable Randomized Player Colors:
- Score Board:
- Time Display:
- Log Viewer:
Game - Top Level of the Game Logic Abstraction. Knows things like player order, minimum players. Interested in the big picture
but does not actually know the rules.
PlayerProxy - Responsible for a socket connection to the player. All players are represented as PlayerProxies, no matter their origin.
This enforces fairness. PlayerProxies are the only source of PlayerTokens.
PlayerToken - A unique object for each connected player. Used heavily in the event system, and therefore throughout the user interface.
HuClient - A client that is created by the game, usually representing a human player, but could represent something more interesting like an AI.
Referee - Middleman for the PlayerProxies. No other class can directly communicate with the proxies. Responsible for adding and removing players.
TimeKeeper - Responsible for keeping the correct "Move Time" for a given player. Works with the Referee to warn and potentially eject the player
from the game.
GameServer - With the help of the Game and Referee collects
incomming requests and transforms them into PlayerProxies.
GameEntry - Aids in the process of transitioning a stand-alone game
into an Applet.
SystemAnalyzer Knows the rules of the game, maintains some sort of global state. Responsible for determining winners if any.
MoveAnalyzer Knows some of the game. Usually stateless. May delegate to the SystemAnalyzer for trickier move analysis.
GameEvent Setup, Start, End
PlayerEvent Joined, Left, Moved, StatusChanged
Broadcasters Store all listeners and when invoked, inform them of some new event.
LogBox - Automates the dull parts of the logging infrastructure. Less flexible, but simpler.
MemorySocketFacade - Abstracts above Sockets to allow Memory based
Sockets for use in enviroments that Sockects cannot or should not be
InterfaceDirector Controls the construction process and sets up the
game's user interface.
InterfaceBuilder Does the actual building of the user interface
with regards to general items such as Buttons, Windows, and Labels
ComponentOrientedBuilder Allows built parts to be used with Java
layout managers. Currently there are Builders for AWT and Swing.
ZeroLayoutBuilder A combination of BorderLayout and GridLayout that
should work for simple layout needs without creating any LayoutManagers on
MutableTextWrapper - A Generic wrapping class to allow the calls of
getText and setText to work on unrelated components, such as JLabels,
Labels and TextComponents
Validator - Checks the Text of some component based on some rules.
ValidatingInputField - When combined with a Validator may display
an error when containg invalid text.
Design Patterns In Action describes a few of
the design patterns used in the framework.
Current Version 1.1
Documented Source Jar
Signed Documented Source Jar
Changes in Version 1.1
Changes in Version 1.0
- Added the NoLimitRRTurnIterator
- Other modifications possible for 1.1...
Changes in Version Beta 1.0.4
- Server now detects if Security Restrictions will allow it run
- HuClients now communicate using MemorySockets
- MemorySocketFacade was created to unify MemorySockets and Traditional
The Input and Output streams are infinite until closed
- MutableTextWrapper was created to allow simple cross-toolkit labels
and multi-line displays
- Bug in TurnBasedIterator squashed
- Server can now be relocated (when the security manager allows)
- Players can be kicked individually from the server
- Minor UI enhancements
- Framework comes in two flavors: signed, for use in signed applets,
and unsigned that does not pester the user with certificates
- Cleaned up MoveAnalyzer
- Removed extraneous debug
Changes in Version Beta 1.0.3
- Altered Game interface to allow a maximum player setting
- Add capability to build MultilineText Displays for use in
help documentation or other descriptive areas, updated the Swing and AWT
- Changed the builder semantic. Now when you associate an icon
with the main window you associate that icon with every window that does
not specify an icon
- Current exception to the above is the GraphicalLogInterface, that
should be fixed in a later version
- Better documentation!
- The framework is now signed!
- Added a terminate() method to Game
- Extended the Server to locate a new address
- Created the class GameEntry as a prototype for the main class
of your Games. GameEntry coupled with InterfaceDirector becomes
a good entry point for your program and should standardize the Main class
for your game. GameEntry also streamlines the transition the entry point
for your program into an applet
- Created heurgame.ui.builder for ease of changing toolkits, currently
supports a subset of AWT and Swing. All builders are sandbox aware.
- Make sure to see the ZeroLayoutBuilder class to ease the process of
building an interface
- Created heurgame.ui.form for validating text fields a task common
enough for automation
Recipe for an Applet
Running the Applet for competition
A page of why
Neat things that haven't been done yet
- An internal scripted AI
Similar to the HuClient but does not
need UI to move. Imagine playing the optimal player from
the previous class? Does not need to be random, but random would be
a start. Given that this construct would be protocol dependant, I
would probably create a common super-class to HuClient and this
ScriptedClient. As to how the scripted client would know how to
act... Well, there is a lot of room. Early versions could be
hardcoded java (even in that case they could be discovered by the game at
runtime...). Future ones might read a textfile (that is protocol
dependant) with variables in place of the expected parts of the
protocol. Esentially making a basic imperative language, but it would be
built ontop of Java so there would be less work on the backend. That
level of abstration would allow two things.
First, less work would be needed for the scripted client to parse the
protocol, because it is already done in library. Second, users could test
strategies without compilation. This would not be an easy undertaking,
but it is within the realm of possibility.
- SWT implementation for builder
- Graphical generator for mindless user interface code :)
- Better graphical log interface