Final Thoughts

The Red Sun four month vertical slice is completed. A vertical slice represents a cross section of a game with in this particular case focused on player movement, abilities, and puzzle navigation. This is not a complete game and contains only a tutorial level and one full puzzle level. We presented the project on August 22nd at Sheridan College.

The version that we released there is available for download if you so choose. There are a few notes about the project. We have had the most testing on the following settings:

Played on Windows 7 and higher
windowed
1920X1080
quality setting fantastic

There is keyboard and Xbox controller support and you can select the sort of prompts for the tutorial you would like to see in the options menu. While we would strongly recommend that all players play the tutorial, it is not required but it is assumed you have played the tutorial when entering level one.

Download from Google Drive: http://goo.gl/jWVJhV

The download contains three items, the RedSun_Data, RedSun.exe, and the TestXML.xml. All three of these are necessary parts for the game to run and we recommend that you download them into a single file folder. Launching RedSun.exe will start the game.

Now for few closing thoughts on the project. The project was drastically changed and trimmed from the initial proposal. Some of this was expected some less so. The vertical slice represents a significant portion of the mechanical elements but almost completely excludes the narrative and extensive world that the proposal contained. If the project is ever revisited, this lack of explanation of the world and narrative would be a primary focus. While it did not end up being the game that was expected, as a four month project it accomplished many of the goals set out for it.

We hope you all enjoy the game!

This blog will be on hiatus for an indeterminate amount of time but comments and queries can be directed to the creative director on the project at her email: firecatrich(at)gmail.com

Now that we're in the thick of things - there's only a month left in the project - most of the news we have for the public is that we're fixing more bugs and hammering out some of the smaller details. So much of what's left in the game is arting things and making sure that it all fits properly and looks right.

That said we have some good and some bad news. To start our animator is gone for a little while. We knew this coming into the project. Hopefully she'll be back for a week or two in August to put some finishing touches. It's in a state where we are comfortable with what we have, but more is always better.

There's a lot of fancy art things going on. Here is what I can share with you this week...posters! We have some really nice posters that will show up in the tutorial level and possibly throughout the rest of the game. I thought it'd be nice to share some of them so here you go.

Really the big thing now is testing the levels and getting the animations ironed out. They are a pain to get right and are probably the first thing that people will notice if they aren't extremely polished. All we can do is hope that the extra couple animations that we added recently don't hurt the product with what little time we have.

Aside from that we are, as always, fixing many bugs and quirks. We will be having another testing day soon as well which means a lot more feedback and a ton of changes to be made to the game in the coming weeks. The testing day is probably just internal testing but we might pick up some outsiders to get some less biased perspective.

Another week down and that much closer to the end of the summer. It's a bit nerve wracking that we're so close to the end now. It's crept up on all of us I think. That said we're well on track to getting things finished and making it awesome.

I know I promised that I'd get something for you guys about the lighting but it's not quite ready yet. As of last week we only had it implemented in the tutorial level and a very small portion of our first full level. We'd like to get it into the rest of the level and polish up our library portion before showing the world this little thing that we're proud of. So look for that in the near future.

Lastly, there's a high chance that there will be no post next week as a third of the team is gone for the weekend at one of the conventions nearby (if you're going to ConBravo! let us know and perhaps we can meet up at some point) which will keep us busy. Work resumes Monday.

Another bug bites the dust

As the title suggests, we've got a lot of bugs fixed. There's still plenty to go as there always is but we've made a lot of progress when it comes to getting a working game.

This has been a very productive week for everything from getting the animations in - we've got sheep and wolves added - to some major camera improvements. So lets get into some specifics now shall we.

We had some very interesting new bugs crop up this last week. We were trying to make some improvements to the way we had the conveyor belts working. The "improvements" led to some very slow belts. Phenomenally slow belts. We haven't fixed that entirely yet so for the time being we've reverted back to the original set of belts. Speaking of slow things, we've had some strange interactions with the sheep animations that cause them to fall very slowly. It's actually quite comical to watch them fall slowly while apparently flapping their ears.

Animations. We've got all of the sheep animations in and nearly all of them are working perfectly. Easy fix I'm sure but not something that would've been easy to catch at the start. Lots of bugs to track down and fix but we've got them mostly under control. Wolves are also in! As I'm typing this I have some of the crew working setting up the animation tree. Can't share any more of that with you yet but the wolves look pretty cool. We haven't even gotten the bubbling wolves in yet. A couple other things we got into it are the edge grab animations and cycles, it looks pretty fancy so far. She can actually hold onto the edge and pull herself up. This is another one of those things where small imperfections will stand out so we'll be continuing to work on stuff like this where we need to.

Enough about animation, on to the fun camera improvements. Throughout testing we found that there were many issues with the frame that the player was looking through. So we've constructed a room camera to get around a lot of these issues and I have to say that it looks wonderful. We're discussing some options for switching between the regular player camera and the room camera but that's one of those design decisions that's easy to implement but has larger over-reaching consequences. I'm sure it will go through a fair bit of testing as well.

Speaking of testing, we have another build getting compiled today. Another round of internal testing. Last time we had a bunch of people from outside the projects come in to check out our games and play around with them but now it's just the faculty and other students. This means a lot of bug hunting and testing. While it might sound like there's tons of work to be done, things are moving along smoothly. We're getting a lot done and we should be hitting all of our goals. These sorts of projects are a lot of work.

Lastly we've got some really cool lighting effects getting set up right now but it's pretty far from being finished so all I can give you is a teaser image of the one tiny section that we've got working and hint at a feature article about our lighting when we have the time. So for now, here's a low-rez shot of some light effects.

Week ??: Starship Troopers

Welcome back everyone! I'm going to start this week off by saying I have no idea which week it is. I might be a week or two behind on the numbering so I'm going to drop it and just have more fun with the titles.

Alpha testing was a huge success with a couple notable problems.

To start we had a few very common almost game-breaking bugs with the way our levels were streamed/built. At one point if a player died they would respawn into an unloaded area of the map. Easy fix but was frustrating during testing.

We had a few other gravity quirks and some stuck issues but for the most part we got some great feedback so thanks to everyone who came out and tested games for all of the groups. While I can't actually speak for the other groups I'm sure they get a bunch of great feedback from you guys as well.

Back to real news though.

Over the radio silence we had some exciting days. We had a sound tech come to a farm with us for some sheep sounds! As you can see there are also some images we got from the excursion. I'll include several more of them before the end of today and perhaps some more over the week if people are enjoying them.

We've got some test music for our ambience and we aren't ready to really share it just yet. We also haven't gotten many other sounds into the game just yet. Because it's an interdisciplinary part of the game (sound tech and musicians and programmers), it will likely be a while before we can really get moving with that section.

As always we have been getting a lot of the art and design into the game but right now the biggest and most important parts of development right now are the bug fixes. We have an incredibly long list of bugs, most of which are minor and some a quite major, that we're working down. The vast majority of our time is devoted to finding and fixing these bugs.

Lastly we're continually editing the levels. The tutorial is likely to go through another 20 to 30 revisions before we settle on something we like. We're hopefully going to get another level in before the end of the summer.



I'd like to give a special thanks to CFA (guesses at what it stands for in the comments, don't ruin it if you already know) for allowing us to go out there to record some of their sheep and take some pictures. As I said before everything is about bug fixes and the camera right now so enjoy the pictures of sheep.

Weeks 3, 4, and 5: Nothing to see here, move along.

Welcome back. Lets start by saying that there's not a whole lot that's been going on that I can share with everyone aside from: everything is moving along smoothly.

Animations are coming along nicely. Bo now has the beginnings of an edge grab animation among some other important bits. As always there are lots of improvements across the other completed animations such as extra frames and touch ups. Not a whole lot to share on that front aside from lots of progress.

In other news, the tutorial has been through at least a dozen passes and is constantly going through more. It's looking pretty good right now with a few rough spots that need a bit more iteration and inspiration. There are also two (2) other levels that are getting built though they're not as finished as our tutorial level.

There's so much that's been going on with the programmers that it's really hard to get all of it to you in a meaningful way so here's the two largest things that I feel are important.

1 - Checkpoints and saving. We've got the beginnings of the checkpoints and saving functions in the game and will be working on it more as time goes on. Now when you die in a level you don't have to start it all over again. This also means we can start putting things together. Levels wont have to be separate things loaded up independently. This leads into getting the game flow (between menus and getting into levels etc) up and running.

2 - More camera work! The camera is looking really nice now and is into more revisions. The panning or peeking as some are calling it is a lot smoother than it used to be.

There's a whole lot more going on under the hood but these are the things that people might notice coming into the game, things you might not notice such as tweaks to things like slippery surfaces and better level flipping gravity without having seen it before are also happening.

Lastly, the big news. We have our first alpha testing day coming up next week. Right now we're all in a mad dash to get things ready for testing so there's not a whole lot to show. With that in mind we wont be here next week but we will be back the week after. We're going to be extremely busy focusing on the feedback from testing and getting things ready for testing that we'll see you in 2 weeks!

Week 2: 2 Steps Forward, 1 Step Back

Week 2 of Red Sun Development has begun, and already I've made a mess of things. All of the notes and information for this week's update got lost when some re-organizing happened. We're working mostly from memory folks so bear with me.

I'm going to start of with the programming side of things this week. The big news here is that we've been trying to decide whether or not to use a regular physics based character controller or build on ourselves that doesn't get caught up with the limitations of Unity's engine. The upside is that Unity has a pretty nice physics engine but forces you into a few things that can give you problems, especially when you tie it into animation. So we're going to stick with the homebrew controller that doesn't stick to Unity's physics engine. It's going to mean a bit more work in some areas but based on what the programmers have told us, a lot less work in others including fewer headaches for the team as a whole.

Additionally in the world of code, our camera has been working wonderfully. We're getting some added features there including camera panning to see more of the level and zooming in/out. Some of the major design considerations here include what we want the player to actually see when moving the camera around. Since we're focusing on the puzzle element of the platformer genre the goal is let people see what they're up against almost as much as possible. This usually means that the restraints we're likely going to put on it include preventing them from zooming too far out and preventing them from seeing the next room or level. That could really pose some problems. Players aren't meant to see the man behind the curtain.

Speaking of cameras and zooming. We've also started work on the parallax backgrounds. Unity has some pretty sweet built in stuff so it makes things incredibly easy for us. There's a little bit of tweaking to do but for the most part we're working actually constructing the backgrounds. This means lots of drawings of scenery and buildings. It also means that it's coming up on time to actually skin the levels. I don't mean taking the skin off of the levels as you might an animal but just the opposite. We have to put all of the tiles and art into the level. As you saw last week it's just a bunch of small boxes with Xs and Os on them to tell us what they mean. In the future you'll see lots of pretty walls, spikes, and various other hazards. We'll just have to deal with the jarring images for now since the tile sets aren't quite ready.

Moving along, just as Bo can now do, we've got Bo running around fully animated now! It's a pretty big step to have the basic animations nearly completed. They don't look quite right just yet but no one really expected them to look perfect from the get-go. We've got a fair bit of tweaking to do and one more large problem that is rearing it's ugly head. Currently we have agreed on a fairly low framerate for the animations. We don't need a 60 fps game. That said the animations are looking a bit staccato with the current setup so we might have to generate some more frames. This isn't necessarily as easy as just pulling the arms in here or there but might require a fair bit more work. Unfortunately we don't have our animator for the entire summer, but we're confident she's up to the challenge.

Lastly we've got a bit more concept art and the tutorial level is starting to take shape. Things are coming along quite nicely even though we're still quite early in the cycle, so lets keep this ball rolling and return to you guys next week.

Week 1: And They're Off!

Hello everybody! Welcome to week 1 of production for Red Sun. I expect that everyone here already knows what's going on but for those of you who don't here's the summary. Red Sun is a capstone project being built by students of Sheridan College here in the great white north, a.k.a. Canada.

We're now a week into the trenches and it's time we took a look at what's already been done and what we have to look forward to.

Starting with the art team. First up is animation. Our resident animator has been working hard at getting Bo's walk/run cycle to look right. This stuff isn't easy as much of the smaller details can really throw off the way it looks but it's going strong and we're well on our way to a very nice looking shepherd. Looking forward there are some concerns about getting other animation sequences just right since it's really hard to turn our wolves into something that has the right feel.

Next up, non-animated art assets. There's a ton of concept art going around the group right now, and you can see why some of it might be hard to translate into real game art. Some of it was done before we got this far in since a whole bunch of pre-production happened during the school semester. These pieces are some of the few things that are getting carried forward. Some of these pieces are really wonderful and some are still getting worked on. We recently saw the Huntsman finished but he's not read for here yet. You'll see plenty of him in the near future.

Also in the art department, we've got some of the background art getting started. Hopefully by next week we'll have some menu backgrounds and maybe, no promises though, some level backgrounds to share with you. Parallax backgrounds can sometimes cause weird issues, especially in 2D games. Since it isn't actually 3D and we're trying to simulate what they would look like in a real 3D environment we have to cheat a little bit. Unfortunately this can cause problems in some cases so it will take a bit of work to get things looking right. Also a concern is Bo's primary movement in the game is upwards and downwards. If you're not familiar with the game, it's going to be a dream-like city-scape. She'll be travelling up and down buildings which stops us from tiling the background the way you could in a side-to-side forest or hill environment.

Music. This isn't something that we are really going to have much of until significantly later in the project. Sensing a theme here? Early on in the development there's a lot of stuff for the programmers to do and the artists are really just getting things rolling so they can get more fancy things and add touch ups to existing assets. That's not to say they aren't working hard, but the fancy stuff that we get to show off comes much later. That said, music falls under the same category. We've had some trouble getting musicians so far. Initially there were two of them that were going to be working with us but they aren't anymore. They got better, and in some cases paying, opportunities. Hopefully we can find someone (or someones) to take their place. If we're really lucky we might have some help finding sound techs through the school.

Now we get to move onto the meaty stuff. The programmers have been very hard at work so far getting a working environment for us. We're using unity, which makes things easier for the designers, and already have a level that can be played through. No framework outside of it but it's an art-less level that has all the things we want in it so far. It's got elevators, switches, buttons, sheep, doors, and a fair bit of death. Working hazards in the level this early really helps get this thing off the ground. We haven't put this into the context of the rest of the game yet but there is concern it might be a bit too easy and that we might have to go back and change things, but that's a process for later in the development cycle and I know I can't wait to test it myself.

Behind the scenes the programmers have also been working on the Wolf AI, more room components, and some basic game infrastructure. You can expect some neat things like gears, conveyor belts, and wolves in the future. Nothing ready to show there yet but from the things I've seen it's looking pretty sweet for it being this early. I expect the momentum to carry on into the summer months.

Things are off to a great start. Sometimes I find it hard to make work for myself but the rest of the team is very hard at work making sure that things are working and look pretty.

Production

The past two weeks have been a break between semesters for the team. There has been brainstorming, concept art, and new team members. This week the primary focus is on scheduling and bringing everyone up to speed on Unity 4.3.4, the version we will be making the game in. While it would be ideal to wait for Unity 5, it looks like it will be coming out too late for us.

The most recent Unity tutorials on making 2D games have been excellent. They are short and to the point. This allows each member of the team to check that their portion of the project, or whatever they happen to be working on at the time, is working correctly. Yay for Unity tutorials.

The final additions to the team bring the head count up to six working full time through the summer. Two designers, two programmers, one animator, and one project manager.

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.

Red Sun on Facebook

The development team is currently putting up a facebook page for the game here: https://www.facebook.com/pages/Red-Sun/626703384065819

The link in temporary and we are looking for an agreeable URL that is not currently in use.

Each team member will be making posts over the next couple of weeks as we start up our production. Most of our documentation is complete and under review from our overseeing faculty.

Tutorials

We have all come together and decided Unity 2D is the way to go for our project and the end pre-production is fast approaching. The prototype has started to form on paper. The programmers have taken to the technical document and building the custom tools we will require. The designers on the other hand have started the GDD appendix. This will outline exactly what pieces will be made in the four months of production as well as a list of all the assets that will need to be produced.  This includes all of the sprite sheets that will have to be made for both the characters and the monsters.

This week the Red Sun team has been going through tutorials. That being said, Unity has put together a 2D tutorial ( http://unity3d.com/learn/tutorials/modules/beginner/2d ) that touches upon all the major areas we'll be working in. Doing the research now will hopefully save us time in the long run as we start building our game.

Living Document and Living Group

The preliminary GDD (Game Design Document) has been completed. That being said, the document is 'living' and will continue to change with the project. We've started setting up our SVN for file sharing so the group can work on different parts of the projects as well as the documentation. Its very important that as the project changes all the members of the group are together and talking about the changes as they happen.

This has brought up the interesting discussion of the democracy vs. the dictatorship group mentalities. Both group designs require leadership, but they are very different in the over all feel of the group. The bottom line to most group discussions have come down to deferring to expertise. Good leadership knows that they can't know everything and being in a group has the great advantage of being able to rely on group members and their working knowledge to make the best choices.

Making a Physical Prototype Kit

Spring break is over and now its time to get back to work. It's time to start prototyping. Physical prototypes can save time and money in the long run by working out mechanics using pencil and paper. There is little initial investment, many of the ideas for a basic kit are house hold items. A few of the more useful items can serve multiple purposes. Several interesting pieces that have been particularly useful are as follows:

Dice:  While these can be used as intended, as a random number generator, an assortment of dice can also be used as counters or uniform game pieces.

Binder Clips: These clips can be used to hold pieces of paper (or other little items) together, latch onto the sides of tables, hold sting, but also can be turned upside down to hold pictures to serve as character markers.

Tiddlywinks: The flat little plastic pieces can be used as markers or counters.

Harvesting pieces from old board games can yield many useful and interesting pieces to use in a prototype. Its a matter of getting creative and having a clear idea of the game before spending the time to make a digital prototype.

Getting It Down on Paper

It might seem obvious, but actually getting ideas articulated and put down on paper can be very difficult in a group of people that have never worked together. It is nice for everyone to have some input and talking out ideas, but there comes a point where all of the nebulous spinning becomes counter productive. Much of this past week has been the team taking the parts of the game most important to them and going off to make visuals to present the rest of the group (and the over seeing faculty). Flow charts and rough concept work is the name of the game at this stage. In the long run, this will help everyone to see exactly what each person is trying to describe and avoid confusion going forward where a great deal of more time will be at risk if assets have to be redone.  

The Great GDD

This week the team has been focused on producing a viable GDD (game design document) for Red Sun. It is a huge undertaking to try to pull together so much information prior to making any prototypes, but our curriculum has us doing it in this order.

Some of the more notable discussions have revolved around the UI. It is ideally all the information the player needs to make informed choices and risks. Ideally keeping the amount of information easy to read and not cluttering the screen has been the goal.

The second discussion has started about extra lives. It seems like an obvious thing to have. The classic 1up is a very common feature in a number of games. As a counter argument though, there are a number of games that have lives where they seem trivial (i.e. the recent mario games) while still being successful. There are others that have opted out of having lives entirely but the player is still able to run into the fail state of dying (usually from running out of health) like Legend of Zelda, Okami, etc.

Both of these aspects of the game have the potential to change the feel of play and going forward it will likely be an unknown until we have a working prototype to play with.

Meaningful Player Choice

Red Sun is a platformer that takes a hard look at play choice as part of its foundation for compelling game play. Below is a brief look at the different types of player choice and a few examples of how they have been used in the past and how they are being used now. 

Player choice has been a driving force behind compelling game play. There are many different kinds of choice a player is asked to make in games. The most prevalent of these choices is arbitrary choice that happens in the natural choice in game play. These choices can be showcased in the presentation of a set of stairs. A player may jump up the stairs or walk up them, it is a choice but the outcome to this choice does not impact the game beyond the moment the choice is made. The second form choice takes is calculated choice. These choices have a right and wrong answer such as picking a sword that has plus 8 attack power over one that has a plus 7 attack. Picking the sword with the higher attack power grants the player benefit on a calculable level. The third form of choice, and the focus of this brief discussion, is meaningful choice. This involves direct impact of game play or player experience through the choices which do not necessarily have a right or wrong answer. This is often presented as a conflict of desires a player may have. They can only choose to do one of two or more of these actions to resolve said conflict. (Source: http://www.gamasutra.com/view/feature/130452/improving_player_choices.php?print=1 )

As far back the first Super Mario Bros released for the Nintendo Entertainment System in 1985 there was meaningful player choice, at least in its most basic form. The mushrooms represented a power up to Mario, who both grew in size and became more durable upon obtaining, but the conflict was presented by the movement of these power ups. Upon being revealed they rapidly started to move away, off screen and the player was putting themselves at risk of death by perusing. The conflict presented has a risk and reward that was clearly put before the player and a very small amount of time to make the choice as soon as the mushroom was on the move to make it in. (Play Super Mario Online: http://www.dan-dare.org/FreeFun/Games/More/NewMarioFlash.htm )

A second example of early meaningful player choice could be observed in Icewind Dale (2000 release). The character creation did not have a right or wrong answer depending on what manner of tactics the player wished to employ over the course of the game, but the experience of the player was drastically different depending on if they chose to be a magic user or melee character. The conflict became making a character appropriate for tactic choice before seeing the battle field and being flexible during game play to adjust.

Following in the footsteps of Icewind Dale, the most recent release in the Fire Emblem series, Awakening continues to offer more choice to the play through the game. A player is presented with far more units than can be brought along or leveled in a single play through and must choose which units they wish to use. (Source: http://ramblingofagamer.blogspot.ca/2013/06/fire-emblem-and-player-choice.html ) The units are able to assist each other in battle and gain bonus for doing so. On top of the tactic level of play, the units make up support groups which tie into story elements. The story and player experience changes depending on which units are used and how they interact together during the story progression.

A recent example that involved the change of choice type was that of the World of Warcraft talent tree. Prior to the Cataclysm expansion in December of 2010 there was a clear, calculable choice for optimum characters in the talent tree. There was a correct configuration because it gave a distinct numerical advantage over every other combination of talents. After the release of Cataclysm the talent trees were overhauled to choices based primarily on player preference. The benefits given for each arrangements of the talents were more a comparison of apples and oranges than any direct evaluation of numbers. (Source: http://us.battle.net/blizzcon/en/blog/3773320 )

Player choice is a hotly debated topic and is continually evolving in the industry but there are two variants I would like to propose for the Red Sun Project. Moral and ethical questions were popularized in dialogue trees in recent years in games such as Mass Effect and Dragon Age. My first variant would be to take a step back and reintegrate complicated questions into player actions. Often in games the enemy units are presented to a player and they must be killed, destroyed, or otherwise disabled for the player to progress. My proposal would be to allow the player to actively be able to choose not to engage in combat if they don't want to. It may be more difficult or take more time, but the player would be able to bypass enemy units by performing puzzle tasks and going around. This variant is grounded in reality with the idea that when people are presented with an obstacle, for example someone in their way, they are able to take the time to avoid them. This presents fighting as a moral question. The fastest and most direct route is violent and frowned upon. To go around is the moral high ground but time consuming. Building on this could have aesthetic implications such as the violent actions leading to the levels looking increasingly dark or evil looking and the plot could become darker. The reserve of which would be the levels looking more colorful or pleasant with the morally right choices. This would make each choice have a clear impact and allow the player to have immediate feedback on their decisions.

A second variant would be to present ongoing player/npc relationships. There are many games that look at relationships as a switch. You are with or against them, but in reality there is some variation in most relationships where the level of closeness fluctuates. This would lead to a dynamic set of benefits that are either mutually exclusive or have a drastically higher cost to get both. If you are presented with two options by two NPCs, for example going to level A or level B first, the one you choose to go to first (let us say level A) will make your relationship with that NPC closer and they may come to assist you on doing that level and it is completable faster. You can then do level B, but the NPC that proposed going there first is angry with you and will not come to help. The player is able to go through both levels but the experience going to both is different depending on the order which they are taken.

Green-light Completed, Onward!

Tuesday was a big day for the project. The team presented a 20 minute green-light presentation about the three pillars around which the rest of the game will be made. The image to the left was the cover page for the presentation and serves as a mock box art.

Our main focus for the platformer at this time is as follows:

- Puzzle solving and world manipulation
- Aesthetic
- Player Choice

The front runners for the game engine choices are Unity 2D and Cocos. There are advantages and disadvantages to both. Our team as a whole has far more experience using Unity , uses C#,  and its developer interface is friendlier to designers. Cocos on the other hand uses C++ and has Box 2D as a  physics package making it attractive to the programmers.

Over the next couple of weeks we are moving towards paper and eventually programmed prototypes. We'll have to make our choice on engine together based on whats best for our skill set and run with it.

Green-light Process

This week the team has been working hard to pull together concept work for the green-light pitch on Tuesday. This includes but is not limited to character turnarounds and mock level proposals that will, in combination with our PowerPoint, convince the faculty to allow us to proceed to prototyping. One of the tools we are putting to use for describing more complicated mechanics is stop motion images of simple boxes performing tasks as we would envision them working in the game. The gif above is one of these series of images strung together for easy viewing.

Making a Game: The Start

This is the development journal for "Red Sun." The project was conceived as a capstone for the end of the one year post graduate programs: Game Level Design and Game Development - Advanced Programming at Sheridan College. The projects current schedule is 4 months of pre-production through which the team will also be attending classes full time and 4 months of production over the summer through which the team will be working exclusively on the game.


This game in currently in pre-production and will be in flux all through its development process to end of August 2014.