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.

Getting setup at Digital Ocean was easy. One of their preconfigured machine setups is a LAMP (Linux, Apache, MySql, PHP) server which is what NextCloud needs. I had to setup SSH keys, had to install a couple extra PHP packages, and make some apache configuration changes for NextCloud. Doing the NextCloud migration was a bit of a hassle, but that was a NextCloud issue.

Since setting up NextCloud, I’ve also built a stand-alone web app on this server. To do that I installed GIT and the SSH plugin for Visual Studio Code so that I could develop right on the Digital Ocean server, but also have source control and a backup on my home machine.

Everything has been pretty simple and convenient. Their monitoring tools are adequate for diagnosing performance issues and their billing is automatic. I do need to log in occasionally to do software updates, but I was having to do that for my local server anyway. Overall I’m pretty happy and will probably move chadweisshaar.com over to them eventually. I “just” need to re-write my gallery webpage to use AWS instead of storing the photos locally.

Not having a home linux server does have some downsides. For one, it was just cool to have part of the internet in my house. But I also used the server to run my own DHCP and DNS. I had an ad blocking DNS server for my phone and also allowed me to create some short urls (like tt.com) for friends to use to connect to the touch table. I miss both of these capabilities.

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.

As you can see from the screenshot above, there is a lot going on in this game. Here is what the original board game looks like:

I put more text on the screen than I usually do in a board game conversion because we don’t play this game very frequently and I expect to need more rule reminders than usual. The three colored boxes on the lower right corner of the screen (bronze/silver/gold with hearts) are where the supply/demand helper lives. The computer is displaying how many cars of each of the three types have been produced, how many dealers and dealer slots there are and how much public demand there is expected to be.

The center area of the board shows the different models of cars and replaces the ring of car models in the original board game. The ring arrangement is actually a bit more intuitive, but this layout made it much easier to arrange the rest of the elements. In the computer version, the display changes depending if the model is currently under production, closed or yet to be opened. If a model is still available, I show a summary of the costs of that square and a quick comparison of the present supply and future demand for that model. When a factory is in operation, I display the built factories, cars and what the player would get if they closed the plant. Once a plant is closed, I show a “balance sheet” for that model.

I am very happy with how this conversion turned out. I think that the computer version plays well and displays a lot of information for the players without obfuscating the underlying mechanics of the game. It is too bad that we probably wont play it very often, because it does improve the game play and cuts the play time by nearly half.

This is the first big game that I’ve made after upgrading to a 4K TV to play the games on. I put more elements on the screen and probably made the text a little smaller than I would have if I’d been designing primarily for 1080p. I still want to be able to play the games on a 1080p screen, and all the text can still be read at 1080, but it is significantly nicer at 4K.

This project was also a lot of fun to work on. It took quite a bit of time (70 hours), but a lot of that time was making player aids, summary charts and optimizing the graphics/layout/animations. I went back to a simple state model for this game after the complex state of Notre Dame. But I’ll probably go back to the state machine implementation for my next large game.

I made a slight improvement to the event engine for this game. When the player takes an action it creates an event which updates the model and then does any animation needed. The animation function returns a number of seconds that the game should “wait” before accepting any more player actions. Usually that wait time is either zero or a constant. But other times it depends on how much animation is needed. This game had some complex animations and so I added a new capability to the event system itself. The old system looked like this:

IEnumerator mainLoop()
{
  while (true)
  {
    wait for an event
    event.do();
    yield return new WaitForSeconds(event.act());
  }
}

This would pause processing events till the animation was complete, but required event.act() to return the animation duration. The new system allows the animation to perform its own wait calls:
IEnumerator mainLoop()
{
  while (true)
  {
    wait for an event
    event.do();
    for (var iter = event.actCoroutine(); iter.HasNext())
      yield return new iter.Current();
  }
}
IEnumerator Event::actCoroutine()
{
  // do animation with interspersed yield return Wait calls
}

In the real code, I kept both act() and actCoroutine() as options by using reflection to detect which function the event implemented.
]]>
					
					https://blog.chadweisshaar.com/2018/03/20/touch-table-automobile/feed/
			1
		
		
			
		
		
		https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/
					https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/#comments
		
		
		Sun, 25 Feb 2018 15:25:03 +0000
				
		
		
		
		
		
		http://gator3305.temp.domains/~cweissha/blog/?p=1452

					Continue reading "Touch table Azul and Medici card game"]]>
										I made two small games for the touch table: Azul and the Medici Card Game. Azul is a tile placement game that was published recently and that I played at our last game day. The Medici card game is a variant of Medici that makes the game a bit simpler by removing the auction aspect. This does introduce a bit more luck, but Medici was already a bit random and the new version plays much faster.

I didn’t track the amount of time it took to make either of these games. Azul was about 20 hours and Medici was about 12. Medici was so quick because I re-used almost all of the original Medici.
Azul took a little more time than I expected it to. I had to redo the player interface a couple of times and the logic for handling situations where tiles can’t be placed onto the grid were more complex than I expected. The root of the problem was that I wrote the game without really thinking through the option of playing on a free board. When I went back to include that option, I had to make a lot of changes.
]]>
					
					https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/feed/
			1