Strategic Hierarchy [Version 1.0] General, command 1000+ soldiers Colonel, command 400 to 900 soldiers Captain, command 100 to 300 soldiers Lieutenant, command 30 to 80 soldiers Sergeant, command 5 to 20 soldiers Mercenary, command your own character In Strategic Hierarchy, the goal is to implement the Lieutenant level. The higher rungs of this hierarchy are for hardcore players. The Sergeant level will be similar to games such as Fire Emblem, Tactics Ogre, Final Fantasy Tactics, but with true geometric movement instead of square/isometric grid. July 29,2009. So this Strategic Hierarchy system needs to be implemented through class or structure equivalent in high level language. Role Playing [Version 1.0] // July 30, 2009. spelling mistakes changed. Your character is a [hero unit]. Health Points [HP] Mentality Points [MP] Maximum single hit strength [MAX STR] Strength optimization [STR] affects physical damage Agility [AGI] affects dodge rate Dexterity [Dex] affects fatigue rate Maximum mental concentration [MAX MEN] Mental optimization [MEN] affects the spell strength Intelligence [INT] affects the spell level you can cast July 29,2009. The data statistics need to be implemented in an array of structures. Strategy [Version 1.0] You need to decide which battles are more important in the overworld map. The decision of battle orders will give you different story lines. If you have multiple officers [you need to be at least lieutenant to have subordinate officers], then you can have multiple simultaneous battles. July 29,2009. In order to further this, I need to open up a discussion of storyline to implement development of the "core" or "real" story and the alternate stories. The point being with more branching, I will end up with a very large game size for a short game, which is not a very good idea since players want to have deep stories. July 30, 2009. http://www.gamedev.net/community/forums/topic.asp?topic_id=542909 I decided to go with SCIentific FIction for this game. SCIFI TECH [Version 1.0] July 30, 2009 A new technology exist, known as the ISC, Intercept Surround and Convert, is an anti-nuke tech. With this technology, and anti-nuke is first sent out to Intercept the nuke and explode the nuke midair. The second stage involves surrounding the explosion to the smallest possible volume. The third stage involves converting the radiation to matter. 11.25 kiloton TNT equivalent = 1 gram of matter at absolute zero. Special Tech of the Order of Psychics is a technology that allows efficient energy -> matter conversion. This system collects external energy to convert to matter instead of using its own powering energy, getting the efficiency similar to heaters. Logistics [Version 1.0] You need to maintain the equipments of your units. Equipments get worn out over time, as well as taking damage. Gathering resources is also important to minimize the cost of maintenance. July 29,2009. I will need to develop the different resource types, as well as an economy system. Tactics [Version 1.1] This design is turn based. Positioning your character on suitable terrain is important. The direction your character face is also important. The movement is on a realistic geometry through coordinate/vectors. This design wants four top view and four isometric views. July 29,2009. The movement algorithm that I want to the artificial intelligence is the breadth first algorithm. Actually, I want to implement an algorithm that follows as this: first a depth first algorithm follow by a breadth first algorithm to the same distant [movement cost] that depth first algorithm finds for first few routes. The algorithm is more intensive, but to shorten the time exponentially, I will want to have the algorithm find macro points and initiate the search from multiple macro points. Tactics [Version 1.0] This design is turn based. Positioning your character on suitable terrain is important. The direction your character face is also important. The movement is on a Square Grid. This design wants four square grid view and four isometric views. Character Size [Version 1.1] Approximating a human, 50 cm wide, 40 cm deep, 160 cm tall, 64 kg mass for an average adult. Max Carry Capacity is 45 kg [soldiers' maximum carry capacity in real life]. Healthy level max carry capacity is 18 kg. I still think the average mass is slightly higher. I believe it is now around 70 kg mass for modern times. 64 kg is average adult mass for the previous three decades. I believe soldiers need a strict BMI of 24 to 26. BMI of 19 to 25 as healthy level. I believe going down 1 BMI from the bottom end of the health range is about the same as going up 4 BMI from the top end of the health range towards unhealthiness, so 18 BMI and 29 BMI are equally unhealthy, 17 BMI and 33 BMI, 16 BMI and 37 BMI, 15 BMI and 41 BMI, etc. The approximation of equally unhealthiness is about correct. Character Size [Version 1.0] Approximating a human, 50 cm wide, 40 cm deep, 180 cm tall, 64 kg mass for an average adult. Max Carry Capacity is 45 kg [soldiers' maximum carry capacity in real life]. Healthy level max carry capacity is 18 kg. Points of View [Version 1.1] Free control of view with first or third person view. All degrees of rotation for the camera angles, and high zooming levels for tactical to strategic views. Points of View [Version 1.0] This design wants four top view, four isometric views [45 degree turn 30 degree incline], and first person perspective view for each character. Edit True Topic: I am going to create a generic game design document and the parts [different topics] of them are discuss at one and a time. The Design Document is generic so that others are able to understand and can implement this design if they want to do so. Simplicity of the design is also a goal. *Basically, I am trying to create a design document that is also a tutorial.* [Edited by - Platinum_Dragon on July 30, 2009 3:08:51 PM]

What is the question? What do you want us to do about this? Do you want us to critique it, make comments on the combat system, give our advice on movement and positioning options? Is this a theoretical design, or are you implementing it? Do you need help coding it, or have you already got a team?

If you could post a question about this you would specifically like answered it would be good.

Let's begin with the movement argument.

Square vs Hexagon for strategy, tactics, and logistics games.
The argument initiated from the fairness diagonal rule in square grid games. In square grid games, there are multiple rule sets for diagonal actions versus orthogonal actions.

Square

All 1 rule: In this rule, diagonal movement are the same as orthogonal movement. This abstractness leads to a diagonal offense advantage and orthogonal defense disadvantage. Units fleeing with an orthogonal direction are slower than pursuing units going along the diagonal direction.

The 1-2 rule: In this rule, every even diagonal count two movement points.

The 2-1 rule: In this rule, every odd diagonal count two movement points.

The 2 rule: In this rule, all diagonals count two movement points.

In either cases, the approximate Pythagorean Triangle is violated, and some players feel this unfairness because other players can exploit weakness. Some players want to have equal movement in more direction than the 4 coordinate direction.

Hexagon

Hexagons have 6 sides of mobility. Area of effect spells are also easier to implement within this system, but players notice that area of effects are smaller for the same radius (or diameter). The distortion of the hexagon tiles are less distortion in six [main] directions, but also increase distortion in six other directions [The Square Root of 5 versus 2 in the zigzag directions].
Your going 1.1180339887498948482045868343656 times faster in the six straight directions.

What I came up with is a slightly less distorted solution. Using calculus, a limit can be taken of a summation for movement. As the unit size is larger in comparison to the tile size, the movement becomes more realistic. If you make a unit become four square tiles size, and look at the larger cluster of squares, you can arrange both square tiling and hex tiling [actually offset squares], but there is a distortion towards the offset square [hex] tiling. This distortion gives a result of 1.5 movement cost along the diagonal. The overlapping of the two arrangement of offset square system gives an equivalent of a unit the size of 4 square tiles on a square gird combining both square and hex movements. It only takes 4th grade math to understand this 2x2 square size units being able to move in both square and hex directions.

Point to point movement is square grid. The explanation comes from the fact that the monitor has a square grid layout of pixels [not considering sub pixel]. The point to point system uses [Rounding [Up]] Pythagorean theorem to measure the distance, and units are in sizes of multiple squares. Those who favor point to point movements are favoring square grid movement, which shows that square grid movement is more accurate then hex grid movement if you shrink the size of the square in comparison to the size of the character. It is similar to integration, but not taking the limit to infinity. The limit is taken to the size of one pixel.

Why did I mention calculus earlier? Point-to-point movement system. I've already explain that the point to point movement system is the same as square tile system. And that hex grid system is also possible with a square tiling.

Open for critique and discussion for tiling mechanics with advantage and disadvantage of the different system for turn based rpg/strategy/tactics/logistics.

[Edited by - Platinum_Dragon on July 28, 2009 2:49:56 PM]

Tiled octagons and diamonds (if on an octagon you have 8 directions, if on a diamond only the 4 diagonals are available).
Diagonal movement costs 2 points (move from an oct to a diamond, or vice versa), grid-aligned movement costs 3 points (move from oct to oct).

Assuming a horizontal/vertical movement cost of 1, the "real" cost of diagonal movement should be sqrt(2), right?
If a diagonal movement costs 1.5, that means a 1.06066017 distortion, according to Google.
Why not give a diagonal movement a cost of sqrt(2) right away?

If you arbitrarily increase the resolution so that every unit occupies multiple tiles I think you risk getting the complexities of floating-point geometry while keeping the rounding errors of tile-based systems.

In one end of the spectrum is tile-based squares with Manhattan movement (very simple), in the other exact distances(very realistic), in between various approximations.

Are you *sure* the game needs a square grid? Square grid is something you use for it's simplicity, both in technical implementation, game balancing and ease of play. You seem to be more interested in depth of play, realism and accuracy. And besides, a turn based battle with "true" geometrical formations would be awesome.
Is there any such game out there? A (turn based)? strategy game where formations are based on floating-point polygons? Computers are good at pushing geometry around, so it should be possible...

Hmm, I seem to have rambled a bit. Sorry about that. :)

Yes, there will be distortion, but even at the point to point movement, the most precise movement mechanic there currently is and will always be [because you cannot move less than a fraction of one pixel] is a square tiling mechanic. It uses the simple Pythagorean rule to it, and if you remember that when you buy something, even a single penny less cannot get you what you want. Therefore, the movement cost is rounded up at the end after the entire path is calculated. There will never be a 100% accuracy. Statistics have a few confidence levels; common ones are 98% confidence, 95% confidence, 90% confidence, and 80% confidence. It we also take terrain cost into account, and also the mobility type into account, then having a lower confidence level will still be acceptable, but there will be players who will abuse this. If we are trying to make perfection of the movement mechanics, then the algorithm is too complicated, and the number of units will have to decrease if given real time game. That is why I decide to use turn based instead of real time. The reason why most algorithm does not use the Pythagorean theorem is because 'float' takes a longer time to compute then 'int' the usage of floating number versus integer creates a need for optimization and most players do not want to have a lag in the movement of their units [more so in real time games, then turn based, but players still want the action to have the quickest reasonable movement].

The reason of shrinking the tile down to the size of a pixel is to get a better geometry, but as far as I can tell, it is not very difficult to shrink the tile to an even smaller size, but the algorithm will be slower. The necessity of turn base is the basis that allow me to decide to shrink the tile size to the smallest possible size which will give the point to point movement.

Technically, point to point movement is still square grid. In order to improve the movement mechanic, we have to increase to size of a character. Say a character that is 4x4 tile large versus a character 9x9 tiles large. the 9x9 tile character is definitely moving more realistic.

Standard games typically have 32x32 or 64x64 tiles, but if I shrink the tile to 1x1 pixel, with characters the size of 32x32 tiles or 64x64 tiles, the movement will come closer and closer to the real value.

It is possible to have floating point polygons. If fact, as a turn based and not real time, there can be more variables involve then real time games by having more shuffling of data on the hard drive. The game will run slower then other games when the amount of units reach a certain point and that's where the "Strategy Hierarchy" system comes in. Each pixel itself can be a different terrain tile. Even the RTS games out there are still using tiles internally. Supreme Commander, Total War series, Star and War Crafts. They all use square/isometric tiles internally. [Square and isometric tiles are identical for movement.] Even thought they are polygons, they still use square tiles.

As in calculus, if you take a limit, and make a fraction the smallest possible as in 1/infinity of a slice, then you will reach a more realistic.

A true geometrical formation is simple. Being a turn base is a plus to the total unit count in comparison to real time games. Thousands of units are possible even with current day technology.

Just to point out. The internal structure of any game is still square grid of some sort. We to be more precise, the structure of any game is through the arrays. Arrays are like Integer Multidimensional grid [Square/Cube/Hypercube/etc]. Most programmer want to take the integer route first before switching over to floating point because the integer algorithm allows a faster performance, with a bit of distortion. The trade off of distortion versus performance is important. Some players don't want to wait forever for the Artificial Intelligence to take one move. The complexity of the game is therefore Multiple dimensions larger than a chess game. Creating an AI for this game will be difficult when the more precise the movement will be. There will be a compromise at some point or the AI will have to cheat. I don't want to have a cheating AI. I want to develop an AI that acts like human, and have the same restrictions as the human player. The more complex the AI, the more CPU power is needed. That is why the I initiate a tile based movement first.

One of my goals is to create a "full scale" RTS, but my plans for it won't get any good advice because a good amount of advice I get is to not be too complex. Full scale has a higher complexity that simulations.

Sorry, I'm still not organized with my thoughts yet.

Edit:

Quote:

Original post by Kekko If you arbitrarily increase the resolution so that every unit occupies multiple tiles I think you risk getting the complexities of floating-point geometry while keeping the rounding errors of tile-based systems.

The increase of resolution will reach to become the same as point to point movement, the best algorithm there currently is. The most realistic algorithm is the "increase resolution" to as much as possible [taking a limit, calculus' integral/derivative]. Yes, increase the resolution is similar to the floating-point geometry, but multiple integer computation can be optimized while floating-point will stay as the slower algorithm. I will get the precision of floating point through integers by increasing the resolution.

Please answer these two questions:
Hey does your monitor ever display a circle properly?
Or does it still use square/rectangle gird to draw your circle?

How about a vector based system.

You have a point that is the origin and then all positions are determined as an angle + distance vector from that. then when you need to display it on screen you just map the vector to the raster of the screen.

The problem you are having is that you are mapping, dir4ectly, the screen co-ordinate system to the world co-ordinate system. There is no need to do this as computers can easily crunch the numbers to translate from one system to the other.

In game design, we decouple various system from one another and translate between them. For example, most games decouple the processor cycles form the frame rate, but we keep track of the difference and factor between them.

Why not do this with positioning system as well?

Even if you separate the screen coordinate system from the world's coordinate system, there still needs a way to ensure that objects do not overlap at the graphical side of the system within this 2d or 3d environment. This translation between the two will allow a higher degree of resolution, but there is a limit before the system chokes the CPU. A design needs to compromise the different performance of the game. The graphics rendering, the movement of units, the AI. Getting a solution to slower CPU would get higher rating for a game because more players can play the game.

There's two solution to a problem. The simple, and the complex. Then there's other solution in between by compromising the two extreme solutions. The simple solution runs faster, and that's why Tile Based games were created, and they are still used. To an extend, most system out there uses square tiles regardless.

The point of separate or not between the world's coordinate and the screen coordinate systems does not matter if I allow zooming; there is an aspect ratio based on the zooming level. And if a player zooms all the way into the screen as much possible, then you will return to tiles regardless of which system use because we will reach a point where we are talking about taking limits in calculus. In fact, that is where I am trying to head towards; higher level [college] education in games.

Using "higher level [college] education in games" is my true goal.

Edit:
Using 6 angle vector.
What is 6 angle vector? 6 Angle vector is the usage of two types of angles: Angles around an axis and angles from an axis positive direction.

Yaw: Angle around the Z axis aka as angle along the xy-plane not the yx-plane.
Pitch: Angle around the X axis aka as angle along the yz-plane not the zy-plane.
Roll: Angle around the Y axis aka as angle along the zx-plane not the xz-plane.
Angle from Z axis positive.
Angle from Y axis positive.
Angle from X axis positive.
Note: There is a different orientation depending on which order you label the axes for planes, spaces, hyperspaces, etc.

The angle around the z axis + angle from z axis = spherical coordinate along z axis.
The angle around the y axis + angle from y axis = spherical coordinate along y axis.
The angle around the x axis + angle from x axis = spherical coordinate along x axis.

The combination of the six angles give you 5 ways to represent the sphere aka all direction in 3D. The usage of all six angles is redundant, because you can get all six angles form any one set of angles that can represent the sphere. The common method for flight simulation it yaw pitch roll, but this requires 3 separate 360 degree angles. Each of the three spherical coordinate requires a 360 degree angle and an 180 degree angle. The fifth method is the "angle from axis method", which requires three 180 degree angles, but can be compress to two 180 degree angles with a binary number for acute obtuse on the third angle. Using only two 180 degree angle with a binary number is far the most compact form in representing directions within the 3D Space.

[Edited by - Platinum_Dragon on July 28, 2009 12:53:13 PM]

Unless I'm understanding you incorrectly, I think you're needlessly over complicating things.

The first assumption you make is that you can't work in units less then a pixel in size, which is incorrect. Even when rendering you work in sub-pixel units - that's how you get anti-aliasing. How you render something shouldn't have any impact on the possible positions of your game objects.

Another assumption you make is that ints are always faster then floats. Unless you're running a VERY old PC (or a DS), the processor probably has a fast FPU, meaning you don't need to worry about int - float performance. If you're game world is exceptionally large, or you need to be able to zoom in exceptionally far, you might run into floating point precision errors, but there are ways around that as well.

If you're still worried about performance, you can use fixed point and just set it to be of sufficient fidelity. If your game is about tanks fighting people, you probably don't need enough fidelity to accurately position microbes.

Finally, how your represent the rotation won't gain you much as far as game design is concerned. Position in 3-space can be given with 3 coordinates, i.e. a vector with x, y, z. A rotation can be represented with Euler angles (with risk of gimbal lock), quaternions, matrices, etc. In the end, as a designer you're still dealing with a position and orientation.

~Kindjie

Quote:

Original post by Platinum_Dragon Please answer these two questions: Hey does your monitor ever display a circle properly? Or does it still use square/rectangle gird to draw your circle?

That's actually just one question. :)
It uses a rectangle grid of course. But on a 1280x1024 resolution (old computer) it looks pretty damn much like a circle.

Here's my question:
What on earth does screen display have to do with how you represent game objects?


Btw, 64 kg sounds a bit smallish. I weigh 64kg, am 175cm tall and I'm pretty thin. I think you've taken the average male height and combined with the average human weight, females included. In Sweden the average male weight went from 75 to 82kg from 1980 to 2005. Something like the lower number (in the 80s before we grew fat. :)) sounds about right as an average soldier weight.