Welcome, Guest. Please login or register.

Login with username, password and session length

Advanced search

1412057 Posts in 69447 Topics- by 58483 Members - Latest Member: Exye

June 23, 2024, 01:04:28 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsPeaceful Era
Pages: [1]
Author Topic: Peaceful Era  (Read 2456 times)
Level 0

Programmer & Designer at DobbleStone

View Profile WWW
« on: March 05, 2016, 12:27:42 PM »

Hi people of the TIGForums,

Thanks for reading DobbleStone's first post!
This post is also our official announcement of our project Peaceful Era.
Peaceful Era is a competitive local-multiplayer brawler. Up to four players take on the roles of pilots controlling planetary landers sent to the surface of newly discovered planets, to claim their resources.

The game is set in a distant future…
After aeons of planetary wars, the United Cosmic Alliance has finally achieved peace throughout the explored parts of our galaxy.
At first, the people rejoiced for the wealth resulting from beneficial trades. However, as resources are starting to dwindle due to a greedy few, new ways need to be found to provide the allied nations.
The Resource Race is at its boiling point, and anything but direct violence is condoned. The nation-leading companies have sent their best pilots to explore new planets. YOU are one of them, and it is your goal to battle... I mean peacefully claim their resources!

Core Mechanics
Core mechanics of the game revolve around gravity bending projectiles, which are deployed by planetary landers (droids), controlled by the pilots (players). A small demo below. We plan to share more visuals on this with you soon. Smiley

Projectiles attract or repulse objects. These droids are of the highly expensive "Eplet" model.

Team DobbleStone
DobbleStone is a group of Dutch students, who all have busy study schedules. To resolve this terrible challenge, the team comes together every two weeks to work on Peaceful Era. The advantage of this formula is that we've managed to secure some busy but talented students we're very excited to work with. The obvious disadvantage is a relatively slow progress. Nonetheless progress is steady.

Feature is DobbleStone's mascot and logo.*

We made a special art choice for Peaceful Era.
The art is inspired by the legendary artist Jean Giraud, better known as Mœbius.
We will share more datails on this choice (and more pictures!) in the future.
For now, here is a draft of one of the resource rich planets of Peaceful Era.

Still of a planet's surface, tentatively titled "Fungal Forest".

Follow Us
If you're interested in receiving more updates, we've set up a Facebook and Twitter to keep you informed about pretty pictures, posts like these, and other announcements.

Thanks again for reading this first post by DobbleStone!
We'd love to hear what you think of project Peaceful Era, and hope to see you next time. Smiley

Hans Cronau
Programmer & Designer at DobbleStone

* Found something "wrong" with Feature? Think again...
« Last Edit: April 26, 2016, 09:53:42 AM by HansCronau » Logged

Level 0

Programmer & Designer at DobbleStone

View Profile WWW
« Reply #1 on: April 30, 2016, 11:49:43 AM »

Hi all,

In this post I'd like to share some details on the implementation of Peaceful Era's Dynamic Camera.

Dynamic Camera
A dynamic camera was one of the early pieces of programming created for Peaceful Era. Without it the game looked static, and it was hard to get a sense of the scale that the characters and levels would eventually have. So how exactly does a camera follow multiple characters around a screen at the same time, while taking into account: boundaries of the level, different aspect ratios, and a margin of 'breathing space' between the characters and the edges of the screen? What should the camera do when a character crosses the boundaries of the camera's movement, when it might still return to the visible part of the level? What happens when temporarily no characters are in the level at all? And how to make all of this look smooth?

Luckily for me this was one of those cases when you have an idea first and working it out is so much faster than looking up references in order to mimic their methods. After programming a camera system I checked how other games had solved the same issue and found similar solutions. An interesting article by Itay Keren on game cameras for side-scollers can be found on Gamasutra. In this post I won't go into historical details or discuss different types of cameras. I will however share how Peaceful Era’s dynamic camera achieves the effect Keren calls “position-averaging, zoom-to-fit, and lerp-smoothing”. I will do this by explaining the steps Peaceful Era's camera goes through each frame. This is the first time details of this system are shared, so I would love to know what you think.

Step 1: Centre
At the heart of our dynamic camera is a sense of centre. This is the point 'in between' all characters, which are represented by (2D) position vectors. To find this point the camera goes over two sub-steps:
  • Loop over all character positions storing the highest and the lowest x- and y-coordinates.
  • Note: if you'd like to have a differing x and y padding, or maybe even a differing x-left and x-right or y-top and y-down padding, add these to the minimum and maximum x- and y-coordinates now.
  • Calculate the distance between the minimum and maximum x-coordinates. Do the same for the y-coordinates.
  • The centre point is then found by adding half of the x-distance to the minimum x-coordinate, and half of the y-distance to the minimum y-coordinate.

An 'average' position is calculated based on the most extreme positions.

One might at this point also add a bias, to compensate for HUD elements occluding parts of the screen. The camera would then attempt to centre slightly above, below, or next to the calculated 'centre' of all characters.

The calculated centre point is stored as the 'desired camera position'.

Step 2: Zoom
Next, we want the camera to zoom in and out, depending on the positioning of the characters. For a 2D Unity game, this comes down to setting one value on the Main Camera, called 'size'. (Unity's 2D orthographic camera doesn't have width and height dimensions.) After some experimental measuring (or reading documentation or this blog post) you'll find that this size value corresponds to the distance (in world space) between the camera's centre y-coordinate and the top (or bottom) visible y-coordinate. This comes with a 'fun' challenge of aspect ratios.
Quick example of what this means:
Want to give the camera a specific height? Divide it by 2 to find the corresponding camera size.
Want to set the camera's width? Tough luck.
Well...not tough luck exactly. This is where the ratios really come into play. If you want to set a width, first calculate a height (height = width * aspectRatio, aspectRatio = screenWidth / screenHeight). Then divide it by 2 to find the size.

Thinking in camera width and height requires translation to a size.

Now that we know how to set a width and height, the tricky part is to know when you want to set which: sometimes characters are far apart horizontally, in which case we want to ensure a matching width, while in other cases they may be far apart vertically, in which cases the camera's height has our main concern. In order to choose between width and height, the camera will need to compare the aspect ratio of the smallest rectangle containing all characters, and compare it to the aspect ratio of the camera (which in typical cases is determined by the screen dimensions).

This is done according to the following rules:
  • The aspect ratio of the character rectangle is easily calculated by dividing the previously found (see Step 1) x-distance by the y-distance.
  • Now that we have two aspect ratios (the camera's and the character rectangle's) compare them in the following fashion (keep in mind aspect ratio is (x/y):
    • If the character rectangle aspect ratio > camera aspect ratio: the character rectangle is wider relative to the camera aspect ratio. This means that the other way around, the camera view is higher relative to the character rectangle. Thus setting the camera's width will automatically ensure enough screen space for the characters vertically.
    • Else: the character rectangle is less wide relative to the camera aspect ratio (or they are exactly as wide, in which case we don't care). This means that setting the camera's height will automatically ensure enough screen space horizontally.
Based on the above, the camera decides whether to set a width or height. We previously discussed how width and height are each translated to size. If you didn't add a padding in a previous step, now simply add your padding value to the desired camera size.

A padding is added to improve orientation of each character within the scene.

If a minimum camera width/height/size is required, check and enforce it at this point.
I do not advise a maximum camera size, as the next step will already limit the camera size based on scene borders.

Note: If a centre bias was applied during Step 1: Centre, one might want to increase the camera's size accordingly at this point, as to not occlude parts of the scene, which would otherwise have been visible.

Step 3: Constraints
Now that the camera has found a desired position and a desired size, it is not done yet.
Probably you don't want all of your scene to be visible to the player. There might be an edge to it.
If characters are allowed to move further than the camera is allowed to view them, it's time to add some constraints.

Peaceful Era's camera system knows camera borders. These are four values: two horizontal borders (left and right) and two vertical borders (top and bottom). Together these borders shape a rectangle with a width = right-left and a height = top-bottom.

If the desired camera size would result in a wider camera than the border width, or a higher camera than the border height, this is a problem and the camera size needs to be constrained. Again we compare aspect ratios, this time between the camera and the border rectangle:
  • If border rectangle aspect ratio > camera aspect ratio AND desired camera height ( = desired size * 2) > border height: constrain the desired camera height to the border height.
  • Else if the border rectangle aspect ratio <= camera aspect ratio AND desired camera width ( = desired size * 2 * camera aspect ratio) > border width: constrain the desired camera width to the border width.

Now that we have found a desired camera size which would fit the confinements of the scene’s camera borders, we still need to adjust the desired camera position to make sure it is actually within the camera borders. This is done in the following steps:
  • Calculate the difference from the camera view's sides to each of the camera border sides. This will yield four values, two horizontally (left difference and right difference) and two vertically (top difference and bottom difference).
  • Go over the difference values. If any of them is positive or negative, indicating that the camera's view is crossing a border, simply add/subtract the difference to the desired camera position.

Zooming is constrained, to ensure the view does not extend beyond the camera's boundaries.

Step 4: Lerp
Note how so far we have discussed a desired camera size and position. The reason for this is that adjusting the camera position and size immediately looks very mechanic. Instead, a more smooth transition is desired. To ensure this smooth transition, we interpolate between the current camera position and size and the desired camera position and size. Position and size can have their own interpolation 'speeds', which are values between 0 and 1. Key is finding a value which fits the speed of the game, so that characters tend to never fall off screen, while at the same time giving the camera a 'smooth' movement.
If you're yet unfamiliar with linear interpolation (often shortened as 'lerp'), please do Google it. It's a very simple mathematical principle and you'll be happy to understand it.

So how will this look ingame?
Linear interpolation is a method of creating data points (such as camera positions) based on two existing points (such as the current position and a desired position). It is often used to create a 0 to 1 transition between two points. This transition would look like a straight line between the two points, and it is easy to imagine that a camera panning along this line in constant speed would look rather dull.

To avoid confusion I would like to point out that this is not how Peaceful Era's camera works. Instead, every frame it chooses a single point along the line between current and desired position - say halfway (0.5) or further (0.7) - and moves the camera to that point. Repeating this every frame with the same value creates a very 'elastic' motion: if the desired position is far away from the current position, moving halfway is quite a far distance too.
When you've gotten closer, the camera will slow down, because the distance between current and desired position has gotten smaller.
Also keep in mind that the desired position may change in between frames, so the camera lerp is never actually 'done'.

Some final notes

Crucial in the above is the order. By maintaining the order 'centre, zoom, constraint, lerp' priorities are where they are expected. Change this and funny stuff will happen, such as players seeing past the edge of the scene.

To generalise the concept of character positions, we created a component called PointOfVisualInterest.
This component automatically registers with the dynamic camera and shares its position.
Advantages of this approach are that important focal points within the scene can also register within the dynamic camera to ensure their visibility.
We also use it to keep the camera focused on the position where a character has left the screen, never to return. Instead of immediately snapping back, this allows the player to register that their robot was irretrievably lost, while the respawn countdown starts.

Although Peaceful Era does not do this, one could give each PointOfVisualInterest a custom padding.

Thank you for reading this post on Peaceful Era's camera system up to this point. If you have any suggestions, questions, remarks, please feel free to comment.

Edit: Added "So how will this look ingame?" to Step 4: Lerp.
Thanks to Ken Voskuil for pointing out this possible confusion.
« Last Edit: May 15, 2016, 04:50:49 AM by HansCronau » Logged

Pages: [1]
Jump to:  

Theme orange-lt created by panic