Empires of Notaname

Abstract
Game Name:	Empires of Notaname
Development Team Members:	Andrew Katona & Carl LeCompte
Game Genre:	Turn-Based Strategy
Brief Description:	Several players compete to secure a dominant position over their competition. Victory is attained by maintaining the strongest control over more than half of the board, while defeat is assured if the range which a player dominates becomes too small. Careful management of your resources, used to build and upgrade various fortifications, will determine victory or defeat.
Overview
Game Story / Objective:	A number of empires battle for control Notaname. Will one be victorious? Or will the war descend into a centuries-long stalemate, or worse, chaos reigning over the world?
Game Mechanics + Controls:	Each fort may do one or more of: - Exert control over an area. - Reduce the control of enemies over an area. - Increase the resources gathered from an area. Upgrades may increase the strength or range of any of these effects. It is cheaper to build a fort in an area you strongly control than it is to build in an area which is held by an enemy. Forts in areas strongly controlled by an enemy may be captured or destroyed, even if you just built it. The resources gained from a tile depend the innate value of the tile, the strength of each player's control over it, and on resource collection boosting forts. Some of the population does not care for the war, and thus disrupts the collection or resources, and may even destroy a fort that is too lightly guarded. The game can be played entirely with the mouse. The end turn button is in the upper right, the current selected fort can be upgraded from the lower right, resource and control information for a moused-over tile can be found at the upper left, and the fort building selection area is at the lower left. There are, however, several helpful keyboard shortcuts: C: Toggle on/off displaying the area a new fort will exert control over. G: Toggle the grid line display on/off. R: Toggle between control display and resource display on the game world map F1: Set fort placement mode to Standard fort placement F2: Set fort placement mode to Artillery fort placement F3: Set fort placement mode to Bunker fort placement F4: Set fort placement mode to Suppression fort placement F5: Set fort placement mode to Resource fort placement F6: Set fort placement mode to Capital fort placement F8: End turn F9: Screenshot (Note: will overwrite screenshots from prior game instances.) F12: Fullscreen mode
Technology:	Variety of complicated, flexible internal data structures. General menu system written from the ground up. Partial support for the addition of extremely general game-altering rules. Tile coverage by water affects gameplay, but is not an all or nothing effect (partial coverage is acurately computed and considered).
Aesthetics:	The graphics, menus, and other interface elements are all meant to be simple, emphasizing functionality and clarity. Various built-in model-drawing functions provide unique models for each fort type. The game world view can present resource or control information at a glance, while mouse-over displays give more precise data on selected tiles.
Reflections
Three Greatest Challenges:	Challenge 1: Generality It was difficult to keep feature interactions as general as we wanted them to be. This was partially solved by careful planning before implementing features, while in other cases the desired functionality was scrapped due to excessive complexity required for relatively poor generality gains. Challenge 2: UI Design Getting the UI to present the desired information while remaining generally unobtrusive took a fair bit of thought, with a bit of trial and error. Challenge 3: Feature Selection Even after some generality-promoting features were dropped due to excessive complexity, there were still many more ideas for stuff to add than could be implemented in the available time, leading to having to make choices about what seemed most likely to add new dimensions to gameplay or make the game more user-friendly.
Three things that went right:	Time Management: We managed our time effectively, in that little time was wasted on unnecessary merges or delays on waiting from code from the other person. This was partially possible because work was very well divided, and partially due to good code architecture. Implementing New Ideas: Several ideas that came late were easily implemented because relevant existing code sections had been well planned, and thus could be easily extended. UI Design: Once things were sorted out, the UI managed to meet our goals of being both clear and unobtrusive very well.
Three things that went wrong:	Overall scope a bit too ambitious, leading to somewhat more feature cuts than expected, though the resulting game was still very complete. Some core code sections that were written early were initially implemented in very messy ways, resulting in some problems in cleaning them up for later changes and additions. An excessive number of values were initially #defined instead of being made variables, resulting in extra time spent cleaning them up (especially when one define was used for two linked pieces of functionality when different values should have been used).
Lessons learned and/or things that you would have done differently:	Would have agreed on a consistent coding style before any code was written. Would have started with a less ambitious design then focused more on additions later, instead of working around excessively complicated ideas that ended up scrapped. Would have worked on the UI more heavily at an earlier time, because it would have resulted in time saved testing other systems.
Media
Screenshots: