The Treasure of the Pirate King

I just found the short blog I wrote while developing this video board game. That's what got me started learning Python development. I had an idea for a board game and wanted to test it on a large scale to see if it was balanced. Learning Python sounded like fun for that purpose. I read Gérard Swinnen's GNU-licensed book about Python programming and learned the basics out of pure curiosity. Back then, I had no idea how much Python would change my life by opening the door to a new passion and profession.

Getting started - 2013-02-26

Now that I have planned the game, the first step is to create the pathfinding algorithm. I created a class that renders the board, as well as a method that calculates the possible target spaces the player can land on. I also added a method that adds a wind modifier to the rolled value. For now, it's just a stub that returns a modifier of 0.

Running Python scripts from Notepad++ - 2013-02-28

So far, I've always run my code with Idle, the editor bundled with the Python distributions. But I miss the flexibility of Notepad++ from it. Now, I took a deep breath and configured Np++ to get the script running capability. The steps I took were:

1. I installed NPPExec plugin under the Plugin manager in the Extensions menu.
2. In the Extensions menu Execute... option I save the following to commands:

    d:\userapps\Python33\python -u -i

    d:\userapps\Python33\python -u -i $(FULL_CURRENT_PATH)

I also set to start the console automatically once NP++ launches and start the Python interpreter inside under Extensions / NPPExec menu / Advanced options... This way I'll always have a Python console to experiment. And I can launch the script I edit by pressing F6.

Language module - 2013-03-06

I'm done with the language selector part of the game. Language resources won't be part of the code but are stored in simple XMLs so they can be extended even without any development experience.

I also wrote the settings save/load part to preserve the player's configuration preferences between sessions.

Porting - 2013-03-10

The language, I use to write the program, has two competing versions. Python 3 is definitely the future, but plenty of packages only support Python 2. For example, I can't find a suitable package to display vector-graphic images in TkInter. If I find only a Python 2 module for the purpose, I'll have to upgrade that for Python 3 myself. It's cool that there 2to3.py exists, but I wonder if a greenhorn like me can use it to convert full packages without breaking them.

The game board - 2013-03-12

It's done. It seems vector graphic rendering is not supported under TkInter. The solution I've found would have multiplied the game's size tenfold, so I scrapped the idea. It still looks great. The trade-off is that I have to pre-render the graphical assets to the highest resolution and that will cap the game to 1920×1080. Of course, I can reexport them later once the higher resolutions displays are more common. Everything else besides the pngs scales dynamically. For lower resolutions downscaling is easy at game load and on resolution change.

Stubborn error - 2013-03-18

I've found an error. But not in my code this time.

Since I started using a dropdown widget from the Ttk package, my app has been started throwing an exception on exit. I could simply suppress it, but I hate to ignore problems. I recreated the issue in a sample code and uploaded it to Stackowerflow. The community helped me to overcome the issue in properly.

Saving module - 2013-03-25

This is finished too. It will do the writing and reading operations.

As it can be seen in the image below, the test method passes the data of the three players to the class that serializes it, than starts the saving process.

As a next step, we create a new instance of the data manager class, load the data back from the saved XML and print it. The content of the data as well as its structure will remain the same. Using XML helps me during the development because I can easily create saves with corner cases.

The last 18 days - 2013-04-12

Since my last update, I progressed with baby steps only. But many small steps together mean a lot of progress:

• The method for calculating the wind modifier is ready. Wind direction changes and influences the possible movement of ships similarly to real wind. Displaying the current wind speed and direction is also complete.
• The GUI now shows the player's wealth and crew.
• The cities are partially complete. You can hire new crew members and buy larger ships.
• The saving/loading module has been updated to keep track of the changes. It also saves info such as the number of turns left to skip, and the number of sailors that can be hired in the ports. The number of ships sunk by each player is also recorded.
• The turn skip mechanics have been implemented.
• All ship types are implemented (schooner, brig and frigate).
• Fixed some bugs (e.g. a phantom board appearing after starting a second game, then changing the resolution; the player can't stay in the port if roll less than three, etc.)

Event cards - 2013-04-24

Once I've finished the cities, it was time to focus on the event and treasure cards. On the board game version players draw cards from these two decks at different times. In the video game version they are pulled and applied automatically. Players are only informed about the cards, and can take actions when decisions must be made.

Now, the cards are shuffled and shown randomly. The next step is to implement saving and loading the state of drawing decks and the discard piles. Then I'll continue with the actual implementation of the events.

Battle - 2013-06-01

Over the past month, I haven't had enough time or energy to continue developing the game as much as I would have liked, but I won't give up on the project. I'm working on the battle module, which is the most complex remaining task. The fight mechanics are working, and you can assign sailors to different locations on the ship. You can win or lose. The only pieces missing are the skills that would make battles more tactical and interesting.

Memory leak - 2013-07-12

I'm done with the battle implementation, but there's still much to be done. Progress isn't always visible or exciting. However, small, boring steps are important, too.

I experienced something interesting last week. I noticed in Task Manager that, whenever I load a saved state, the amount of RAM used by the game increases. I ran a quick test and discovered that the increase was caused by the graphical content. The memory claimed by the images is not released until the game uses more than half a GB. Considering that 30-40 MB is required to play a single party, that's way too much.

I went through the code and found no leaks, so I posted the whole situation on Stackoverflow. I was relieved by the answers. It seems it isn't a memory leak, but the way how Python and Windows minimizes the effort of returning and reclaiming the memory once allocated.

Windows - 2013-07-17

I encountered a strange issue. I wanted to prevent players from closing the battle screen. I added a penalty for doing so, as well as a brief warning message. However, when the warning is displayed, the battle window ends up behind the main window. Therefore, even if the player chooses not to leave, they will no longer be able to find the battle.

I couldn't find a solution to this problem on Google because I couldn't come up with the right keywords. So, I wrote a small test app to recreate the issue with Windows Alpha, Beta, and Gamma. While doing so, I found the solution. The warning message's parent was the main window instead of the battle screen. Cleaning up the hierarchy fixed the problem.

Past 80% - 2013-08-26

As it says in the title, the game is more than 80% complete. I've reimplemented the classes that display the cards, and half of the card events have been implemented. However, that was the simpler half, as 30 treasure cards and 20 battle cards have the same functionality, differing only in their arguments. It will take a while to complete the full game, but we're getting closer.

I never finished the game. Later, I rewrote the entire game from scratch to simplify it and clean up the code. Through these two development processes, I learned a lot about clean coding. I improved my use of scopes, namespaces, data classes, and states. I also improved my unit testing and project management skills. The second time around, I got further, up to ~95%. But I still haven't finished it. Yet. 😉