This chapter describes problems we had to solve early in development of KaM Remake. The project was a closely guarded secret for the first few months, we had to make sure we could solve problems before we would announce the project publicly (or abandon it otherwise).
We had to choose a name for our yet secret project. Catchy “OpenKaM” name was already taken so I had to come up with something different. Something easy to write and spell, implying that it is going to be open-source and complete rewrite from scratch. I did not wanted to change the games title to something new though, KaM2 was out of question as well, because it was still a remake of the original, not a new game. Long story short – KaM Remake was the title that fit well.
Due to secrecy of development I had to come with some codename until it goes public, that was CastlesAnd.. or spelled differently – castleSand. That was the name I used to register an SVN account at Google Code. That was on 23 of April in 2008. The same moment our official revision counter began (however we had like 100 hundred commits before that between me and Alex, but for simplicity sake we omit that).
SVN is one of the greatest things invented in application development. It keeps track on every file change and makes it easy to work collaboratively by keeping a copy of project online and accessible to all developers, it let’s them add or change the code there in turns keeping the data integrity. If ever comes a need you can revert parts of the project steps back and see which exact change has caused some effect.
Even then, when remaking the game seemed like an impossible thing to do, I had estimated that it would take ~2 years to complete (or to cancel).
Estimated project completion time meant that the game had to run on weak PCs of that time. This idea and exaggerated TKE system requirements made me choose a simple path – KaM Remake should be acceptably playable on my old PC (Pentium II 466Mhz, 256mb RAM, OpenGL 1.1 compliant GPU). Back then that was still a decent PC.
Alex made architectural skeleton of OOP classes and dependencies that we kept using and expanding ever since. Even today many parts of that design are unchanged – so well they were planned. However skilled in programming, but he was not a keen KaM player. I still remember one of the funny things that he coded – he did not remembered how units were trained in KaM and he had programmed that like in Warcraft, as if player had global reserve of gold and hiring a unit would subtract 100 gold and spawn a unit in the game 
We had debates about how the game should handle all the interactions inside. Should it be a centralized state-machine or a multitude of individual agents exchanging with events (event-driven design). First way offers more control over the game and is easier to maintain, but the second is more versatile and unit-oriented. We had chosen centralized-state machine and have not regretted about it ever since. After all clear code is much more important than clever complicated concepts behind. Nowadays we had added some events here and there that fit well into the system, they compliment the state-machine in a good way.
I still think that it was Alex who made the biggest impact on KaM Remakes early progress. He was with the project in its first days, planning from scratch in a clear field – that is priceless.
To be continued …