Tiled maps vs pre-rendered maps

All games in the Panzer General series are using hex-based maps, but every generation (I, II and III) changed the way those maps are rendered.

The first game in the series used 237 small images (tiles) representing 13 different terrain types to dynamically create the image for all the maps in the game. The tile images were skillfully designed in order to allow assembling an image for the map that was almost seamless.

Panzer General II changed the approach to using large pre-rendered images as the background of the battlefield. The result was a more realistically-looking terrain but I think this change in the look also had quite an important effect on the gameplay. Pre-rendered images use a lot of memory and back in the days when PG2 was released, PCs only had about 16 or 32 MB of RAM and even fewer video memory. Thus, the maps were limited in size, and I think this made the game designers to reduce the scale of the game from strategic/operational to a more tactical one.

The third installment changed to 3D rendering but the scale was reduced even more, yet again for performance reasons, I'm afraid (they were forced to reduce the number of 3D polygons, hence the number of units).

When we decided to start developing The Panzer Division, we chose to embrace the approach of the original Panzer General. Using tiles for maps has the following advantages:

• tiles have to be designed only once and subsequent map design is much faster
• different set of tiles for each possible ground condition (dry, muddy, frozen) allow dynamically changing the appearance of the battlefield 
• less memory is required

However, designing the tile set so that maps assembled using it look well enough is a difficult endeavor. Rares and I both tried to create some acceptable looking tile sets, but we were not satisfied with the results. Luckily, we managed to convince Bogdan, a talented designer, to join our efforts and help us with the map making.

His firsts attempts brought some promising results, but it also caused us to change the approach a bit. Creating pre-rendered maps, like in Panzer General II, proved to be a lot easier than trying to come up with an acceptable tile set.

Attempt to render the original Norway map

However, as I mentioned before, pre-rendered maps usually raise the memory requirement. On PCs, this wouldn't be much of a problem, but we're trying to release The Panzer Division on tablets primarily (including iPads and Android tablets). The first iPad has only 256 MB of RAM (including the video memory), the second generation doubled that to 512 MB and the retina ones have 1 GB of memory. While the latter wouldn't pose any problems, the tiny amount of RAM in the original iPad is certainly a serious issue.

We've found some ways to alleviate this problem and scale the visual quality depending on the amount of available device memory (similarly to the 3D computer games), so we decided to go with this approach. There are also one advantage we gain by making this change: it is possible to create a far more diverse terrain.  In the original PG1:

• roads were always on plain hexes. That meant that pass through the mountains needed to be modeled as large valleys. Now we can place roads over any type of ground
• rivers were also taking up whole hexes. The approach was a bit weird gameplay-wise, because entering a river hex required a separate move. It was always hard to figure out whether a unit located over a river hex is on one river side or the other. We decided to fix that and place rivers on the hexes side, thus making it clear that they separate the opposing hexes.
• Coastlines were also plain hexes, thus the Norway map was a bit off (impossible to model mountainous shores)

Come back soon to see some new posts from Bogdan with samples of his rendered map images.

Airbases

In the Panzer General games, aircraft behave much like land units. Of course, they move in their own layer and thus, can overlap a land/naval unit, but everything else is similar: you move them on the map, they stay there until you move them to some other place and once in a while you have to place them over an airfield for refueling or getting reinforcements. They even obey the same zone-of-control rules as ground units do.

However, you have to pay more attention to their fuel level. If you keep moving an aircraft spending all its fuel, the next turn it will disappear (it crashed into the ground). To avoid this, you have to move it to a friendly airfield and refuel it during next turn. If there's no such airfield in range, you would better leave the airplane there and try to take one that is close enough from the enemy's hands.

One problem, in my opinion, with this approach, is that the aircraft's real range is not having too much of an effect on the gameplay. Of course, you have to go back refueling more often with some types like the early war fighters, but I think that's not enough.

Let's recall the Battle of Britain case. German Bf 109s, based on airfields on the French coast, barely had enough fuel to reach England and fight for a few minutes before returning home. That meant the bombers that could fly to more distant targets had to do it without the protection of their fighters. Luftwaffe knew about this so they designed the Me 110 heavy fighter. The Zerstörer had a bigger range but fared poorly against the more nimble British fighters.

One cannot simulate this well enough in the Panzer General games. You could move a Bf 109 all the way into middle of Britain and then leave it there waiting for the ground troops to take a nearby airfield to resupply the fighter.

What if airplanes stop behaving like ground troops in a different layer and be based on airfields instead? We could use their range to determine what their operational area would be. Let' analyze this approach a bit:

• The movement attribute becomes useless because what matters is only the range. They could move anywhere within a certain radius centered at the airbase location.

• Aircraft would supposedly return home after performing their mission. Because of this, they would be able to refuel and rearm every turn, for free.

• However, adding reinforcements would require holding the unit for the entire turn at the base (justified by reorganizing actions, let's say).

My initial intention was to leave the airplanes where they are at the end of the turn. That raised the question: how would the spotting take into account the unit's movement? Because moving the unit reveals area covered by the fog-of-war not only around their starting and ending locations, but also along the path of their movement.

If we leave the planes where they are, next turn when they move they will uncover the area along the trail, which might not make much sense if we consider that they should return home after each mission. It is also a bit cheating, since it will clear the fog-of-war in the area where the plane was the previous turn even if there are no friendly units there in the current turn.

So let's suppose that air unit returns to base after a mission. When should that happen? If they return immediately after a mission or at the end of that player's turn; the other side doesn't get the chance to strike back. Maybe they want to attack them with fighters or AA guns, so it would only be fair to leave the units there during the enemy's turn. Only at the beginning of current side's next turn would the aircraft return at their base, ready for another mission.

I'm currently implementing the approach described above in our The Panzer Division game. I have no idea whether it's going to be a total failure or a huge success, but I think it's going to integrate well with the changes in the general supply mechanism I'm planning to make in the game. Also, there are some details to sort out, like the air transports and paratroopers. Anyway, I would like to hear your opinion, so feel free to comment on this post.

Epic Citadel - Unreal Engine 3 demo - is running in the browser

This is crazy. The web is moving so fast. Never though that I'll live the day when a full blown shooter will be played in the browser.

Requires special JavaScript, available in Firefox 22 only. if you have it go here.
I wonder if other browsers will follow. Or maybe the question is when..

Heavy weapons German infantry units?

There were some special unit types available to the Axis player in the first Panzer General game: the heavy weapons infantry. Did such units really exist during the second world war?

Heavy weapons unit next to a standard infantry unit - Panzer General I

Let's see what kind of weapons were used by infantry during WW2:

Rifles

 This was the most used infantry weapon. Long range, great accuracy but slow rate of fire as the shooter had to manually operate the handle to eject the spent cartridge and load the next round.
Later in the war, semi-automatic rifles started to be used. In the German army, their numbers were relatively small compared to the number of bolt-action rifles. However, the M1 Garand, being the standard weapon of the U.S. infantry, was used extensively during WW2 and afterwards (Korean war).

Submachine guns

Able to shoot pistol cartridges at high rates-of-fire, they have much less range and accuracy than a rifle. However, in urban environments, these disadvantages are minimized and SMG infantry fares much better than riflemen. Additionally, this type of weapon does not require highly trained troops to be put to good use.

The German most used SMG, the MP-40, was not produced in high numbers (again, compared to the Mauser rifles), and they were issued only to squad leaders or specialized units, such as paratroopers. In contrast, the Soviets built their PPSh-41 drum magazines SMGs in large quantities and equipped whole battalions with it.

Assault rifles

 Combining SMG rate-of-fire with decent accuracy and range, the assault rifle concept appeared during the Second World War (as opposed with the rifle and SMG which had existed prior to the onset of the war).
Facing the Allies which enjoyed greater individual firepower (through the use of submachine guns or semi-automatic rifles), the Germans chose to use a different solution; StG 44 was born. It was available only 1944-1945, but after the war, the concept was embraced by most armies of the world and it's the current standard infantry weapon (e.g. AK-47 and M-16).

Light machine guns

The German military doctrine regarded the light machine gun as the primary firepower provider. One machine gun was allocated to each squad. The troops were armed mostly with rifles, but they were supposed to provide support to the LMG.

The most used German LMG was the bipod-mounted MG-34 (and its derivative MG-42).

Medium and heavy machine guns

The same MG-34 and MG-42 could be used on a tripod mount, feeding ammo through linked belts and changing the barrels as they overheated. Thus, it could provide sustained fire, fulfilling the role of a medium/heavy machine gun, even though it used the 7.92 calibre ammunition.

Grenades

The familiar stick grenade ("potato masher") was the most used German design, while the Allies relied on fragmentation-type ("pineapple") grenades

Land mines

These are defensive weapons and sometimes fake minefields were used to funnel enemy attacks to locations favourable to the defenders.

Anti-tank weapons

Early in the war, portable anti-tank weapons (e.g. anti-tank rifles, with limited penetration capabilities) were seldom used. They usually relied on anti-tank guns available at regimental-level.
Later, the famous Panzerfaust and Panzershrek weapons provided the soldiers with considerable anti-tank abilities, albeit effective only at small ranges.

Flamethrowers

Used when attacking fortifications by the Pioniersturmzug (Engineer) units.

Mortars

Infantry mortars were very useful in providing support during attacks,due to proximity to the combat zone, resulting in fast response times to changing conditions in the field.
They could also be carried by the soldiers, making them even more useful when larger artillery support is not available.

Support weapons

Field guns and howitzers, as well as anti-tank guns companies were available at the infantry regimental level, increasing the firepower available at critical sectors.

U.S. infantry also had antiaircraft .50 machine guns support available. The Germans would have to use their own MG42s to provide air defence.




In a future post, I will continue the analysis about the heavy weapons infantry units of the Wehrmacht and its validity as a unit type in a Panzer General-type strategy game.

Bitmap fonts

Rendering images is far faster than rendering text with HTML5 canvas - this is not a canvas specific issue, most game APIs have the same issue. So since this is an old problem, it has an old solution: using bitmap fonts to compose text instead of regular fonts.

Bitmap fonts are simply collections of raster images of glyphs. For each variant of the font, there is a complete set of glyph images, with each set containing an image for each character. For example, if a font has three sizes, and any combination of bold and italic, then there must be 12 complete sets of images.

See bitmap fonts on Wikipedia.
The biggest advantaje of the bitmap fonts is that they are fast to draw, the biggest disadvantaje is that you'll need new bitmaps for each dimension, font style, etc.
The good news is that for our games we need a limited set of the font family(s), font size(s), etc, so we can happilly use custom generated bitmap fonts.

The plan

The plan is to generate two things:

1. a big image with all the characters rendered using the font.
2. a "map" file that indicates the place of each char image.

When we will need to render a word, like "Play", we'll do the following:

1. Break the word in characters (e.g P, l, a and y).
2. For each character, use the font map to get the char image position.
3. Read the char image from the fonts image.
4. Draw the char image on the canvas.

The conversion

Before we begin I must warn you that you should check if the licence of your favorite font allows you to do this. Let's begin.

• Choose a font
  Download a font or choose one from your system. For example I used one from moorstation.org, one of my favorites, is called Die Deutsche Druckschrift .
  
• Choose a tool
  Now as you image there are lots of tools for this job out there, both free and paid, so you can experiment with them for a while. I settled with fontbuilder - Bitmap font generator , an open source project. While there are executables only for Windows (at the moment), it runs with Wine on Mac OS X also.
  1. Select the font, size, etc:
     
  2. Select the character set:
     
  3. Select the layout of the generated image:
     
  4. Select the output folder:
     
  5. Convert XML to JSON. JavaScript likes JSON so we need to convert the XML to JSON (e.g. http://www.utilities-online.info/xmltojson/)

The usage

Once we have both the font image and the font map we need to load them in our game and we are ready to draw texts using them.
I've created a Bitmap font reader repo on Github that contains the JavaScript code, so if you're interested go ahead and have a look.
If everything works fine, you should see this in your browser:

Till next time: keep calm and don't forget to be awesome!

Udacity - HTML5 Game Development course

Recently I discovered a new HTML5 Game course, this time from Udacity. I was intrigued to see if they can teach something I didn't knew already, so I started to take the course. Since the course was just beginning I was able to do it quickly.

The course is based on GRITS game and a couple of Google I/O presentation about the game. GRITS is open source, so you can browse the source code and if you find something clever you can let us know (for example like Paul Irish did with jQuery).

Most of the things are the basic and well known, but you can find here and there a few good tips. I'm not saying that you'll throw away your code and rewrite it again but maybe you'll do a couple of tweaks here and there.

I didn't knew about TexturePacker - is a nice little tool that we might use in the future, as for Tiled - we already have our own map editor, so I don't know if we'll switch but, you know, it can be good for new projects.

Alive and kicking

It's been a while since our last post, so it's time to dust off this a little.

Today I'll tell about my latest adventures on the journey to beat the final boss, Panzer Division Gold Version. A while ago, I became increasingly unhappy with the performance of PzDiv on iPad 1 so I decided to stop everything else and seek a solution to make it run smoother. Plain HTML/CSS/JavaScript is not working good enough on iPad no matter what, so was time to try something else.

We love HTML5 Games

I followed many leads but most of them were dead ends. The only interesting solutions were the so called hardware accelerated canvases - implementations of HTML5 Canvas API in native code.

There are quite a few of them, here are those that I investigated:

• CocoonJS
• Impact
• DirectCanvas

I know now which is better but I settled on CocconJS for the simple reason that:

• is free (at least for the moment)
• has a nice app on both iOS and Android so you can test you app asap
• PzDiv runs quite fast on it.

Even if we choosed for the moment CocconJS, I'm confident that we'll be able to migrate the code to the other frameworsk if needed - since they are all canvas based.

To canvas or not to canvas

The thing is PzDiv code is using CSS transitions, transforms, scrolls, all kinds of regular HTML stuff. All those things will not work anymore in a canvas only game and must be rewritten, redesigned, recreated. Sadly that will take a while.

It is a tough choice but I believe is the right thing to do. Till next time: keep calm and don't forget to be awesome!