Pagini

Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Monday, October 7, 2013

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.

Thursday, August 8, 2013

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.

Friday, March 8, 2013

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.

Monday, September 17, 2012

The Map Editor - Part I

Panzer Division Map Editor 1

I'm working on the Map Editor for the Panzer Division for a while now. It's not done yet but I decided to share some of the experience, maybe somebody will find it useful or maybe somebody will spot something horribly wrong and let me know.

To understand some of the decisions we took is important to know that:

  • Panzer Division is made with HTML5, CSS3 and JavaScript.
  • Panzer Division is supposed to run even on the first iPad (where we are facing tough constraints especially related to the maximum canvas memory.)
  • Panzer Division maps have pointy hexagonal tiles.

Intro

In Panzer Divizion the first thing you'll have to do is to choose what to play: a campaign or a scenario.

  • A campaign has an associated set of scenarios.
  • A scenario has an associated map.

Before we can create campaigns, we need to have scenarios. And in order to create scenarios we need maps. (Actually with one map we can create multiple scenarios, and those scenarios can be used to create campaigns.)

To create maps we need a Map Editor.
To create scenarios we need a Scenario Editor.
To create campaigns we need - what a surprise - a Campaign Editor.

The maps, scenarios and campaigns are kept on disk in some format like JSON. When the user chooses a scenario, the corresponding scenario file and map file are loaded from disk.

All the three editors have to:

  1. read and parse the file and generate data structures to be used by the game.
  2. allow the user to modify the data.
  3. save the data back to the file.

For the moment we work on the map editor, the others are to be done later. Panzer Division Map Editor 2

The Map Files

The purpose of the Map Editor is to read, modify and save map files.

A map file contains the following information:

  1. map size - number of rows and columns.
  2. tile data for each of the tile - indicates how a specific tile must be rendered (e.g as sea, forest, shore, etc).

Map file example:

"numberOfColumns":30,
"numberOfRows":20,
"tiles": [
 [0,0,0,0,0,0,0,0,0,0,5,11,11,11,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,10,106,106,106,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,10,193,176,169,159,23,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,5,11,6,5,16,188,217,178,178,172,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [5,6,0,5,16,33,106,22,106,193,218,238,178,156,106,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,106,17,16,106,106,64,106,106,188,189,208,207,196,24,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,175,158,114,110,133,100,133,117,192,199,106,191,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [9,155,178,165,106,130,106,64,106,106,106,106,106,24,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [9,161,160,106,145,117,106,63,106,13,14,106,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,9,106,128,119,106,163,60,106,18,0,3,8,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,9,113,106,106,157,174,31,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,3,14,106,157,178,179,165,18,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,15,162,178,167,160,106,12,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,4,106,20,160,13,14,106,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,3,2,3,2,0,3,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], 
 [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] ]

The tile information must also be used by the game logic to influence the unit movement (e.g rivers or swamps reduce it) or to prevent movement (e.g battleships cannot go over forests) so is important to spend a while to think about various ways to do it.

We also need a tile set image - a big image that contains all the terrain tiles. We now have a big problem: the tile set image can be very different based on the choises we make so we need to spend as little time as possible on making that tile set for the moment. My advice is to use obvious colors and big brushes to create a rude version of the tile set. I lost lots of time trying to create nice, detailed tiles only to throw them away later because I realised I need a different tile set.

Defining hexes

The map is composed of pointy hexagonal tiles. Each hex has 6 corners and 6 sides.

 S6  /\  S1
 S5 |  | S2
 S4  \/  S3

We can use either to describe the tile, for example we could use 1 for the side that matches forest and 0 for the side that is not forest.

Since there are 6 sides/corners, so we have 64 possible combinations for each type of tile, the sides index is: 000000-111111 (00-63)

The side 1 is the last significant digit, side 6 the most significant digit, like this:

S6 S5 S4 S3 S2 S1
1  1  0  1  1  0 

Panzer Division Map Editor 3

The many facets of the terrain

There are forests, mountains, rivers, shore, etc. How can we encode more than one terrain type in one tile data? That will be discussed in another post.

Tuesday, April 24, 2012

How to become a game design master

Machinarium sketch
Machinarium game concept

You think you can design games? You think you know why is a game fun or not? Maybe not now but you will as soon as you read Game Design Concepts - An experiment in game design and teaching

Game Design Concepts was started as an experiment by Ian Schreiber - one of the authors of Challenges for Game Designers book. It is an online course in game design. Unlike most of the stuff out there that is mostly theoretical, this course is very practical.

So what will you find there?

By the end of this course, you will be familiar with the (relatively small) body of work that is accepted in the game industry as the theoretical foundation of game design. You will also be comfortable enough in processes to start designing your own games, as well as critically analyzing other people’s games.

Each lesson ends with a homeplay (a.k.a homework) and links to related articles or books. Those links alone are gems, believe me you'll find what to read there.

We found some nifty strategy ideas for Panzer Division there, I'm sure you'll find too as soon as you start designing a game.

In case you are hungry for more, in 2010, the experiment continued as Game Balance Concepts - A continued experiment in game design and teaching.