KaM Remake github location

KaM Remake SVN was successfully reorganized (details in previous article) and moved to GitHub (GH). The new official KaM Remake repository address is:

https://github.com/Kromster80/kam_remake

Issues/Bugs were not ported, because I could not find the right script (and because they are largely outdated at GC). We track KMR bugs in our custom format in \todo\ folder. GH issues system looks nice, so hopefully we will use it more than GC.

Wiki articles were ported, but they need their markup to be fixed, due to different flavor of markup languages used by GC and GH.

All in all migration was time-consuming more than painful. GC repo is closed with a redirect link now. So let’s hope GH becomes comfy reliable new home for KaM Remake.

Posted in News | Leave a comment

Perils of converting from SVN to Git

KaM Remake was started almost 7 years ago now and at that time I had little knowledge of SVN. No wonder that KMR repository was created flawed. It missed “trunk/branches/tags” folders, which are an industry standard for SVN repositories. We have added them only few years later (in 2011). That did not mattered until now, when we need to migrate from Google Code and that is a good time to switch to Git. Problem is – Git import tools don’t like unusual SVN repositories, like ours.  That means we need to go back in time and fix the KaM Remake repository.

Thanks to simple SVN tools that can dump whole repo in editable text format, restoring SVN structure seems to be working well. I’m splitting the repo into pieces and rearranging them so that now creation of “trunk” folder happens in r1 instead of r1641. That shifts all rev numbers by 1, but luckily I was able to find an early pair of revs I can join into one (r25 and r26). And instead of r1640 that created the trunk I’m inserting a placeholder rev.

Old chain:
r1..r25
r26
r27..r1639
r1640 trunk created
r1641..

New chain
r1 trunk created
r2..r26 known previously as r1..r25, old r26 adjoined with old r25
r27..r1639 as they were
r1640 placeholder rev inserted
r1641.. as they were

That gives us perfectly valid repository meeting required standards. Spent around 1 day on that.

As part of conversion we need a list of all the authors who commit to KMR repository with their emails. We have 15 different authors registered. Finding their emails took another 2,5 hours.

Upcoming perils are due to conversion process. Git cannot work with latest SVN repositories directly. Giving error

Expected FS format ‘2’; found format ‘6’

That is solved by starting local svn server pointing to the SVN repository, so now Git has to work not with a file:///C:/PathToRepo/ path, but a svn://localhost/. 2 days of research trial and error.

Now git cloning is rolling in background, happily processing 1 revision in 2-5 seconds. Which gives us 6740 * 3,5sec ~= 6,5 hours of machine time.

Hope that will work out now 🙂

Posted in Development | Leave a comment

KaM Remake repository is planned to move to GitHub in near future

A few days ago Google announced that Google Code (GC) project hosting is going to be closed (just like many other services Google has closed in the past, like Reader, Wave, Labs, etc..). GC will function as normal till 25 August, after that it becomes read-only and somewhere around December it’s planned to close. That means that KaM Remake needs to migrate to a new project hosting ground. Best one I know of so far is GitHub (GH).

Issues:
– Migrate repository from GC to GH. Doable. Thanks to automatic import. However there are problems.
– First ~1600 commits revision history is lost, they all are merged into one.
– We loose revision numbers in general, since Git does not rely on commits numbering, every commit is marked with a small hash. We can sort of rely on total commits count instead (should be the same thing?).
– It is yet unclear how project committers info is linked, since after import GH does not show project members in web interface. Should be doable.
– Git is generally more complicated than SVN. I’m not experienced with it, so it might need some time to get used to.

On the brighter side:
– It is easier to suggest code/resource changes through GH web interface. Creating a Pull Request is a matter of minutes.
– Integrated issue tracking seems to be more advanced and handy

New test repo is available at: https://github.com/Kromster80/kam_remake
For now my plan is to play around, look into more possible issues and see if above “issues” can be solved. That means that the repo is in test mode and there’s a fat chance that I will delete and recreate it once again (or maybe even few times).

Said that, everyone is welcome to test the TestKaMRemakeRepositoryOnGitHub (TKROGH for short), and leave their opinions!

Posted in Development, News | 2 Comments

KaM Remake history. Part 4. Going public

After a long break, here’s the continuation to the series of posts about KaM Remake history.

During development each project has more than one point that can be called a start. There’s a time when a glimpse of an idea is born, when “an idea” becomes “the idea”, when first line of code is written, when first prototype works out … There are plenty of such points and it’s hard to pick just one and proclaim its a “true and utter start point”. One of such points that is more important than others is a public announcement. Before announcement you need to be damn sure the project will work out and has a chance of being finished. Once the announcement is made you will need to be dead serious putting all the effort into it.

Continue reading

Posted in Development, History | 2 Comments

Is there an unfair advantage when 2 arbaletmen armies clash?

There was a question about fighting mechanics over at KaM forum (link). To sum up in one sentence – Is there an unfair advantage when 2 arbaletmen armies clash?

28vs28 xbows screen

Imagine there are 2 armies of arbaletmen standing in front of each other. Top vs bottom, Red vs Blue. Order to attack arrives at the same moment to both armies. Who has an advantage? Place your bets and proceed inside:

Continue reading

Posted in Gameplay | 2 Comments

How exactly does KaM Remake relate to TPR

We’ve been asked a lot recently, why is it that KaM Remake does not inherit all of the TPR (The Peasants Rebellion) features. Surely it is a remake and it needs to do that, right?

The explanation is pretty simple – unlike common belief, that a remake should be based on latest game from the series, we decided to pick TSK (The Shattered Kingdom) as our golden standard of KaM gameplay and reinvigorate it by adding only those features that are fit for TSK, looking at TPR as only one of the alternatives.

Here’s a small diagram showing how exactly features distributed themselves between TSK, TPR and KaM Remake:

kmr_roots2

Posted in Development | Leave a comment

First nightly build

By popular demand: Here’s first nightly build of the KaM Remake – r5920.

What is it good for? Mainly the improved Map Editor. Early access to Dynamic Scripts that will be in next big version. Hopefully it will also allow us to reflect ideas and balance changes faster. And of course you can report bugs earlier, but no promises we will fix them fast due to ongoing development 🙂

Details under the cut:

Continue reading

Posted in Development, Gameplay, News | 3 Comments

Expanding mission text libraries

Text libraries appeared in KaM Remake missions and campaigns quite some time ago and proved to be real handy. Now they are undergoing some changes and improvements.

Continue reading

Posted in Development | Leave a comment

Chinese text support progress report

Progress report about Chinese text status in game. This is an actual screen from the game that is using actual Unicode font:

kmr_chn

Of course this is an early beta (not all characters, vertical alignment is wrong, etc.), but the big thing about this is that the workflow for fonts generation is working now 🙂 Continue reading

Posted in Development, News | 3 Comments

KaM Remake history. Part 3. Early Days

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).

Continue reading

Posted in Development, History | 4 Comments