Here’s a comparison of the look of the old gallery to the new:

Motivation

I created my original photo gallery before web galleries like google photos were popular. At that time it was possible to manually upload your photos to a web host like Flickr or Shutterfly, but you gave up some control of your photos and their interfaces weren’t great.

Today it is hard to argue against using Google photos – especially for people who don’t have a standalone camera. Google photos provides AI based search and categorization that replaces hours of captioning and tagging of photos. They provide an easy to use interface and lots of free storage.

But there are still disadvantages to switching to Google photos for me. The main one is my stubborn resistance to giving all my photos to Google. Their terms and conditions are pretty good, but are subject to change at any time and give Google permission to use photos forever. The second is my sub-photo feature. In my albums photos can have a set of sub-photos that you can see by clicking on the main photo. This allows the album to be small, showing just the best photos, while still allowing me to post everything.

New Look

My existing photo gallery has small buttons and scroll bars that are difficult to use on a mobile device. Along with fixing that problem, I changed the layout of the page to be responsive to the screen size. I also removed the requirement that all photos take the same amount of space on the page. This allows a better display of panorama and portrait orientation. I based the look of the new site on Google Photos which has a nice clean look.

Amazon S3

My web hosting company (HostGator) advertises “unlimited” storage space, but in practice there is a limit of 100K files. This sounds like a lot, but between all my webpages, WordPress blog, and photos, I’m getting close to this limit. I also have plans to switch to a private web server like Digital Ocean which will give me more control of the software on my website. But when I do that I’ll have to pay significantly more for storage space. So as part of this gallery re-write I moved the storage of my images to Amazon S3.

I’m using S3 is as a cloud based hard drive. I added the capability to my photo processing software to upload the original photo along with a mid-sized and thumbnail sized image to S3. The thumbnails are about 12KB each, the mid-sized image is about 300KB and the original depends on the camera. All my photos take about 100GB and adding the thumbnail and mid-size version increased that by about 8%. The cost to store all of this in S3 is about $1/month.

S3 was not difficult to setup, but it wasn’t trivial either. I needed to setup permissions and get API keys, and their systems were not intuitive to me. On the other hand, their software SDK for C# was extremely easy to use and I was able to quickly add the code to upload the files.

Database

I’m using a MySQL database on my website to store albums and the photo/sub-photo relationships. I considered using the S3 tag feature for photo meta-data (caption, person tags, photo location, camera settings, etc.). But I decided to store that information in the MySQL database. This allowed me to do all the web code without needing the S3 APIs and will make it easier to switch from Amazon to a competitor if needed.

This database ended up being pretty similar to the existing gallery system, but I did add people, tags and camera data. I also moved the code that adds photos to the database from a PHP script on my website to my C# desktop photo software. I was having issues with old versions of PHP not being able to process some of my photos correctly.

AJAX

My old gallery used PHP to generate a static page with bits of javascript. This meant that the whole page loaded at once but could take a while to come up. It also made it more difficult to add javascript to the page. In the intervening years I’ve gotten used to making pages in HTML/javascript that make an AJAX call to a very basic PHP script which loads data from the DB and so I switched the gallery to use this method. It made all the code much cleaner and let me add nicer transitions and more javascript features. The page comes up quicker, but takes a bit longer to fully load the photos.

Future work

There are a couple features that I’d still like to add to the gallery system. The first is a more advanced search where you could look for specific people or limit the results by year. I’d also like to add a map to the album so that all the photos show up on the same map. It would also be nice if there was a way for people to download all the photos in an album at once.

Our group started playing this game at the beginning of the year and we’ve been surprised both by how much we’ve played it and that we are still enjoying it. The game has a fair amount of setup and piece moving so it is a good candidate for conversion. Converting it also allows it to play six players.

We have a couple house rules that I implemented as options in the game. The first is to make the game more interesting for more players. It seems like the “right” number of players is three. That means that players can add a card to their board every third roll. With four, five, and six players, I feel like I don’t have enough control and the “active” card powers are very weak. So we have an option for multiple players to be active and buy. In a four player game, we allow two players to use their active powers and buy and in a six player we allow either two or three.

The other house rule is a simplification of the game for kids. In this mode, all cards with abilities that need to be charged are removed.

There were a couple things that made the game difficult to convert. One was fitting all the cards onto the screen. For a six player game, I need to display 36 cards along the long edge of the screen. This means that each card gets 100 pixels. A lot of the cards have abilities spelled out in text and when I put that text into a 100 pixel card, it was too small to read. So I needed to create iconography for all of the abilities. I think that the icons and graphics came out pretty well. Players that already know the game like the icons better than the text. I haven’t had new players learn the game on the touch table yet, so hopefully it isn’t too confusing to them. The icons, and particularly the charge counters are still pretty small and can be hard to see on a standard monitor

The other difficulty for this game was making sure that all the players could take their rewards at the same time. This is how it works in the physical game (you just have to trust the other players to do it right) and I didn’t want the touch table version to slow that down. There are very rare situations where the order that the players perform actions matters and the computer version leaves it up to the players to act in the correct order in those cases. Normally I like to have the computer enforce all the rules, but I didn’t want to cause delays for something that happens less than once in five games.

I tried to use a new animation system for this game. My idea was to have a separate thread that does animations and the main event thread that is doing model updates would add animations to the animation thread. This worked great until I needed multiple animations running at the same time. When I ran into that problem (which is pretty common in this game since all the players can act at once), I backed out my new animation thread code and have the main thread kick off each animation in its own little thread.

There are a few problems with this system. The worst is that I still have timing issues caused by two events creating conflicting animations. I’ve reduced this issue by making the animations as small as possible, but it still caused problems during development. The other issue is that by combining animation code and model update code I’ve made all the code a little more complex.

I’m not sure what I’ll try for animation in my next project. If the game is linear (one player acts at a time), I’ll probably give the animation thread another try. But if it is more like this game I’ll probably just use this system again.

This game took 64 hours to create. I took a shortcut on the graphics and re-used a lot of my work from Galaxy Trucker. I spent more time testing this game, but the actual implementation went surprisingly smoothly.

I expected this to be a moderately large project, but it ended up being a little easier than I expected. I spent three weeks on it, putting in fairly long days because it was a fun project. This is the second Martin Wallace game that I’ve converted, and like Automobile, the game is complex, but doesn’t have hidden/unexpected complexity and was it fun to program because progress was constant. It ended up taking 70 hours which is really quick for a game that is considered as complex as Caverna or Terra Mystica – two of my longest projects.

One thing that saved me a lot of time was having done other games with similar mechanics. I was able to take a lot of the map and connection code from Concordia, and the web interface is a stripped down version of the Settlers interface.

Unfortunately Brass is only four player. It is also not very popular in my gaming group, so I don’t expect to get to play this conversion many times. Its probably going to be one of the games where I spend more man-hours converting it than it will have man-hours of play.

Board space was a big consideration for this project. The physical game takes a lot of space on a table:

To save space, I collapsed the player board down to display just the lowest level of each building. Players can touch their board to open up the stack of higher level buildings:

This saves a lot of table space and makes it possible to keep everything big enough to be legible on a 2K display. One thing that is still easier to see on the physical board are the resources on the built industry tiles. In the physical board game, the resources are cubes that sit on the otherwise flat map. Nothing on a screen will stand out like a real 3D cube, especially since I’m not using 3D effects like shadows.

The game has a web client where players connect to the game with their phone. The web interface shows the player’s their current cards and lets them pick one to play. In other games I’ve put game controls on the web interface, and players do like that system. However, it makes it harder for the rest of the players to see what the current player is doing. In games with web controls I end up having slower animations and a lot of voice saying what the current player is doing. To avoid that problem in this game, all the game controls are on the touch table, so players pick their card on their phone and then do everything else on the table.

Brass is a long game taking about 30 minutes per player to play. The table doesn’t change this a lot. There is just a lot of thinking time in this game, especially for inexperienced players. The touch version does save a lot of time, it’s just not a big percentage of the total. Having all the money and board setup/cleanup taken care of probably saves 15 minutes.

From a technical point of view, the big change for this game was the animation system. I’d tried it out in King Domino, but this was the first big game to use the new stand-alone animation system. I’d say the new system is an improvement, but is still not perfect. This game really stressed the animation system because it has a lot of the most difficult kinds of animation: where multiple model updates are happening at the same time and pieces are moving both to/from a location at the same time.

For example: A player builds an Iron mine. The player pays some money for the building, and buys some coal from the global market. Then the mine produces some iron which is sold back to the global market. In the model this all happens at once and causes three updates to the player’s money, two to the global market and adds the new building to the board with some of its iron sold. But it needs to animate one step at a time: Pay for the building, move the building to the board, pay for and animate the coal to the building, move the iron to the global market and animate gaining money from it. The new animation system means that I can push on each animation as it happens during the model update, but it doesn’t solve the other big problem of wanting to use the draw code during animations. When animating the first coal from the global market I’d like to use the market’s draw function to remove the bought coal. But if the global market does a re-draw, it will draw the newly sold iron before the animation has gotten to that step. So I end up writing extra code to incrementally re-draw the market for the animation and save the full redraw till all the animation is done. This causes duplicate code, so I don’t do it till I have to. But that causes its own problems as I have to re-visit old animation code that breaks as I add new animations and remove full re-draw calls.

I don’t think there is a perfect solution to the animation problem. In the next big game, I’m going to try to break up my draw functions into much smaller parts that can be called separately during animations and I’m going to be more aggressive about pausing model updates to allow animations to complete. I like to do all the model updates at once so that the player doesn’t have to wait for animations before doing their next action, but I’m going to move more towards making players wait.

This was a fairly short project, taking a couple weeks to do both games. I was able to use some of the code for tile placement and growing boards from Between two Cities. My main goal with this conversion was to make this four player game support six.

King Domino comes with enough tiles for 2-4 players. Queen domino is also 2-4 players with its own set of tiles. The games can be combined into a 5-6 player Queen Domino, but in my opinion, combining the games this way makes for a very long game with under-powered city tiles. So instead, I created extra tiles sets for each game to support up to six players. A six player game of Queen Domino is still a little to long, but it is faster on the touch table so it is still fun.

Another advantage of the touch table version is the scoring. It takes a while at the end of the game to score the board – especially in Queen Domino. Not only does the computer do this for us, but it displays the running score during the game so that you can see who is winning and get a feel for how much each tile/action helps you.

The conversion ended up being harder than I’d expected. Part of that was my expectations were unrealistic, but I also spent quite a bit of time on board layout and animations.

Board layout took a while because I was trying to maximize the size of the tiles. It didn’t really matter for King Domino, but in Queen domino there can be quite a bit of information displayed on a tile, so it needed to be as big as possible.

I tried out a new animation system for this game. I had a separate thread that handled all animation. The main thread would add animation routines/calls to the animation thread as things happened. This had the advantage of allowing me to created animations as the model was changed instead of isolating animation code in its own function. However, the actual animations still ran after all model updates, so the animation code didn’t have access to the old state of the model. This only became a problem when the model was updated multiple times before the animation got to run.

Overall I liked the new animation system well enough to continue to use it for my next game. This game had fairly simple animations, so I want to test the new system with a bigger game.

Galaxy trucker was fairly fun to implement. I’d expected the ship building part of the game to be difficult, but it came together quite quickly. Conversely, I underestimated the difficulty of everything else. The adventure cards were more difficult that I expected them to be. Most of the “new tech” tiles were OK, but hyperspace added a lot of complexity. I haven’t done a line of code count, but I’m up to 160 hours on the game.

I’m pretty happy with how the game turned out. I think that the ship building works well; I feel like the graphics are some of my best; and the computer version saves a lot of time in setup.

When considering this game for conversion, my main concern was the ship building. In the physical game, players pull face-down square tiles from the center, flip them over to reveal the tile, then add them to their ship by orienting them and matching existing connectors, or return them to the center. This is a very physical experience and is done quickly because the players are racing against each other to build their ships. I implemented this with a button for each player to draw a new tile, dragging the tile into position, and tapping to rotate it. The button to draw a new tile can only be pressed every couple seconds to simulate the time it takes to reach out, get a tile and put it back. Drawing or grabbing a new tiles returns the old one. When a tile is put back in the center, any player can drag it over to their board. All this works pretty well and it still feels like you are building a ship.

A couple things make this game better to play on the table. One is how quick it is to setup and tear down. There are a lot of tiles, astronauts, cargo, battery markers, etc. The tiles all need shuffled and arranged face down between each round and setting up the adventure deck isn’t trivial. The second big advantage is that the strength of each aspect of player’s ships is always displayed. There is an adventure card called the “combat zone” where players compare an aspect of their ship with each other. This involves a lot of counting to find the base strength and the maximum strength with batteries for each ship.

The part of this conversion that I am least happy with is the animation. I’ve been unhappy with how I do animations for the past year. The system that I use has significant advantages:

• animations are separate from the game logic so that during loading/undo I can easily skip all animation
• the draw functions are easy because they just draw the game state as it is.

But there are problems too.

• I have to be very careful about when things get drawn. Because the game logic is all separate from animation, when the player does something, the game model is updated immediately. And since the draw functions just draw the model as-is, if I call draw too soon, the GUI will be updated to new values/state before the animation is complete.
• To do animation separate from model updates, I often have to store a bunch of information so that I can animate what happened.
• I’ve been using a state machine for most of the game logic, while the animation code is part of the event system. So the event system will ask the state to animate what just happened, but that means that I need to keep track of all the states that were pushed/popped to the state stack during an event so that they can each animate.

I’m not sure what the solution is, but I think that in my next game I’m going to try creating a separate animation timeline. Currently, I have an event timeline. When players act, events are added to the timeline and executed in order. Events do the animation when they are done and can force a delay before the next event will be processed. I’ll use the same code for an animation timeline. As events (or the states) update the model, they will add little animations to the animation timeline which will get executed in order. During a reload/undo I’ll skip processing the animation timeline. I’m hoping that by formalizing animations as a time sequence I’ll have less trouble with the timing of draw calls and that by adding the animations during the model update I can avoid storing extra data needed for animation

But I’m glad that I finished it. The conversion plays well and it adds another relatively easy 7 player game to the touch table.

In the board game, players cooperate with their neighbors to build a city between each set of two players. Each round the players pick two tiles and add one to each adjacent city. You want the best cities, but your score is the lower of the two cities you worked on, so you need to keep your cities balanced.

Each type of tile has unique effects and is scored differently. Shops want to be in a line, offices want to be near entertainment, houses want a variety of tile types and don’t want to be next to a factory, etc.

All the tiles are 1×1 except in the middle round where the tiles are 2×1 or 1×2. It can be difficult to find a good tile and position in the second round.

The Capitals expansion adds a “Civics” tile that wants to be near two types and wants to avoid a third type. It also adds points for having the city with the largest “districts”. A district is made up of adjacent tiles of two types. This adds several new considerations for which tiles to pick and where to place them.

There is hidden information in this game (the tiles are hidden while you are selecting the two you want to place) so I created a web interface. I’m still happy using the React framework for building web pages.

There were two things that made this project difficult. The first was the non-standard board. A player interacts with the cities that are between the players instead of with their own pieces and a central board. The second was how the cities are built. Tiles can be placed anywhere adjacent to existing tiles. The only limit is that the city needs to end up being 5×5. So the play area grows out from the initial tile. I ended up creating an 8×8 model where the player only fills in part of the area. The display shows just the part of the city that has tiles. I also had a hard time with the wide/tall tiles. I think that the source of the trouble was not spending enough time thinking through and designing the way tiles would be modeled and moved before I started writing code. I wrote code for the first round where tiles are 1×1 and then forced the wide/tall tiles to fit into that pattern.

I’m not sure why it took me so long to complete this project. I did take a vacation in the middle of the project, but there was also a 10 day period where I was home but didn’t work on it at all, and even when I was working I was only putting in 2-3 hours a day. I definitely felt less excited about this project. I suspect that it was a mix of feeling lukewarm about the game itself and feeling like it should be easier than it was.

The best part of the converted version is how much time is saved scoring the cities. The scoring rules are fairly complex (especially with the Capitals expansion) and it is nice to have the score calculated quickly and correctly. I also display the score of the cities during the game to help the players to balance their cities:

It ended up being a larger project than I expected, but I’m pretty happy with the game.

Why Settlers

Settlers is a game that we played many, many times when we were just getting into board games. We really enjoyed the game and bought the Seafarers and Cities and Knights expansions along with the 5/6 player expansions for all three games.

I’ve made a “Settlers Helper” app at least three times in different languages. The app would help to build a random but fair board and to reduce the randomness of the dice.

But as we got new games and different players in our game group, we’ve played Settlers less and less. So it has never been a high priority for conversion – especially because it has hidden information and is fairly complex.

But we’ve converted all the low hanging fruit and I’ve been running out of things that I really want on the table. When I picked Settlers, the other games I was considering were Brass and Age of Steam. These are both relatively complex/difficult games that are also not played very often. Brass is only four player and Age of Steam has had two new version released since we bought our copy making it tough to know what rule set to implement.

Issues

Settlers ended up being more complex than I imagined and has turned out to be one of the largest games that I’ve converted. Settlers and Seafarers took 100 hours and Cities and Knights took another 100+. Part of the complexity is the board. I’ve done hexes before, most recently in Terra Mystica. But Setters has an especially complex map because the model has to include the hexes, the vertices and the edges. All three parts can be selected and have elements and state. There are also somewhat complex rules for building and the calculation of the “longest road” is a bit messy. Along with the map, the other complexity is all the progress cards in Cities and Knights.

So one issue was underestimating the complexity. This lead to one re-factoring to fix some classes that were getting too big. I also had to do some re-work and re-testing of base Settlers and Seafarers when I implemented Cities and Knights. I also spent too long manually creating maps before writing a map editor.

Another issue was animation. I still haven’t found a pattern/system that I am 100% happy with. It is getting better, but on my next game I might try some event/listener driven GUI updates for things like the scoreboard, status icons and buttons.

What worked

Settlers has been implemented by several different companies – mostly for online play. So I had several places to look for interface ideas. Most useful was the Xbox trading implementation.

The state machine system that I used in Notre Dame worked quite well. With the state machine pattern, I still use the Timeline and Events to handle player interaction, but those classes mostly just tell the state machine what the players did. The state machine then updates the game and player models and the state of the game.

Settlers, and particularly Cities and Knights, has fairly complex state and I was able to re-use states for multiple scenarios.

Another part of states that worked really well was for highlighting possible actions on the map. In Terra Mystica, my MapGUI class had a huge if/then/else tree for detecting what parts of the map to draw and highlight. In Settlers, there was still some special code, but in general, the state could tell the map what hex/vertex/edge was clickable or highlighted.

The react based web page continues to work well. The react class system kept the different pages manageable and let me re-use some code for drawing resources and resource up/down dials. On the server side, I re-used the WebState system that I’ve used for the last few web games. The timeline events and game state can send a WebState to a particular client. This WebState is sent out over the web socket and also stored. If the player refreshes their page or disconnects and reconnects, the server can re-send the last state. The web clients hold almost no state/logic of their own and can be re-built from the WebState data.

Finally, making a map editor was a good decision. It took a little time to write, but saved me a lot of tedious and error prone data entry. Looking back on it, I probably should have made a map editor for Concordia.

Implementation

There were several interesting things about implementing this game that may be useful in future projects.

Web interface

The action cards are private, and while I probably could have just put them on the touch table, I used React to build a web page to display them and other decisions. I didn’t do anything new with the web interface for this game.

I also kept the “State” design pattern from Broom Service. When the game sends something to a web client, it keeps track of that message to easily handle client disconnects and other errors.

By reusing a lot of the web code and design from Broom Service I saved quite a bit of effort.

Simultaneous play

In Notre Dame, it is common for players to act semi-simultaneously. The game is technically turn based, and each player is supposed to act in order; but in practice there is not a lot of interaction between the players and people take advantage of that to speed up the game by overlapping their turns.

I didn’t want the touch table version to slow down play by making everyone wait for their turn, so I allow players to act out of turn when possible. The game still keeps track of the real turn order and enforces it when the player’s actions might affect others.

Accepting actions out of order didn’t really make the game logic more complex, but it did complicate undo. Our normal event system uses a global stack of events (actions and game flow events). Undo removes the last action and re-executes the whole stack. But with player’s acting out of order, a player may want to undo their action, possibly without even noticing that another player or players have taken actions. To allow this, I created a per-player undo button. I implemented it in a similar way to Caverna. The player undo finds the last action taken by the player and removes it from the list of events, then re-executes all the events. The difficult part was separating the cases where that would cause problems and turning off the undo button in those situations.

State Machine

In the last few games, I’ve been experimenting with different ways to model the game state. In this game I went all-in on state modeling and implemented a per-player state machine. The player model has a stack of PlayerState classes to track what state the player is in (ie: played action card, selecting new district for friend. Or hired personality, selected garage, moving car). Each state class in the stack knows which know which parts of the player interface to enable/disable and can handle player input. The state classes update the game model when the players take actions and tell the GUI what to animate.

The state classes basically replace the functionality that used to live in the events. Now the events just ask the current state to handle the input. So all game logic is still done within an event execution, but it is the state doing the work instead of the event.

This design worked quite well for this game. In Notre Dame, the state is fairly complex: like Broom Service, actions can trigger other actions. The stack never gets quite as deep as Broom service, but there are a much wider variety of actions. Another thing that made this design work well is that there are very few distinct player actions. Most of the time players are either selecting a worker or a region. The effect of that selection depends on the current state of the game, but having very few actions means that the states only have to have a couple functions for handling player actions.

Complexity

Notre Dame ended up taking about 90 hours. The game doesn’t seem that complicated when you are playing it and I originally thought that it would be a 40 hour game. But when I read the rules with conversion in mind I realized that it was going to be a large project.

Adding to the complexity, I implemented two expansions for the game that add more “personality cards”. Many of these cards end up being special cases with custom code.

Final thoughts

I’m pretty happy with this conversion. The simultaneous play keeps the game moving, and I don’t have to worry about other players making a mistake on their turn when I’m not paying attention.

I’m also happy with the web interface and state machine designs that I used in this game and hope that they will be useful in the future.

Since writing that program I’ve come back to it every few years to put in more recent data and make improvements. Once my spouse and I got married, I took out a bunch of code that split expenses and taxes between the two of us.

A few months ago I decided to give the program a full makeover and add features to make it useful to more people. The original program was very specific to our situation and didn’t handle account types, expenses, and investments that we didn’t have. Along with adding new features, I needed to make the program much more user friendly and error tolerant.

I’ve completed this project, and the program (and source) are available for download. It still doesn’t handle nearly as many situations as I’d like, and it has very little support for people who are still working, but it is good enough to release.

Motivations

Our brokerage offered us access to their retirement planning product called “Money Guide Pro”. In some ways it is very similar to my program: it uses a Monte Carlo market simulation; it requires you to input assets, expenses, and retirement goals; and it presents the results as a probability of success. There are also some big differences: they handle a wide variety of situations that my program doesn’t; their program runs as a web app; and most importantly their program isn’t available unless you have a financial adviser working with you. I couldn’t find out how much companies like Money Guide Pro charge brokerages for access to the program, but it certainly isn’t free, and the inner workings are proprietary. While my broker was pretty low pressure, the broker’s goal is to use the program to sell management services or annuities.

The results from the professional software were very similar to my program which gave me a little more confidence in my approach. After looking around the web, I didn’t see any other products that were already doing what my program did, and I have the flexibility to release the software for free and make the source code public.

Development

New features

For this release I added a bunch of new features to the program:

• Singles or couples
• Legacy planing
• Medical expenses can be set to grow faster than inflation
• Medicare replaces private insurance at age 65
• Added equal lifetime payments to IRAs
• Added annuities, pensions and HSA accounts
• Added the ability to buy property during the simulation
• Inheritance – benefactors have their own life expectancy model and you can set which member of the couple is the beneficiary
• Calculates your optimal Social security start age – but starts early if you need the money
• More control of how the external markets are modeled
• More simulation outcomes – high wealth/success/success with reduced expenses/success with property sales/success with failed legacy goals or purchases/failures
• Quick sim capability to make a tweak and get a quick result.
• Stress test against historical scenarios
• Better tax model – includes social security and the brackets and deduction amounts can be set on the GUI
• Multiple save files.

Language and libraries

The original program was written in a mix of managed and native C++ using Mircosoft’s C++/CLI platform. I’ve had issues over the years getting my code to build in the latest versions of Visual Studio, and I’m not thrilled with the level of support for C++/CLI from Microsoft (they are pushing Metro App development). But between the reuse codebase and the advantages of C++/CLI, I decided to stick with it. C++/CLI allows you to write either managed C++ that acts a lot like C# and gives you access to the .NET libraries, or native C++ where you manage your own memory, have access to STL and BOOST, and get the performance advantage of native C++. The drawback of this mix is that the managed C++ uses funky looking symbols (^ is roughly *, and % is roughly &, gcnew instead of new) and doesn’t have good lambda function support. It is also a big pain moving data back and forth from managed data structures to native data structures.

The GUI in my program is all built on the Windows.Forms part of the .NET library. So all the GUI is managed code. Since the GUI often directly manipulates the data model, the model that backs the GUI is mostly built on the .NET System.Data.DataSet class and is managed. But, I want the simulation to run fast, so that part is written in native C++. At the start of a run, the managed data model is copied into native C++ classes.

Along with the hassle of managed C++, this was also the first C++ project that I have worked on for several years and I’ve really grown accustomed to the conveniences of C# and the LINQ extensions. Writing constructors, copy constructors, destructors and member accessors is a lot of code overhead that I’d gotten used to not having to write.

I used the C++ library Boost for random number generation and the normal and student’s t distribution. I also used the .NET charting library for all the plots and graphs.

Documentation

Another large task in this project was to write documentation for how to use the program and to describe how the simulation works.

Amount of work

At 111 hours, this update to SimRetirement has taken as long as a large touch table game. I don’t know how long I spent on the original program. Probably a similar amount of time. I spent a lot more time doing research for the first version of the program. Deciding how to model the stock market and other market variables took a long time.

The majority of the lines of code are for the GUI. Of those 75% are generated by the GUI builder.

This project also required a lot of data. I use historical data for several of the “Market” tab plots. I also include data that is used by the model for life expectancy and social security calculations. I store all this data as XML. There are 1490 lines of this kind of data.

Unlike a touch game, this project required basically no art assets. Besides the icon, I didn’t need any graphics. All the charts and graphics in the program are from the .NET Data.Charting library.

Release

I’ve released the program and source code for download on my website. I’ll also post it to reddit in some of the personal finance subs. But I don’t expect to see much interest in the program. I think that it would be useful to people, but it is really difficult to find things like this program on the internet today.

While there’s a nearly unlimited market for phone and web apps, the market for desktop applications is really struggling. There isn’t nearly as much demand as there once was, and the process of discovering desktop software is broken.

We once relied on shareware aggregation websites where people looking for software could search both free and pay software. Sites like tucows and freewarefiles used to be the first stop when trying to find software. With the rise of Google, those sites have become an afterthought and many of them have turned into ad-burdened cesspits of low-quality and/or trial software. Today there isn’t something like the Play Store for desktop software, and searching for shareware/freeware on Google is frustrating (mostly due to shady SEOed sites selling software).

Village has an interesting mechanic where you manage the life and death of your workers. All your workers start as farmers and can be trained as specialists. Actions take “time” to perform, and when enough “time” has passed, a worker dies. A limited number of each type of worker is rewarded with fame and victory points upon death while the rest get an anonymous grave. The key is making the best use of your workers and their time while  trying to arrange a good death.

This game was similar in size to Age of Discovery. There were two parts of this project that were time consuming. The first was just the number of different actions that a player can take on their turn. There were just lots of (relatively easy) cases to implement. The second difficulty was for the “Inn” expansion. That expansion added a lot of unique cards to the game that the players can buy and use. Each card needed to be coded. So again, a lot of fairly simple cases to implement.

I was able to re-use all the standard code, along with my map code from Concordia.

As you can see, the screen is pretty full. The game takes up a lot of room on the table too. It felt like I spent more time than average laying out the graphics for this game. Honestly though, it always takes a long time to do the graphics for a game. It used to be something that I really disliked, but as I get used to Photoshop and Unity, I’m enjoying it more. Now my least favorite part of the game is audio and animations.

Game state

I used our standard event system to perform the actions in this game. The event system is great, but doesn’t really help with managing game state.

In most games I have an enumeration of game states, and data about the state of the game is stored in either the player or game class. This works well for games with relatively simple state. After doing Age of Discovery, I knew that it would have been better to have a full state machine or at least a set of state classes. I haven’t done that for any of my games, so I decided to try it out for this one.

I didn’t make a full state machine, but I did make a set of classes to store what state the game is in and any data that I need about that state. When I had an enumeration, it was easy to check what state the game was it. I had lots of code that looked like:

if ( Game.theGame.CurrentState == Game.StateType.PickAction &&
     Game.theGame.ActionArea == Game.ActionType.Travel)

Now that I was keeping a stack of classes to represent the state, I was going to have code that looked like

if ( Game.theGame.StateStack.Count > 0 && Game.theGame.StateStack[0] is GS_PickAction &&
     (Game.theGame.StateStack[0] as GS_PickAction).ActionArea == GS_PickAction.ActionType.Travel )

That may not look like a big difference, but I ended up writing a line of code similar to that 125 times in this project. So to save some typing, I added some templated convenience functions and ended up with if checks that looked like:

if ( Game.theGame.isCurrentState<GS_PickAction() &&
     Game.theGame.CurrentState<GS_PickAction>().ActionArea == GS_PickAction.ActionType.Travel )

I think that having state classes is probably a good idea. It keeps the model code cleaner since I don’t have to keep adding member variables for storing state details.

For Village, I made events that were not state dependent but were instead action dependent. So instead of having an event for picking a worker to kill, picking a worker to train, and picking a worker to activate, I had one event called PSelectWorker that then checked the state of the game and did different things.

Unfortunately, that made my events grow larger and larger as I added each part of the game. The event classes ended up being too complex and difficult to maintain. Instead, I should have put a lot of the event functionality into the state classes. So I’d still have a PSelectWorker event, but the event would then ask the current state to handle the selection of a worker.

Next game I will try this method.

Hours and Lines of Code

At 85 hours, Village is a standard “large” project. This is probably my favorite length for a project. It is long enough to feel like a big game and have interesting challenges, but not big enough so that I start forgetting how I implemented things in the middle of the project.

I was able to reuse some art assets from other games and the rest of the assets were fairly easy to find. As usual, I used thenounproject for most of the art and Unity assets for the audio.

To get an estimate for the lines of code created by Unity for GUI layout, I estimated that each hour of coding created 87 lines of new code. At that rate, the time I spent on the GUI would be 2443 lines of code. So the GUI layout and Coding tasks are further broken down by what type of code they create:

At 5847 lines of code and 85 hours, this project was very similar in size to Age of Discovery. That makes it a large game – maybe a bit larger than I expected it to be. But not nearly as large as a very complex game like Caverna or Terra Mystica.

It is also really nice to be able to re-use so much from other projects. I started the GUI for this project by copying the layout from Age of Discovery. This gave me a lot of the main menu, camera, canvases and controller setup for free. But I did have to spend a bit of time cleaning up the rest of the GUI.