This week was all about midterm and preparing for break. Not much additional programming was done due to the fact that we just finished our sprint towards midterm and GMGF.
We did have two substantial contributions to moving our game forward outside of bug fixes. The new player model has finally been finished and as such we had to implement the new player into the existing levels and swap out the old one. The layout of the player changed drastically so the way our scripts communicated between the shield and the actual player had to be modified to compensate. We also had to re hook up all the visual effects and scale colliders so that this new player felt exactly like the old, just looking much cooler.
Other than that, VXT being a game all about high scores we made changes to our high score screen online allowing for more attractively viewable content. The highscores from green mountain games fest has been immortalized on our website in a much nicer and more dynamic layout then before.
We also planned on moving forward. The following week is our "spring break" which is code word for time you get to work on all of your projects while not having to go to class. We have a lot of levels that need to be made and the plan is to bust out a 5 more over the course of our break. This will inevitably come with bug fixes, polish and graphics programming to make these levels really pop.
More the the programming front, after seeing what happened during Green Mountain Games Fest, and knowing that those computer will be what we are programming on, we will need to make heavy advances to optimizing our game so that it can run at top efficiency for the senior show.
Friday, February 28, 2014
Friday, February 21, 2014
Capstone Green Mountain Game Fest
Green Mountain Game Festival is an event created by students are located with in Champlain college to show off independent game development in the Northeast many games will be on display with a handful of developers from outside of the Vermont area attending as well. This event goes down this Saturday which is why this last week as all about getting ourselves ready to present VXT at this event.
To do so we need to make our first draft level much better, after a few rounds of testing we had a list of changes to our major mechanics to make them much more user friendly and enjoyable. Some examples for thing that changed are as followed
Boost Mechanic - We changed the controls around so that the left trigger is now what activates the boost, we change it so it requires more collectibles to gain speed, and most importantly made it so you can aim the direction of the boost instead of just increasing your current velocity by a magnitude. You can aim the direction by now pointing your shield in the direction you are going.
Slip Stream - We fixed a lot of the preform bugs due to physic being applied to every spawned particle. We changed how the player moved from setting position to applying forces to our player to make much smoother movement. Finally we allow the player to keep the massive velocity they gain while going through the slipstream allowing them to be propelled out of the end of it reaching amazing speeds, making it so satisfying to use.
Moving Platforms- Moving platforms allow players to have more dynamic obstacles however getting the timing right so that the platform was where it needed to be when the player arrived wasn't working out. So to fix that problem as well as putting more emphasis into the use of our shield, we made it so the platforms lay dormant and carry a color then when a player touches the moving platform it will active starting the movement, this way the platform only moves if the player is there.
Besides tweaks to these mechanics in order to prepare for Green Mountain Games we needed to make sure our game could play as if inside a kiosk. We revamped our menu system allowing quick and easy additions of levels to make expansion easier. We fixed pausing and restarting of levels so that player quickly swapping out wont have a problems starting and new. And most importantly in the spirit of competition (which our game thrives on) we made out global online high scores dynamic per level name and this way anyone who plays our game on Saturday and preforms well will be immortalized forever on the online high scores of the VXT Green Mountain Games levels high scores at themidnightacos.com
This Friday we are jamming out to get the most we can get done before the event. Wish us luck as midterms are right around the corner.
Until next time!
-Ian
To do so we need to make our first draft level much better, after a few rounds of testing we had a list of changes to our major mechanics to make them much more user friendly and enjoyable. Some examples for thing that changed are as followed
Boost Mechanic - We changed the controls around so that the left trigger is now what activates the boost, we change it so it requires more collectibles to gain speed, and most importantly made it so you can aim the direction of the boost instead of just increasing your current velocity by a magnitude. You can aim the direction by now pointing your shield in the direction you are going.
Slip Stream - We fixed a lot of the preform bugs due to physic being applied to every spawned particle. We changed how the player moved from setting position to applying forces to our player to make much smoother movement. Finally we allow the player to keep the massive velocity they gain while going through the slipstream allowing them to be propelled out of the end of it reaching amazing speeds, making it so satisfying to use.
Moving Platforms- Moving platforms allow players to have more dynamic obstacles however getting the timing right so that the platform was where it needed to be when the player arrived wasn't working out. So to fix that problem as well as putting more emphasis into the use of our shield, we made it so the platforms lay dormant and carry a color then when a player touches the moving platform it will active starting the movement, this way the platform only moves if the player is there.
Besides tweaks to these mechanics in order to prepare for Green Mountain Games we needed to make sure our game could play as if inside a kiosk. We revamped our menu system allowing quick and easy additions of levels to make expansion easier. We fixed pausing and restarting of levels so that player quickly swapping out wont have a problems starting and new. And most importantly in the spirit of competition (which our game thrives on) we made out global online high scores dynamic per level name and this way anyone who plays our game on Saturday and preforms well will be immortalized forever on the online high scores of the VXT Green Mountain Games levels high scores at themidnightacos.com
This Friday we are jamming out to get the most we can get done before the event. Wish us luck as midterms are right around the corner.
Until next time!
-Ian
Sunday, February 16, 2014
REST Calls, caching, and threading on Android
Recently I was granted access to Riot Games API allowing me to finally create a League of Legends app. I've had a decent amount of experience of making basic applications Android applications such as my most recent release for Blizzards new game Hearthstone found here. However this app would require much more advance skills then I have done in a java android environment. For this project I needed to figure out how to accomplish what I stated in the title Rest calls, caching, and threading! So after doing the leg work I present to you how to effectively thread your app, make a rest call, and cache that call for later use.
The first step in this process is making and using a thread. Threading in java and android is actually quite trivial but very important, if you don't use threads on asynchronous task such as making REST calls to a database then your app will lock up while it waits for an answer to your request. This way the user call still interact with the phone, use the UI or cancel the request, all without having to wait or thinking the app has gone unresponsive and force closing. Threads are their own virtual class, so all you need to do is create a new thread and implement the run method as show below.
new Thread(){
public void run()
{
//I'll make a rest call from here so I lock up my UI!
}
}.start();
The .start(); at the end of the new Thread creation is telling android to start doing what is in the run method once you reach this line of code. Alternatively if you don't want to run the thread from within a method or would like to set it up, call it later or call it multiple times you could do the following.
Thread restThread = new Thread()
{
public void run()
{
//I'll make a rest call from here so I lock up my UI!
}
}
void main()
{
restThread.start(); // this will start the thread whenever whereever as many times as you want
}
Once our thread is started we can safely make our REST call without locking down the program. Making a rest call from java is also just a matter of a few steps. We need to create an inputstream for our program to get return data from once the connection is made. We then try to open up a HttpURLConnection and set our request method in this case this is a GET method, and any other header information we may need. We check the response code to make sure the connection worked. Then we make a character array large enough to hold all the data we get back from our server and start to read the data from the input string into our char array. Just like that we made a set up a connection, requested data, and took data into our program.
IMPORTANT: You must have the follow permission in your manifest file in order to have access to the internet and make these calls. <uses-permission android:name="android.permission.INTERNET" />
InputStream input = null;
try{
URL url = new URL(www.databaseWeWannaCall.com);
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection();
if(!(httpConnection instanceof HttpURLConnection))
{
throw new IOException ("this url is not a http url");
}
httpConnection.connect();
int responseCode == httpConnection.getResponseCode();
if(responseCode == HttpURLConnection.HTTP_OK)
{
input = httpConnection.getInputStream();
}
}
catch(MalformedURLException e)
{
e.printStackTrace();
}
catch (IOException e) {
e.printStackTrace();
}
try
{
InputStreamReader inputReader = new InputStreamRead(input);
int charRead;
String ResponseText = "";
char[] inputBuffer = new char[Size of data pulling down] //if you dont know the size just make it a very //large number it isn't efficient but it will get the job done for now.
while((charRead = inputReader.read(inputBuffer))>0)
{
String readString = String.copyValueOf(inputBuffer,0,charRead);
ResponseText += readString;
inputBuffer = new char [Size of data pulling down];
}
input.close();
}
Just like that we now have a string called ResponseText filled with all the data we queried from the server. Now that we have this data we still have a slight problem because the data is in our new thread we created, our next challenge is getting the data out of the thread and back to the main activity. We do this by using a message system. To do this we first set up our message handler, this is where when we send the message the data will be accessed inside our main activity.
private Handler myHandler = new Handler() {
public void handleMessage(Message msg) {
super.handleMessage(msg);
//do stuff with our data
}
};
Making a new Handler() requires us to implement the method void handelMessage(Message) this method is called when a Message is broadcasted to the program. But how do we send a message, as well as data with it?
Message msg = Message.obtain();
Bundle responseBundle = new Bundle();
responseBundle.putString("Response", ResponseText);
msg.setData(responseBundle);
myHandler.sendMessage(msg);
First we create our message object using the .obtain method. We then need to change our data from a string to a format that a message can send. Java has a Bundle class which will do just that for us. a bundle is basically just as it's called a bundle of information, it holds data along with a key to be accessed later much like a dictionary. We take the bundle put our string into it and send the message to myHandler.
Taking the data back out of the bundle is trivial just add this one line of code into the myHandler. This takes the data from the message in the bundle with the key "Response which we set up earlier when packaging the message.
msg.getData().getString("Response"));
We that we have a full rest call system set up with threading we can worry about caching the responses we get. Caching is a very important to do especially on the android environment we don't want to make our user make extra calls to the database especially when not on wifi. There is a built in caching solution in the URL class which is very hands off, it supposedly takes care of everything for you and gives you very little access. Because of this i chose to run with my own implementation of caching which is actually quite simple. All you need to do is write the data to a file and before you make a call to the database check to see if you have data in that file and when's the last time you made that call and saved the data. If the data is constantly changing you want to make sure that they data will be refreshed periodically so that your first cache doesn't stay around forever.
I check the time by using javas built in Calendar class.
Calendar myCalnder = Calendar.getInstance();
gets a object that holds year month day hour minute seconds in a clean way. I just update the calendar each time I'm about to make a call and compare it to the caches calendar. If more than the time i've wanted the cache to last has passed I make my REST call otherwise I use the cache file.
Another good thing to do is add a way for the player to clear our the cache and force a updated REST call. One thing I did in my implementation and would also recommend in a mobile environment would be to make sure, if you have cache and it's supposed to be updated, if the user is not connected to wifi don't update the cache wait until they have wifi and then let it happen. This way the user is angry that your app is using up all of their data plan.
You can check to see if the user is connected to wifi by doing the following call
if ( NetworkConnected())
{
//make the rest call
}
else
{
InputStream input = openFileInput(My_Cache_File);
}
you also must have the following permissions in your manifest file
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
That's pretty much all you need to know in order to get your own REST calls threading and caching working within and android environment, it's a very powerful tool and will open up endless possibilities for your app development.
I wish you all luck, and until next time, thanks for reading.
-Ian Percoco
The first step in this process is making and using a thread. Threading in java and android is actually quite trivial but very important, if you don't use threads on asynchronous task such as making REST calls to a database then your app will lock up while it waits for an answer to your request. This way the user call still interact with the phone, use the UI or cancel the request, all without having to wait or thinking the app has gone unresponsive and force closing. Threads are their own virtual class, so all you need to do is create a new thread and implement the run method as show below.
new Thread(){
public void run()
{
//I'll make a rest call from here so I lock up my UI!
}
}.start();
The .start(); at the end of the new Thread creation is telling android to start doing what is in the run method once you reach this line of code. Alternatively if you don't want to run the thread from within a method or would like to set it up, call it later or call it multiple times you could do the following.
Thread restThread = new Thread()
{
public void run()
{
//I'll make a rest call from here so I lock up my UI!
}
}
void main()
{
restThread.start(); // this will start the thread whenever whereever as many times as you want
}
Once our thread is started we can safely make our REST call without locking down the program. Making a rest call from java is also just a matter of a few steps. We need to create an inputstream for our program to get return data from once the connection is made. We then try to open up a HttpURLConnection and set our request method in this case this is a GET method, and any other header information we may need. We check the response code to make sure the connection worked. Then we make a character array large enough to hold all the data we get back from our server and start to read the data from the input string into our char array. Just like that we made a set up a connection, requested data, and took data into our program.
IMPORTANT: You must have the follow permission in your manifest file in order to have access to the internet and make these calls. <uses-permission android:name="android.permission.INTERNET" />
InputStream input = null;
try{
URL url = new URL(www.databaseWeWannaCall.com);
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection();
if(!(httpConnection instanceof HttpURLConnection))
{
throw new IOException ("this url is not a http url");
}
httpConnection.connect();
int responseCode == httpConnection.getResponseCode();
if(responseCode == HttpURLConnection.HTTP_OK)
{
input = httpConnection.getInputStream();
}
}
catch(MalformedURLException e)
{
e.printStackTrace();
}
catch (IOException e) {
e.printStackTrace();
}
try
{
InputStreamReader inputReader = new InputStreamRead(input);
int charRead;
String ResponseText = "";
char[] inputBuffer = new char[Size of data pulling down] //if you dont know the size just make it a very //large number it isn't efficient but it will get the job done for now.
while((charRead = inputReader.read(inputBuffer))>0)
{
String readString = String.copyValueOf(inputBuffer,0,charRead);
ResponseText += readString;
inputBuffer = new char [Size of data pulling down];
}
input.close();
}
Just like that we now have a string called ResponseText filled with all the data we queried from the server. Now that we have this data we still have a slight problem because the data is in our new thread we created, our next challenge is getting the data out of the thread and back to the main activity. We do this by using a message system. To do this we first set up our message handler, this is where when we send the message the data will be accessed inside our main activity.
private Handler myHandler = new Handler() {
public void handleMessage(Message msg) {
super.handleMessage(msg);
//do stuff with our data
}
};
Making a new Handler() requires us to implement the method void handelMessage(Message) this method is called when a Message is broadcasted to the program. But how do we send a message, as well as data with it?
Message msg = Message.obtain();
Bundle responseBundle = new Bundle();
responseBundle.putString("Response", ResponseText);
msg.setData(responseBundle);
myHandler.sendMessage(msg);
First we create our message object using the .obtain method. We then need to change our data from a string to a format that a message can send. Java has a Bundle class which will do just that for us. a bundle is basically just as it's called a bundle of information, it holds data along with a key to be accessed later much like a dictionary. We take the bundle put our string into it and send the message to myHandler.
Taking the data back out of the bundle is trivial just add this one line of code into the myHandler. This takes the data from the message in the bundle with the key "Response which we set up earlier when packaging the message.
msg.getData().getString("Response"));
We that we have a full rest call system set up with threading we can worry about caching the responses we get. Caching is a very important to do especially on the android environment we don't want to make our user make extra calls to the database especially when not on wifi. There is a built in caching solution in the URL class which is very hands off, it supposedly takes care of everything for you and gives you very little access. Because of this i chose to run with my own implementation of caching which is actually quite simple. All you need to do is write the data to a file and before you make a call to the database check to see if you have data in that file and when's the last time you made that call and saved the data. If the data is constantly changing you want to make sure that they data will be refreshed periodically so that your first cache doesn't stay around forever.
I check the time by using javas built in Calendar class.
Calendar myCalnder = Calendar.getInstance();
gets a object that holds year month day hour minute seconds in a clean way. I just update the calendar each time I'm about to make a call and compare it to the caches calendar. If more than the time i've wanted the cache to last has passed I make my REST call otherwise I use the cache file.
Another good thing to do is add a way for the player to clear our the cache and force a updated REST call. One thing I did in my implementation and would also recommend in a mobile environment would be to make sure, if you have cache and it's supposed to be updated, if the user is not connected to wifi don't update the cache wait until they have wifi and then let it happen. This way the user is angry that your app is using up all of their data plan.
You can check to see if the user is connected to wifi by doing the following call
if ( NetworkConnected())
{
//make the rest call
}
else
{
InputStream input = openFileInput(My_Cache_File);
}
you also must have the following permissions in your manifest file
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
That's pretty much all you need to know in order to get your own REST calls threading and caching working within and android environment, it's a very powerful tool and will open up endless possibilities for your app development.
I wish you all luck, and until next time, thanks for reading.
-Ian Percoco
Friday, February 14, 2014
Capstone: Midterms in sight.
This past week was quite a busy one for our Senior Production team. We were a little worried about our current progress and we really need to get down due some work and get it tested. We had a large work meeting last Sunday where we started creating four levels and the mechanics they each would introduce. We ended the day with four white boxed levels and four iterations of mechanics.
The mechanics that we got working were the shatter mechanic in which when the player collides with this objects with the correct shield out they will shatter the object and continuing moving. If they don't use the right shield it will slow them down. We're taking this to testing to hopes to find out if the speed reduction is too much and if we actually want the player to use any shield color or match the correct color.
Falling platforms were the next basic mechanic that we finished right now we are trying to find out if it is too punishing because they start to fall very fast, and if how they just kinda disappeared is acceptable or if they want them to still be intractable when they fall.
Boost mechanic was also worked on which gives a reason for players to grab collectables. With the collectables they will be able to use quickly boost to max speed to in which ever direction they are currently moving. We want to know if players would rather have to send you in the direction of your shield or not.
Finally we took our second stab at the slipstream. Slipstream has brought us many problems in the past whether it be due to frame rate, ability for the player to stay in the slip, ability for the player to come out of the slip cleanly. I do believe we have fixed all three problems but we need players using them without knowing what used to happen to see if they can break it or if it works good enough.
In other interesting news via our twitter @TMTgames we were contacted by Infinite Respawn a game blogging site that has their own podcast, has ask to interview us about our development process our plans and what the game is going turn into. Which was quite exciting for us and we will most likely pursue. Time is moving quickly and we have to pick up the pace to match it. With green mountain gaming and mid terms right around the corner we have a lot of iterations to do.
It's going to be an interesting ride,
The mechanics that we got working were the shatter mechanic in which when the player collides with this objects with the correct shield out they will shatter the object and continuing moving. If they don't use the right shield it will slow them down. We're taking this to testing to hopes to find out if the speed reduction is too much and if we actually want the player to use any shield color or match the correct color.
Falling platforms were the next basic mechanic that we finished right now we are trying to find out if it is too punishing because they start to fall very fast, and if how they just kinda disappeared is acceptable or if they want them to still be intractable when they fall.
Boost mechanic was also worked on which gives a reason for players to grab collectables. With the collectables they will be able to use quickly boost to max speed to in which ever direction they are currently moving. We want to know if players would rather have to send you in the direction of your shield or not.
Finally we took our second stab at the slipstream. Slipstream has brought us many problems in the past whether it be due to frame rate, ability for the player to stay in the slip, ability for the player to come out of the slip cleanly. I do believe we have fixed all three problems but we need players using them without knowing what used to happen to see if they can break it or if it works good enough.
In other interesting news via our twitter @TMTgames we were contacted by Infinite Respawn a game blogging site that has their own podcast, has ask to interview us about our development process our plans and what the game is going turn into. Which was quite exciting for us and we will most likely pursue. Time is moving quickly and we have to pick up the pace to match it. With green mountain gaming and mid terms right around the corner we have a lot of iterations to do.
It's going to be an interesting ride,
Friday, February 7, 2014
Capstone: Always More
This week as not as productive on my end as I hoped, and this morning I felt the consequences of my actions. The past 7 days have been filled with physics, operating system, ASP.net , Android programming, as well as trying to meet a deadline at my job. Something had to take a hit and sadly this week it was capstone. I only got to put in a few hours, most of which I will be making up for Sunday at our weekly work till you drop meeting. However few it was, it was rather productive.
One of the major requests from my designers is to make what they are calling the slipstream. The slipstream is a series of nodes that once places will generate particles between them. The player when making contact with this particles with the correct color shield will be dragging allow in the direction of the facing shield. This will allow our players to take a break from the action while still traveling at high speed. It's also perfect for making controlled direction choices.
The funny thing about this feature is while I stated above that it was planned to make you move in the direction of the facing shield, that only happened due to accidental functionality emergence in the way I created the feature. The slipstream works by when the player collides with one of the particles with their shield out and on they hook onto it and the player changes his position to the particle he is colliding with. However due to how close together the particles are the player does not ride along with a particle but keeps jumping to the next one. This means that depending on the way the player faced their shield they could control the way in which they went. This let itself to some really interesting gameplay due to the fact that we can now set up choice gates where the player can decided to get off early, follow, another path, or go back the way they came all from within the slipstream. It makes it a decision based rest section rather than a free ride.
The currently implementation still has some bugs and smoothing to be fully functional and ready to be given to the designers but it is definitely a step in the right direction and quite an interesting discovery that only adds to the possibilities of slip streams which I could quickly see becoming a testers favorite in the upcoming weeks. Slip streams should hopefully be hitting the QA labs this Tuesday so if you wanna try them yourself come on down , testing starts at 6:30.
That's all for this week,
-Ian
One of the major requests from my designers is to make what they are calling the slipstream. The slipstream is a series of nodes that once places will generate particles between them. The player when making contact with this particles with the correct color shield will be dragging allow in the direction of the facing shield. This will allow our players to take a break from the action while still traveling at high speed. It's also perfect for making controlled direction choices.
The funny thing about this feature is while I stated above that it was planned to make you move in the direction of the facing shield, that only happened due to accidental functionality emergence in the way I created the feature. The slipstream works by when the player collides with one of the particles with their shield out and on they hook onto it and the player changes his position to the particle he is colliding with. However due to how close together the particles are the player does not ride along with a particle but keeps jumping to the next one. This means that depending on the way the player faced their shield they could control the way in which they went. This let itself to some really interesting gameplay due to the fact that we can now set up choice gates where the player can decided to get off early, follow, another path, or go back the way they came all from within the slipstream. It makes it a decision based rest section rather than a free ride.
The currently implementation still has some bugs and smoothing to be fully functional and ready to be given to the designers but it is definitely a step in the right direction and quite an interesting discovery that only adds to the possibilities of slip streams which I could quickly see becoming a testers favorite in the upcoming weeks. Slip streams should hopefully be hitting the QA labs this Tuesday so if you wanna try them yourself come on down , testing starts at 6:30.
That's all for this week,
-Ian
Tuesday, February 4, 2014
Game Physics: To Scale Solar System in Open-Gl
Space, the final frontier, these are the voyages of programmer Ian Percoco. In this blog I will cover the adventures, methods, successes, and failure while creating a life sized scale version of our Solar System. This was not an easy task and put a lot of my programming and math knowledge to the challenge.
When I stated life sized, I really meant life sized, the first part of this process was to find a unit of measurement that my solar system to live in. I needed to figure out what to use for distance, mass, and radius. Seems simple right? Just use like the metric standard or something, I mean we get to do all of our massive calculations on a computer, it should be no problem! Wrong! Using a type of unit that is too small or too large literally makes the significant digits used in the math, too many for floats or even doubles to hold. So after a lot of calculations and making a small spread sheet I came to the conclusion I would use Megameters (1000000 meters) and Yottagrams (1.0x10^24 grams) This way the computer can actually preform the calculations needed to make our solar system move.
When I stated life sized, I really meant life sized, the first part of this process was to find a unit of measurement that my solar system to live in. I needed to figure out what to use for distance, mass, and radius. Seems simple right? Just use like the metric standard or something, I mean we get to do all of our massive calculations on a computer, it should be no problem! Wrong! Using a type of unit that is too small or too large literally makes the significant digits used in the math, too many for floats or even doubles to hold. So after a lot of calculations and making a small spread sheet I came to the conclusion I would use Megameters (1000000 meters) and Yottagrams (1.0x10^24 grams) This way the computer can actually preform the calculations needed to make our solar system move.
After deciding on units the challenge of making the planets actually move begins. I set up what is known as a force registry system. The force registry system takes the job of applying forces out of the hands of my planets and into the Registry. Basically I make a force registry system that holds a list of forces. The planets get linked up to the forces and then added to the registry. When update physics is called the registry loops through and applies force upon the planets based on in this main case the gravitational pull of one planet onto another and the amount of time that has passed since the last call. The planet takes this updated force and applies it to its velocity and then updates the position, clears out the force and waits for the next force update. This way the planets don't have to keep track of one another or calculate distance or even the total gravitational force (gravitationalConstant * mM/distance^2)
And just like that I had movement, I kept adding planets setting up forces and they just started to move around as expected. The hardest part was getting earths moon to keep up with earth but all that really needed to happen was have the moon be affected by both the earth and the sun as well as changing the moons initial velocity to match that of the earths + it's own. It doesn't make the most stable orbit for long but it does work.
Now that I could see individually this planets moving, there was no way I would be able to get objects so far apart and at such varying sizes to appear on the screen. So I needed to implement a distance scaling basically saying if a planet such as Neptune is too far away to be drawn, bump up the scale a little bit to allow us to actually see it. This way we can actually see the orbits as shown above.
From there the project was a lot of camera fixing, adding debug text, free form camera rotation and such all on this massive scale which surprisingly was one of the hardest parts (excluding finding the right units). My debug text still doesn't work right due to the changing angle of the camera but It suits me just fine right now as a proof of concept.
From there the project was a lot of camera fixing, adding debug text, free form camera rotation and such all on this massive scale which surprisingly was one of the hardest parts (excluding finding the right units). My debug text still doesn't work right due to the changing angle of the camera but It suits me just fine right now as a proof of concept.
Subscribe to:
Posts (Atom)