Thursday, May 4, 2017

Weekly Update (2017-05-04): Benjamin

This week, we worked on planning out what we will work on for the next three weeks in order to have a playable game.

Planning Process

First, we wrote down a list of tasks that we thought were necassary for a playable game. Then, after cleaning up asana, we entered them into asana with due dates. I will talk in more detail about the tasks that I am planning on doing below.

Refactoring the State System

Our current system for handling airplane states (flying, landing, etc.) is a good start, but it has a lot of ugly bits. I'm trying to clean this up before we add a bunch more states. The idea is that by adding a deeper inheritance heirarchy for the components of an airplane state, we can avoid the huge amount of code duplication that is going on now.

An example of this duplication is that all three states that we have right now need to draw an airplane at a position on the screen. We currently have almost identical code for drawing the airplane in each of these cases. Instead, I am going to create a class called AirplaneVisible which handles the drawing. AirplaneVisible does not assume that an airplane has an altitude because that is not needed to draw an airplane.

Fix Collisions

There are currently a few issues with the collision system. Primarily, we need to balance it so that it isn't too easy to cause collisions, but it still happens. One of the other issues involved here is the balance between realism and having a fun game. The other main issue that I want to work on is the animation for collision. Currently, when you are zoomed in on one spot, but a collision occurs completely outside the view frame, the pan-zoom thing will not work. This should be pretty easy to fix.

Weekly Update (2017-05-04): Liam

This Week

The main advance I made this week was departures. Airplanes start on the runway, accelerate, and then move into the flying state. Right now this happens randomly, but I plan to add a queueing system later.

I also made several minor improvements to gameplay, including:
  • Changing the ascent and descent rate to make it more reasonable
  • Adding a handoff button for flyovers and departures (not yet functional)
  • Removing planes that have landed
  • Added descent during landing (not yet fully implemented)
  • Added a "cancel" button for landing airplanes
Here's a screenshot of a departure on the runway and the new cancel button:

Tasks completed:

  • Implement departures
  • Add landing capabilities

Next Week

Now that we've migrated to a new task list, I plan to add functionality for the handoff button and descent during landing (properly).

Asana tasks to complete:

  • Make final map
  • Implement flyover & departure targets
  • Fix altitude implementation

Weekly Update (2017-05-04): Guy

This Week:

This week i did several things. I added a pause button, which stops the game and movement of the planes. I also finished the rough main menu. There is a placeholder logo and a play button which will move the game to the play screen to start the game. I started work on the points system and we talked about what the next three weeks should entail. We cleaned our branches and added new ones for our current tasks and started a new asana document, moving to the updated system. Here is what the main menu looks like so far.

Next Week:

Next week my task is to add a points system. Currently there is no way to win or lose, so points will be a start of that. There will be points for landing, taking off, and crashing, all variable on the difficulty and negative or positive impact they have.

Asana Tasks:

  • Add Main Menu
  • Fix Branch System
  • Add points system(incomplete)

Thursday, April 20, 2017

Weekly Update (2017-04-20): Liam

This Week

I added landing constraints for airplanes. If they are too close to the end of the runway, or pointing more than 30 degrees off the heading of the runway, or positioned outside of a 30-degree sector at the end of the runway, the airplane will not be allowed to land.


Asana Tasks Completed

  • Add landing constraints

Next Week

In this process, I noticed a couple of weird bugs involving landing: sometimes an airplane won't land even if it's perfectly lined up with the runway, and it won't land at all if time-warp is on.

Asana Tasks

  • Determine scale of airport
  • Add landing capabilities: descent, remove landed planes from runway
  • Fix landing bugs
  • Add collision warnings

Weekly Update (2017-04-20): Guy

This Week:

This week I started off on Tuesday by fixing a mistake I made over the weekend with Github. I had commited an old version of the code from my home computer while attempting to pull the current version on Github. I had to find out how to delete a commit and revert it back to how it was initially. On Thursday I worked on the design doc and added a section for The Main Menu and how it will look and work. I have not completed it yet, but its pretty straightforward.

Next Week:

Next week I will complete the page on the main menu and hopefully add it to our Gitbook design doc as well because it was not working this week. Then I will start work on the it. That should take up[ most of the week, as its creating a new screen from scratch essentially.

Asana Tasks:

  • Main Menu

Friday, April 14, 2017

Weekly Update (2017-04-14): Benjamin

This week, I added a debug time warp system as well as a UI for viewing more information about planes.

Time Warp

We found that often, while testing the game, things would be going to slowly and we would spend a lot of time waiting around. The solution is a developer only time warp. Time warp is pretty simple. The main idea is that dt gets multiplied by a warp value, which can be changed with buttons. (Asana task: time warp)

Plane UI

Previously, each plane would have a lot of information associated with it like name and flight type which were inacessible to the user. To show this information, I created a box which shows up in the upper right hand corner when an airplane is selected. This box provides information about the airplane. (Asana task: add UI for flight type)




Next Week

I plan on starting work on some of the tasks listed under "Minimum Playable Tasks". Specifically, I plan on adding either collisions or setting other airports as destinations.

Weekly Update (2017-04-14): Liam

This Week

I didn't have a whole lot of class time this week since I missed class on Wednesday, but I accomplished some small changes. I fixed the positioning of the text (yet again--it was destroyed during a merge) and started implementing landing constraints. I added the easiest part first: if an airplane is too close to the runway, it can't begin to land.


Asana Tasks Completed

  • Add landing constraints: distance

Next Week

I plan to continue implementing landing constraints and then move on to collisions.

Asana Tasks

  • Add collision warnings
  • Add landing constraints

Weekly Update (2017-04-14): Guy

This Week:

This week I added functionality to the buttons on the home screen. The one button I have now changed the screen from the Main Menu to the game state. Now that we have this we can easily implement buttons to another screen such as a settings screen. It is also possible now to all have the same code for ProjectIcarus class since there is no need for each of us to go to a different initial screen.

Next Week:

Next week I haven't really thought about. This has been the main project that i have been working on so we will have to discuss what other parts of the game we want to implement in the future. It is likely i will be working on making a usable main menu so Ill start with that.

Asana Tasks:

  • Main Menu

Wednesday, April 12, 2017

Weekly Update (2017-03-03): Benjamin

This week, I worked only on the autopilot. I'm not done yet, but I think that I am getting close. Because of this, I have not checked off any Asana tasks.

Autopilot

What the whiteboard looks like right now

We have a draft of an algorithm:

The heading of the plane is $\vec{a}$, the position of the plane is $\vec{b}$, the target point on the runway is $\vec{d}$, and the heading of the runway is $\vec{c}$. First, we turn towards the runway until $\vec{a} \cdot (\vec{d} - \vec{a}) < 0$

Friday, April 7, 2017

Weekly Update (2017-04-07): Benjamin

This week I worked on altitude control and landing systems. We now have a working system for changing altitude as well as a (semi) working system for switching to landed state.

Altitude Control

For altitude control, when you press a button, an altitude target counter will pop up. Dragging up and down will change the target altitude. Tapping will select the altitude. After a target altitude is selected, the airplane will change altitude at a constant rate in order to match it.


Landing

The landing mechanism currently used will cause airplanes which go close enough to the end of a runway while attempting to land on it to stop displaying their altitude and start slowing down to a stop on the runway. Internally, this involved a lot of refactoring. The idea is that individual behavior states for an airplane should be their own classes (deriving from one AirplaneState) base class. This way, things which only make sense in a given state are not implemented by other states.

Next Week

Implementing landing caused a regression in the landing autopilot system. Now, airplanes often end up slightly off the runway when attempting to land:

I don't know exactly what is causing this yet, but I suspect that the turning radius calculation is incorrect.

Asana Tasks

  • Refactoring

Weekly Update (2017-03-17): Guy

This Week:

This week I got the switching down and was starting to work on the main menu by adding buttons and styling. Soon after I figured this out I started getting nothing to show up on the screen and then after started getting crashes. I went through the changes that were showing up in git bash and then tried to reverse the ones I didnt think were necessary. In doing this it seemed to almost do nothing, as I still got crashes and had an error. I found that the error has something to do with getWidth and will fix it next week.

Next Week:

This coming week ill fix the bug with getWidth and hopefully add a button to the main menu. Currently it doesnt show anything, but once i figure out the issue i can add the button and make it so we can use the same code on the master branch.

Asana Tasks:

  • Main Menu(incomplete)

Weekly Update (2017-04-07): Guy

This Week:

In the past week I worked on implementing a button that will switch screens in the game. I stopped trying to use the buttons we used in our game previously and used buttons that are called imagebuttons. This seems to be working so far, but I have run into the same problem that I had with the other button type. I currently cant change screens with the button, and there isnt an error. Ill have to compare the code from John's game to mine and see what I am missing or added accidentally.

Next Week:

Next week i should be trying to add the fully functional button to master. If I can get it to do that then i will add another screen for settings and possibly another for a different function. The first thing ill try next week will be to find the error in the code.Once I do that i think it will be smooth sailing for whatever i need to do next, which i have not figured out yet.

Asana Tasks:

  • Main Menu(incomplete)

Weekly Update (2017-04-07): Liam

This Week

While Benjamin worked on refactoring the airplane code, I fixed some small UI problems that have been bugging me for a while. I made the airplane labels smaller and farther away from the airplane, and I fixed the positioning of the runway labels. I also created a new map, with properly aligned waypoints and non-overlapping labels.

Before the changes. Note the overlapping text.

New map

New airplane label

Asana Tasks Completed

  • Fix label positions
  • Implement final airport

Next Week

I plan to merge Benjamin's changes in landing-experiment with plane-control, and eventually with master. Then I wan to finish up the landing algorithm, either at the end of next week or the beginning of the week after.

Asana Tasks

  • Determine scale of airport
  • Add landing capabilities
  • Add landing constraints

Thursday, March 23, 2017

Weekly Update (2017-03-23): Guy

This Week:

This week I figured out how to implement a button onto the screen. After a number of errors, i was actually just using the button wrong as ididnt fully understand the code. With help from Liam i fixed it and the button became implemented. It is there, however, it doesnt work and nothing happens when you press it.

Next Week:

Week I will be trying to get the button to open the actual game. Once i do that we can all use the same code for the Master branch, instead of having it go to different classes when opened. Once i figure out the problem with changing screens using the buttons we can all just go to MainMenuScreen and click the ubtton to get to PI Screen which will be helpful in merging later on.

Asana Tasks:

  • Main Menu(incomplete)

Weekly Update (2017-03-23): Liam

This Week

I looked into a reasonable scale for the airport. Right now, distances are measured in pixels, which makes realism hard. It's also hard to determine how fast an airplane should descend and decelerate; it seems to vary based on the aircraft, so we'll probably just choose a reasonable number and use that. I've decided to try a scale of 100 meters per pixel, but before that can be used in the game we need to implement it in the editor.

On a more minor note, certain controls are now disabled for flyover flights. The player shouldn't be able to tell flyovers to land at or circle the airport.

Arrivals have full controls

Flyovers can only change direction and altitude

Asana Tasks Completed

  • Implement flight types

Next Week

I plan to finish (finally!) the airplane landing algorithm, incorporating descent and deceleration.

Asana Tasks

  • Determine scale of airport
  • Add landing capabilities
  • Add landing constraints

Friday, March 17, 2017

Weekly Update (2017-03-17): Liam

This Week

The big breakthrough this week was implementing a landing A.I. The player selects an airplane, then selects the end of a target runway, and the airplane tries to land. This won't always work, but any edge cases won't allow the user to land, anyway. Basically, the airplane first turns toward the runway, then at the last second straightens out. Right now it doesn't deal with altitude or speed, but getting this far was a lot of work; Benjamin and I spent 3 or 4 class periods on the equations.

Pointing towards the runway

Lining up

"Landed"

Asana Tasks Completed

  • Add airplane states
  • Add enum to Airplane class

Next Week

I plan to complete the A.I. by adding deceleration and descent. I'll also add more constraints on how the player can control arrivals, departures, and flyovers

Asana Tasks To Do

  • Add landing capabilities
  • Add landing constraints
  • Implement flight types

Weekly Update (2017-03-17): Benjamin

This week, I spent most of the time finishing the landing algorithm with liam. We finally got it working. Now, I am working on a UI for changing altitude.

Landing

IT WORKS!!!!!!!!
Our final algorithm is extremely simple. The first step is to turn until the airplane is pointing inside the line that goes towards the end of the runway. This makes sure that there is enough room to turn facing the runway once the airplane gets to the intersection. Next, we find the intersection between the airplane's line and the line of the runway. The angle between the airplane and the runway is used to calculate the distance from the intersection at which the turn should start.
\[\frac{\sin{\frac{\alpha}{2}}}{r} = \frac{\sin{\frac{\pi}{2} - \frac{\alpha}{2}}}{d}\]
\[d = \frac{\sin{\frac{\pi}{2} - \frac{\alpha}{2}}}{\frac{\sin{\frac{\alpha}{2}}}{r}}\]
Then, the plane simply has to wait until it is the specified distance from the intersection. The end result is that the plane will do an S-curve to bring it both colinear and parllel to the runway.

Altitude Adjustment

The placeholder altitude adjustment system is that dragging on the screen will change the target altitude and tapping will send the command.

Asana Tasks

  • Me and Liam: Autopilot
  • Fix rotation of runway labels
  • Airplane controls -> altitude

Friday, March 3, 2017

Weekly Update (2017-03-03): Liam

This Week

While Benjamin worked on a landing algorithm, I fixed a nagging issue with the way the map is displayed. The status bar on the bottom of the screen is drawn over the map, which means that even when the user pans down as far as possible, some of the map is still blocked by the status bar. I made it so the game allows you to pan further than the boundaries of the map, just enough so that the bottom of the map aligns with the top of the status bar. This will also be useful when we add a side bar later.

I also added spontaneous airplane generation: airplanes appear around the edges of the screen, distributed randomly, at random time intervals between 4 and 30 seconds.

How far the user could pan down before:


After, with airplane generation:


Completed Asana Tasks

  • Implement airplane generation
  • Stop status bar from blocking bottom portion of map
  • Add airplanes at random time intervals

Next Week

I plan on helping Benjamin finish the landing autopilot. I also plan on implementing altitude and rates of descent.

Current Asana Tasks

  • Add airplane controls
  • Add airplane constraints
  • Add landing capabilities


Weekly Update (2017-03-03): Guy

This Week:

This week I continued working on screens. I worked mainly on figuring out how to change screens from one to another. The main error I found was in figuring out what each screen needed in order to change it. I also had an issue with showing up a button in order to change the screens from the screen. Since then I have ran into another error that continuously crashes the game which I need to figure out. Once that is done I'll move to the button error

Next Week:

So next week I need to figure out what the error is that is making the game crash when opened. I think it has something to do with how I am changing the screens, however, I have not figured it out yet. After that I need to be able to change the screens. The button isn't working so far so I cannot make sure the changing screen code works so that will be the next step in order to troubleshoot the rest of the code.

Asana Tasks:

  • Main Menu(incomplete)

Thursday, February 23, 2017

Weekly Update (2017-02-23): Liam

This Week

I started work on landing and taking off. During this process I realized that we need to define a scale for the map, so that the runway lengths and the size of the map will be reasonable. For the plane to be able to land, it needs to be within a certain angle and area and below a certain altitude (this will eventually depend on the airplane's distance from the runway, but right now these values are constants). Today I added the first step: when a runway is selected, the game calculates if the airplane is within an angle of 10 degrees from the heading of the runway:


Notice the status bar says that the upper right airplane is about 5 degrees off from the runway's heading.

I also worked on merging Guy's work on the menu branch with master. Now, the code has been reorganized so the main class only controls the screen and the UI state.

Completed Asana Tasks

  • Clean up code in PIScreen
  • Decide on fixed turn rate

Next Week

I will continue to work on landing constraints and procedures. I need to add an altitude and heading constraint, and then start working on an AI to automatically land the airplane.

Current Asana Tasks

  • Add airplane controls
  • Add airplane constraints
  • Add landing capabilities

Weekly Update (2017-02-23): Benjamin

This week, I added many usability improvements to the editor to get it ready for creating airports for the real game. Mainly, this was a bunch of small improvements rather than one big feature. The largest feature that was implemented was support for loading existing levels.

  • Support for dragging existing runways around after they are created
  • A better system for snapping runways
  • The ability to snap waypoints to be colinear with any runway
  • A scale guide in the bottom left hand corner (1px=50m)
  • Solving a bug in which all of the airport coordinates would be inverted between the editor and the game


Loading Airports

Loading airports was relatively easy, since they are stored as JSON with very similar structure to that used internally by the editor. The main issue was that, in order to solve the level inversion bug, levels are stored upside down. Because of this, a level would be loaded upside down. I solved this by running the inverse of the transform used for saving.

Next Week: Autopilot

Next week, I plan on implementing the landing autopilot. Liam has a system set up that will determine whether it is possible to land from a particular position, but this system does not actually land the planes yet. The problem is that there are infinite solutions for landing on a runway given a particular position.

This hypothetical system needs to, given a plane within 10 degrees of being colinear with the runway and a heading of within 10 degrees of being parallel with the runway, find a set of commands which will bring it into being both perfectly parallel and perfectly colinear.

In order to think about this problem, I am first solving the simplified case: the plane is parallel with the runway but not colinear. In addition, the plane has to be far enough away that it does not have to slow down while making the turn. In this situation, the best solution is to turn away from parallel until you are halfway to being colinear. After that, it needs to turn back. This will form an S-shaped curve which brings it into the correct position and direction.

In a situation in which the plane is not parallel, already colinear, or close enough to slow down, things get much harder. Instead of making a simple S-curve, you might have to make a more complex turn to line up which includes overshooting for a little bit before turning back. Things get even worse when you have to slow down. This will probably involve a lot of calculus. Yay!

Weekly Update (2017-02-23): Guy

This Week:

This week I finally successfully created separate screens. They each are their own class and in the ProjectIcarus class you can send the game to any of them. We merged mennus with master and now in our main code we have separate screens. After I finished this I started working on the MainMenuScreen. I almost have it I believe but there is now one line of code that has an error and I need to fix. So for now, the code works as intended, just with more expandability on the back end.


Next Week:

Currently, I am working on making sure the code can switch between screens from each screen and an action on the screen. I think I am relatively close to completing this however, I only had a limited time to test is and as of yet it is not working. The majority of next week will likely be filled with completing the main menu and making sure it can successfully navigate to separate screens while maintaining those screens functionality. This shouldnt be too hard, and after that we likely will need to decide the art style of the game, to make everything fit and look smooth.

Asana Tasks:

  • Menu
  • Main Menu(incomplete)

Thursday, February 16, 2017

Weekly Update (2017-02-16): Liam

This Week

I started the process of implementing takeoff and landing. Benjamin added runways to the editor, so after that was up and running I created a different test airport map, with runways in the center and some creative waypoint names:


Today (Thursday) I added runway selection. Users can't select the whole runway, because there would be problems at intersections, but there is a hit circle at each end of the runway. So far airplanes don't do anything when a runway is selected, but I'm working on that.


I also fixed the minor issue where the angle on the heading selection wheel wasn't accurate. Turns out I was measuring from the bottom of the button, thinking that I was measuring from the bottom left corner of the app. Oops.

Asana Tasks Completed

  • Add target heading button

Next Week

I will continue to work on takeoff and landing, and hopefully by Friday I will have the airplanes navigate to runways.

Current Asana Tasks

  • Fix Airport orientation
  • Add airplane controls
  • Add airplane constraints

Weekly Update: Benjamin Lee (2017-16-10)

I worked more on the runway system and general improvements on the editor.

Editor Improvements

One of the focuses this week was on getting the editor ready for use in creating real levels. For this, I added support for selecting existing runways and a few other quality of life improvements. Next week I plan on adding the main missing feature: loading existing airports from JSON.

Labels

 

Runway labels are pretty much complete at this point.  The way that they work is that the user enters the angle and distance for the center of the text to each end of the runway in the editor. In addition, the app can load these names and display them.

One issue for this was that since the player can zoom, the offset has to be in screen coordinates, not world coordinates. Otherwise, the labels will overlap the runways at some zoom levels.

Friday, February 10, 2017

Weekly Update: Benjamin Lee (2017-2-10)

This week, I worked on completing the runway system. I added runway loading to the game, and started work on runway labels.

Runways in the App

I added runway loading from JSON into the app in the game. This involved some refactoring of the rest of the airport loader. I found out that drawing lines in libgdx is way harder than it should be.

Labels

The problem for adding labels is that they have to be both easily associated with the target runway, and not overlap other runways. The best way that we came up with to do this is to make two parameters done by the level editor: angle and distance. I drew a diagram of this system:


I ended up having font problems and got caught up in trying to convert a BDF into a TTF.

Weekly Update (2017-02-10): Guy

This Week:

This week I worked on implementing separate screens or pages for the app. I went through another example this week, but ultimately made a major mistake that required I wipe the code I made and start over. Even though I achieved nothing tactile this week I achieved the knowledge of how to do it next week and successfully have multiple screens. The mistake i made was trying to keep the ProjectIcarus class as the GameScreen class, when it should be made the GameClass. 

Next Week:

So next week i will transfer all the game data from ProjectIcarus into GameScreen and hopefully it will work. I think this will be the end of the project of creating screens in this game, hopefully. After that I dont have any plans on what to do next. But it will likely include making a more detailed main menu page. Transfer between the pages should be more easy in the game as well.

Asana Tasks:

  • Menu(incomplete)

Weekly Update (2017-02-10): Liam

This Week

This week I worked entirely on adding a heading selection wheel. When an airplane is selected, the user can press a button which will make a selection wheel pop up in the middle of the map. The user can drag their finger along the wheel until they find the angle they desire. When they release their finger, the airplane will turn to that heading. Here are some screenshots:




One issue right now is that the angle isn't exactly right when the user releases their finger.

Asana Tasks Completed

  • Add target heading button

Next Week

I plan to fix the angle selection issue with the heading wheel, and then start implementing airplanes.

Current Asana Tasks

  • Add airplane controls
  • Add airplane constraints


Thursday, February 2, 2017

Weekly Update (2017-02-02): Liam

This Week

I accomplished a few minor items, such as making UI elements density independent. My main achievement this week was implementing airplane navigation to waypoints. We decided to add waypoint selection as an enum, so that waypoints could only be selected if the user pressed the "Navigate to waypoint" button. This wasn't too hard to implement, but I was plagued with the problem that airplanes would always be a little off target:
These airplanes were all instructed to fly to waypoint ABC, but as you can see most of them missed the mark. I discovered that this wasn't a problem with the targeting system; rather, airplane sprites were being drawn in the wrong places. After much debugging and a simple fix, everything worked beautifully:

Asana Tasks Completed

  • Refactor with singleton
  • Make UI elements density independent
  • Add maneuver to waypoint

Next Week

In addition to turning to a waypoint, I want the airplanes to be able to turn to a specific heading. I plan to implement some sort of user input interface for heading, altitude, and perhaps other controls as well. The next major item to add will be runways.

Current Asana Tasks

  • Add airplane controls
  • Add airplane constraints

Weekly Update (2017-2-2): Benjamin

This week, I only had two classes, but I worked on fixing bugs the first day and on implementing runways the second day.

Runways

I have started the implementation for creating runways in the editor. The main challenge here is giving the editor precision. For the first step, I looked at some real airport runway maps:

http://photodesk.chicagotribune.com.s3.amazonaws.com/Graphics/runway-diagram-0728.png 
 https://www.faa.gov/nextgen/snapshots/assets/img/airports/maps/SLC.png


There are a few things that I noticed:
  • Lots of parallel lines
  • Perpendicular lines
  • Aligning with the X, Y, and 45 degree axes
To implement this in the editor, I used a snapping system which makes it easy to do these things precisely.

Small Changes

  • I made a new map that has more recognizable waypoint names to use in debugging
  • Worked with liam on airplane control

Weekly Update (2017-02-02): Guy

Thursday, February 2, 2017

Weekly Update (2017-02-02): Guy


This Week:

This week I attempted further to implement multiple pages for our app. I tried several different sources, initially this seemed promising, however, there was a lot of difficulties with the way that it was implemented and I ended up scrapping the project I was working on because there were too many errors and it was faster to wipe than to fix all the errors. The new source I am using is this one and it seems much simpler and so far is working. Ill see next week if it continues to be helpful.

Next Week:

Next week I plan to continue on this tutorial on screens and possibly finish implementing them and move on to creating the ui for the mainmenu screen. This will likely intail many buttons and changing between screens.

Asana Tasks:

  • Menu(incomplete)

Thursday, January 26, 2017

Weekly Update (2017-01-26): Liam

This Week

I spent most of my time allowing the user to interact with the airplanes in the app. Benjamin and I implemented a system to select airplanes, and I worked on making the camera follow the selected airplane. I also made the airplane control buttons appear when an airplane is selected and disappear when it is deselected. I also made sure UI elements were density-independent.

This is the game initially:
And this is the game when an airplane is selected:

Completed Asana Tasks:

  • Remove unused branches
  • Add airplane selection system
  • Implement plane movement
  • Make UI elements density independent
  • Refactor with singleton

Next Week

Next week I plan on making the game a lot more playable. I'm going to implement a lot of user controls for airplanes, like navigating to waypoints and altitudes.

Current Asana Tasks:

  • Add airplane controls
  • Add airplane constraints

Weekly Update (2017-26-1): Benjamin

This week, I worked on improving the UI system and fixed minor problems and annoying bugs.

Status Line

One of the major systems completed this week is the status line. In the game, this line will display context information and respond to user commands. This line appears on the bottom of the screen, and adjusts height based on the screen resolution to match the font size. ("Status line")

A challenge encountered in implementing the status line was that there was no way to access the log method from everywhere in the application. This was solved using the singleton design pattern. (Further work done by liam: "Refactor with singleton")



Small Changes

  • I added a small feature to disable the airplane tracking system when you attempt to pan. ("Stop following airplanes after panning")
  • I decreased the size of airplanes so that they were less ridiculously large. ("Make airplanes smaller")
  • I finished up the ui branch and merged it into master ("Merge ui with master")
  • I made several text displays in the game scale size based on screen resolution ("Scale font size to resolution")

Next Week

I am planning on making another refactoring pass over all of the code. There is a lot of commented out code sitting around that can be removed, and a lot of things left over from before ProjectIcarus had singleton. We are aiming for full airplane control next week.

Guy 1/26

1/26/17

This Week

This week I worked on creating screens. I looked at several different examples, initially trying to implement this example, however, there were a number of documentation changes since this was posted, making my attempt at implementing challenging, and eventually I moved on from it. I then tried reading the documentation, however, my problem didn't seem to have a fix. I moved to this example, which proved more useful. I got to a point where I had only one error, and looking at the documentation again I believe that the problem has to do with setting the screen as a game and not a screen instead. This led to the end of the day on Friday.

Next Week

For next week I plan to finish implementing different screens to allow change on the press of a button or another action possibly. After that I may try and figure out pop-ups, however, we are not at that point yet.

Asana Tasks

  • Menu(incomplete)