Prototype Programming

Hello everyone, this is Colin, one of the programmers on Red Sun. So far in the project I have worked on the foundation work of the prototype, by which I mean the movement of the character as well as the buttons, switches, and the various objects they affect. My main focus when creating these objects was to make using them as designer-friendly as possible. With that in mind I have also made a few simple tools and editor scripts that should make it a little easier to create and design levels for this game. Creating and refining these kinds of features and scripts will likely be my primary task over the next couple of weeks while we get all of the groundwork done. After that, we'll be moving on to bigger things like enemy AI and level streaming, and In the meantime I'll try to keep this blog updated on how things are going on my side of the project.

Working on Camera

Hello, I'm John, one of the programmers in this project, where I was asked to do the camera work for the prototype. The prototype that the programmers have made so far is a simple, closed room with simple boxes and circles, also known as programmer art.

When it comes to the prototype, I have created two camera modes so far: 

Multi-target camera mode

In this mode, one needs to track all of the interesting objects in the level, which includes Bo, the sheep, the wolves, and others that we may see fit. Of course, while in this camera mode, all of these objects must be within the camera's field of view, especially Bo. It is really bad camera work if you cannot see who you control, right? So we set a maximum threshold for our characters' positions relative to the camera before we zoom in or out.

However, zooming opens another cam of worms to deal with, such as:

•  objects being so far apart that the player is too small in size to view, or 
• the objects are too near between each other that the overall actual puzzle room cannot be seen, so the player cannot really see what's going on with the puzzle room once they do things such as pulling levers, stepping on buttons, etc. 

In order to solve this, we did three things. First, we just created a minimum and maximum orthographic size variable for our camera. This prevents the camera from zooming in or out too much. The minimum orthographic size of the camera is set such that a majority of the current level is within the camera's field of view. Meanwhile, the maximum orthographic size is set to a value where the entire room can be seen, and consumes most of the camera's field of view. When setting these values, it is important to note that these values should not be too far apart so that the zooming events do not make the player dizzy when the player's position satisfies the criteria for zooming in and zooming out.

Second, we added weights for every interesting object in the game to establish focus to those that are more important.For example, the player must have higher weight than sheep and wolves. These wights are important when calculated the weighted average of all the positions that will determine the camera's position while in this camera mode.

Finally, we created an empty GameObject that is located at the centre of the room, with its weight set higher than the rest of the objects in the level. This allows the player to see most of the puzzle room, while still having focus towards the interesting objects (Bo, sheep, wolves, etc.) 


Reveal camera mode

As of this stage of the development, we have agreed that we will introduce another camera mode whenever an object appears in the game for the first time. For example, in out prototype, I assumed that the new object being introduced at the current level we are working on is a button.

When the player touches the ground for the first time in the level, we immediately switch to this new camera mode to "reveal" the new item. So, the camera "lerps" (basically interpolates) from the current position of the camera on the way to the location of the new interesting object to be revealed. Then we stop the camera movement once it has reached its intended position to "reveal" the new item. Then, we switch back to the multi-target camera mode to resume gameplay.

Currently, the camera's position "jumps back" from the newly-revealed item in the level to the weighted centre of all of the tracked objects in the level. However, I'm also considering to "lerp" the camera back to its original position (i.e. its position prior to the switch to the "reveal" camera mode.)

I am also considering other ways to put the "reveal" camera to use. For example, when a switch has been triggered, the camera will "lerp" towards the object affected by the triggered switch, and goes back to the player a few seconds once it has finished the consequent action. However, repeatedly triggering the switch on and off may get the player feeling dizzy due to having too much camera movement. So, if I introduce this action, I will do it on the initial interaction. Therefore, the subsequent interactions with the switch will not trigger this camera mode to avoid player dizziness and confusion.

Laying the GRIDwork (pun)

Hey gang, it's Nick (!) here, and I've been tasked to create a nice simple grid to help with the ease of creating puzzle rooms for Red Sun.

After brainstorming as to which base assets we would need to create a level, I set to work making some rudimentary avatars in Illustrator to represent the much prettier (eventually) real-game elements.

Using the Unity 2D platformer metrics, the team and I have come up with a simple jump metric for Bo that is a key step in creating a usable level creator grid.

It is important to note, however, that these metrics will most likely need to be constantly tweaked in order to achieve a result that we're happy with. 

The next step was to gather a consistent agreement on the dimensions of Bo and all other assets in order to create a simple and easily tile-able level creator. After deciding on a 1 unit by 1 unit grid, we went to work assigning height and with values to all the remaining assets we would be using.

The advantage of keeping relatively square, makes it much simpler to snap assets onto the grid when it comes time to make a bajillion puzzles.

So with our metrics figured out, I placed our nice little tiles in the grid to recreate the sample level used during our green light pitch. And let the play testing ensue!

Prototypes and Proposals

This week the team has been putting together the a prototype, level design document, and preliminary style guide. The prototype is getting its basic features from the programming side. Basic boxes and rudimentary controls will be the jumping off point for basic level design and ironing out the game play. The level design document is the design team getting diagrams around which we can all talk about. It takes time and effort to commit to a design and getting as much worked out on paper as possible will make the most of our time.  Finally the style guides are in much the same place as the other elements of the project. Its a great many ideas and concepts to work through so the team has a common place to start from. There is not enough production time to really change directions once key choices have been made and working out these ideas now well hopefully help prevent butting heads down the road when implementation gets underway.

Later this week the team will get putting together introductions and brief overviews of their work so far as individuals on the project.