Studio_3[week_twelve]; Raytracer Progression — December 12, 2016

Studio_3[week_twelve]; Raytracer Progression

raytracer-progression

Raytracer Progression-  http://textcraft.net

As one of the learning objectives this trimester, we were tasked with optimising a raytracer given to us, to the best of our ability. All the leading numbers for each picture description, are shown in milliseconds taken to complete the raytrace 100%. As an example, the first time shown, the base time, would be just over 59 seconds.

59096 – This is the base time with no changes to the raytracer program.59098-base

31136 – This is the time for the base raytracer program, except I turned shadows off. I decided that I wanted to make beating this number my goal, without using OpenMP.
31136-everything-base-except-no-shadows

53647 – Reflect twice not thrice. This is the first thing I tried, by default the raytracer allows for 3 reflection bounces, I set it to two and it made a 6-ish second difference with only minimal changes to reflections of reflections of objects.
53647-reflect-twice

39337 – Skipped checking for light 0. There are two lights in the scene, a red one and a white one, I disabled the check for the white one and it made a massive difference! You can kind of se on the right side of the bed of spheres that there is more red light, but I believe it looks better anyway, hence why I kept it.
39337-skip-light-0

37880 – Slightly changed LUA file. The “power” value for the bottom bed of spheres was 5, I set it to 1, you can see a shadowing difference for sure, but I asked Carlos what image he thought was the base image between this one and the base one, and he thought for sure this was the base image and I agree with him that it looks better 😉 It is only a matter of 2 seconds though, but I am keeping it.
37880-sligh-lua-change

33839 – More slight changes to the LUA file, disabled the reflective attribute of the bed of spheres, it didn’t seem to make any difference in looks, but it made a 4-ish second difference in completion time!
33839-more-lua-editing

30587 – I added a more efficient sqrt algorithm, it only saved me around 3 seconds total, but I had finally passed the time I wanted to beat, the time of the base version of the raytracer except disabling shadows.
30587-after-sqrt-change

22281 – I was now happy that I had passed the time I set myself to pass, now I could activate OpenMP and really see how good I could make it.
22281-openmp-activated

16321 – I had previously set main_disp.set_normatization to 1 to test if normalisation would better the time, it totally didn’t, setting it back to 0 shedded around 6 seconds off of the time.
16321-changed-normalisation-back-to-0

9926 – Edited the LUA file another tad, this time only spawning balls that will be visible on screen, saved a hell of a lot of time, another 6.5-ish seconds. I must admit the average time is between 10.5 and 11 seconds for this one. (You can see the reflection of the bed of balls in the spiral of spheres, but it shows no change to how many balls are visible on the actual bed of balls.)
9926-changed-lua-a-bit-more-make-less-bed-balls

Between 9835 and 9390 – Final changes – I didn’t like how obvious the change to the “power” attribute was in the LUA file, so I changed it back from 1 to 4. I ran the raytracer from a cold computer, 6 times, once every minute, and through all 6 times, the number never went over 9835ms! I am soooo glad I can get consistently under 10 seconds!between-9835-and-9390-run-6-times-once-every-minute-from-cold-computer-and-re-set-power-to-4-in-lua

Things I tried but failed:

  • Running the sky image through a program that cuts down the size of BMPs. CImg now couldn’t read the BMP.

 

  • Making the image a PNG, including the libpng library for CImg to be able to read it. The libpng library couldn’t find the reference to one of it’s files even though I pointed it directly to tat file’s location.

 

  • Removing the specular and diffuse calculations, it made too much of a difference in looks but no difference in speed.

 

  • Setting main_disp.set_normatization to 1. Thought maybe normalisation may speed things up, I don’t know why, its just an extra step, changing it back to 0 shaved 6 seconds off again.

 

  • Putting the improved sqrt method into the kf library for it to use on vector math, it was coming up with a const-related error and I couldn’t be bothered trying to solve it for the few milliseconds I predicted it would shave off.

 

  • Tried an Assembly solution for the sqrt algorithm, C++ understood all the syntax given, no errors there, but it would still complain and wouldn’t build.

 

  • Right after changing the reflection amount from 3 to 2, I wanted to see what setting it to only reflect once would look like, it took 20 seconds shorter (which amazed me), but it looked too much different from the original to keep.
    34607-reflect-once

 

  • Tried setting main_disp.set_normalisation to 2, and I got some really cool looking results as you can see below, but it added 4 seconds to the time (did this after the 16321 version and got 20016 setting normalisation to 2).
    20016-playing-around

In the end I think it was a pretty big success, cutting down the time it takes the raytracer to complete by 50 seconds! Sure the 9 second time was only once, but it still happened, I swear, I have proof! 😀 Anyway, here is a final comparison between the base raytracer image and the completed raytracer image:


This is Daniel Jochem, signing out.

Advertisements
Studio_3[week_twelve]; Reflection of Programming Skill — December 11, 2016

Studio_3[week_twelve]; Reflection of Programming Skill

reflection-of-programmin-3

Reflection of Programming Skill-  http://textcraft.net

In the first 1/3 of this trimester, we had Anthony as our programming facilitator. Anthony focussed on getting to know us as programmers by giving us small tasks to work on that would show him how much we remember from Scripting 1 and what sort of tricks we have learnt throughout the trimesters. This was very self-revealing when it came to my abilities as a programmer, I had forgotten a lot, but I had also remembered more than I thought I would have, as I am not known for having the greatest of memory recalling.

One major thing I forgot I remembered was Object Pooling. What a great optimisation method that is, and I had totally forgotten that I was taught about the wonders of it 4 trimesters ago. I have used Object Pooling on three different occasions this trimester and believe I will be using them a lot more in the future, way better than instantiating and destroying gameObjects (such as bullets) over and over again, potentially many times a second!

This trimester I actually tried to plan out scripts that I would make, instead of sitting down and just coding until it was bugless. I found writing out what needed to happen and making a UML diagram only slightly helped, I didn’t see any improvement in the development time of the scripts I planned out, it actually slightly made it harder as I could not test out code as I went along, seeing what worked together and what could be improved upon through the testing.

I tried writing out one of the scripts exactly as I planned out in it’s UML diagram, and it was broken as hell. It didn’t make me feel good about my programming ability, because I knew I was better than that without any planning. I either need to get better at planning out my scripts, or I need to incorporate testing time into the planning of the scripts, but then I may as well just continue writing scripts as I wouldn’t need any pre-planning if I am testing things to see if they work together.

I was able to effectively solve problems with other people’s code when they needed help, both within my groups and with other programmers. As I have stated many times in the past, I love helping people out, and if I am helping other people find solutions to problems in code, I am in my perfect happy zone, if it is solved, nirvana!

I have been saying for a while now that I enjoy making tools, and most of the tools that I have made so far are for game designers to use, and you are not left disappointed this trimester either, I made a a level builder tool for Splop. That was a hell of  lot of fun to make, especially because the Splop designers kept asking for more features so I iterated the tool throughout the whole trimester.

I wonder if the Splop designers did that deliberately, just to slightly break up my work load throughout the trimester, if they did consciously plan out and give me these tasks each couple of weeks, then I congratulate them fully, I think I would have gone insane if I were just focussing on the two games purely. Gareth was on Team Splop and I know that he knows I enjoy tinkering with tools development, so I suspect he did it on purpose to some extent.


This is Daniel Jochem, signing out.

Studio_3[week_twelve]; Reflection of Team Work —

Studio_3[week_twelve]; Reflection of Team Work

reflection-of-team-work

Reflection of Team Work –  http://textcraft.net

Having to work on two apps at once was for sure a challenge. In the first week of the project, I needed to develop full Alpha builds of two games, now THAT was a challenge! I would say that it was more like 2.5 games I made, as for Splop, I also created a level builder tool to create levels, save them out to CSV and load the CSVs into the game to play. I did an average of 16 hours a day for 4 days straight on these games and the level builder, it was one of the most intense weekends I have ever had.

Positives of teamwork in projects

For Splop, I totally had the wrong idea what role you played in the game, initially I thought that you were a separate entity jumping over jellies. Thinking this would have totally changed the game mechanic, and a lot of code would have had to be changed if it wasn’t for myself showing Gareth my progress after I finished the level builder for Splop, before I started on the development of the game. Gareth quickly picked up on my explanation and display of a player entity being placed in the level builder to be saved out in the created level.

Team members were generally productive and especially in the second half of the project development, they would ask me if I needed any help or less of a workload as they knew how busy I was having to handle two projects. All four of my designers were super understanding and lenient towards my milestone deadline progressions. I would always get stuff done by the deadlines, it would just be slightly less than expected, probably 80-90% of what I would promise would be done.

I thank all four of my designers personally for how great they acted towards me during the progression of their app developments, they were forceful, but a good kind of forceful, not too much, just to the extent they knew I could do stuff to, if they were more forceful towards what needed to be done by deadlines, I don’t think I could have coped with the workload, it would have just been too insane making two Alphas to their full potential in one 4-day period if I was limited to that.

Negatives of teamwork in projects

Very hard to contact group members on-the-fly. I think it is a problem with both Slack and Discord apps on phones, as people found it hard to contact me as well at times, I don’t get notified of any messages coming in from both of those apps, unless i am explicitly tagged in a comment, even then that only notifies me 80% of the time.

Mostly near the start, GDDs did not have all the information I needed and this ties into the previous point where it was hard to contact members, forcing me to decide for myself what was needed to fill in the missing information, luckily I set it up where values could be changed easily because I got a couple of things totally wrong and only needed to change a formula and some values that were also made available to the Designers.

Since my time was split between two apps, I did not get to put my full potential into both apps, like I stated earlier, I had completed 80-90% of what I wanted to do to both apps, but that last 10-20% really counts as well.


This is Daniel Jochem, signing out.

Studio_3[week_twelve]; Weekly Roundup —

Studio_3[week_twelve]; Weekly Roundup

weekly-roundup-1

Weekly Roundup –  http://textcraft.net

The Designers had been busy all this week preparing their apps for an update to be pushed on the Friday. Great improvements had been made to both of my games, fixing many bugs and visual aspects in Space Race and fixing theming, visualisations and instructions in Splop. Adrian gave everyone permissions to push app updates, I had a feeling I would be the one pushing the updates and my intuition was correct.

I needed to quickly change 1 small thing for each of my apps before I released the update. Space Race’s UI layering was a bit off and the sun would move on top of the UI as it progressed forward. Splop’s level menu scrollbar would show only two levels visible at the beginning of the scrollbar on some devices, so I moved it left 100 units so that 1/4-1/2 of the third level would be displayed signifying the player can scroll to other levels.

This week was exhibition week! Week 12, Wednesday, 5pm-8pm. That is what the usual details are for an exhibition night, except only three of us from the whole of Studio 3 turned up and presented our games. Everyone else ‘didn’t know’ that the exhibition was this week until Tuesday apparently, the day before the exhibition. Anyway, it was Carlos, Eli and I who showcased the games. Carlos and Eli are on the Steel Seal (formerly Seal Surfer) team.

I showcased both of my games I had worked on this trimester. It was a whole load of fun, it went by so fast! My feet ached as I had to stand by my games for the whole 3 hours (I was very jealous of Carlos and Eli, who could swap out every half an hour or so to take a break), but I kept myself active and entertained and tried dismissing the pain, it worked to some extent! Quite a few people from the industry came to the event and played our games, we received a lot of good feedback that will be very useful in the future. I passed the feedback onto all 4 of my designers, since none of my designers were there on the night, and in the update pushed on Friday, a lot of the feedback was integrated into the games which is a really good thing to see that my designers also took on the feedback given.

I have been asked by my ITS teacher from school, this week, if I could make a course for his Moodle site teaching technology students all around the world how to develop a game in Unity. I have started planning out how I will present the course already, and have got some good ideas brewing in my mind for what sort of content I will cover. I am thinking maybe 3 hours of content a week, so that 5 days each week, students can spend 30-40 minutes on a module, and make 1 full small game each week, progressively getting harder each week.

It is LO Weekend. Expect 3 more blogs today (hopefully I can do it!). I have figured out I need to do 9 writing-related things this weekend, two days have already been and I have written 3 of them. 4 blogs total today, then tomorrow I am left with two writings which, to be honest, I could probably only get one done, but i’ll try for both. It is going to be a big rush to get everything done by the end of the week, but Greg marked off 12 LOs related to the apps on Thursday, and we also started and completed the implementation of a network LO, so that put it up to a total of 13 out of 24 LOs complete! I have done at least another 5 LOs worth of stuff, possibly up to 7, which would put me up to 18-20/24, so very close.

I would love to go into more detail about the exhibition, but I am way too busy, and need to do another three blogs today, plus this blog is starting to go way over the rough limit I set myself of 500 words per blog this trimester, so it will have to wait for another time, I gave you the general gist anyway.

Alright, on to the next blog, wish me luck for the rest of this weekend!


This is Daniel Jochem, signing out.

Studio_3[week_eleven]; Weekly Roundup — December 4, 2016

Studio_3[week_eleven]; Weekly Roundup

weekly-roundup

Weekly Roundup –  http://textcraft.net

This week was the week, the apps are now published! It has been a very long journey, making two apps. I remember the first week us Programmers were told that we were to make alpha versions of these apps in 4 days, sure, making one game in 4 days is fine, but I was set with the mammoth task of making two Designer group’s alpha apps in the 4-day period. I was actually able to do that, with one app alpha complete to around 95% and the other to about 80%. What made it even more amazing was that I had managed to make a level builder tool for the first game as well, in this 4-day period. I must admit, I was quite proud of myself. Zoom through the weeks and quite a few new feature requests and bug fixes later, and I had contributed to two (un-polished) full games which are now available to wider public! Here, go play my games, give me some feedback at daniel.jochem@gmail.com!:

Splop!https://goo.gl/ScGiL1

Space Racehttps://goo.gl/JP3y6n

Only two weeks of the trimester to go! It is very scary the amount of work I still need to do, extra scary because I currently have 0/24 LOs completed, and that I still need to do more to my Final Project game which is currently a higher priority, as the progress report is due on Tuesday so I have to have stuff completed for that.

Looks like I won’t be finishing all LOs by the end of Week 12, like I promised myself I would try to do, it has just been way too busy with the apps I needed to make for the Designer groups.

Although my LO sheet shows that I have been satisfactory for 0/24 LOs, I have done the equivalent of between 14 and 18 LOs, they just need to be checked and marked off. Luckily most of those LOs to be marked off are for the apps that have just been published this week, so once Greg plays the apps, he can hopefully check most, if not all of those app-related LOs off.

I am going to be working on Final Project for the rest of today, but tomorrow is dedicated to working on more LOs. I can hopefully get a load of the “Make a game or system that uses threads or scheduling to achieve concurrency” LO done tomorrow, as I can work on the placeholder raytracer to get it as efficient and optimised as possible. I will do as much as I can  in one day, as when we finally take our Kinect 3D-ish photo of us Programmers, hopefully this week, I can quickly copy over the code I made/changed on the placeholder raytracer to the new raytracer with our photo, add some more small optimisations to it, and be done for that LO.

It is now the final push towards the end of the trimester, I am definitely on the right track to complete everything that needs to be completed, but a little bit behind schedule, so I will be working a couple more hours a day on all I need to do, and I have hope that I will complete all that is required by the end of Week 13!


This is Daniel Jochem, signing out.

Studio_3[week_ten]; Weekly Roundup — November 28, 2016

Studio_3[week_ten]; Weekly Roundup

weekly-roundup

Weekly Roundup –  http://textcraft.net

In both Tuesday and Thursday’s classes, we got stuck in and helped out our Designers with their games. Near the end of Tuesday’s class, we were all asked to write on the board, under the name of our games, what still needed to be done and were instructed to categorise the tasks as either:

  • A – Designer’s could do it so they should do it
  • B – Either the Designer or Programmer could do it, depending on who got to it first
  • C and even possibly D – Programmers should do it.

I did all that I was instructed to do by my two teams on Wednesday, which turned out to be only one thing for Splop!, finding out, and implementing a way to hack-proof, as best as possible, the watching-an-ad-only-every-6-hours feature. This was challenging to plan for and make, but I had so much fun doing it. The basics of what happens is when you enter the Sugar Store menu, a request gets sent to a time server to get the current UTC time, I then convert it to the UNIX time number, compare it to a dated version of a UNIX time number saved out from the last time they watched an ad, and if the time difference is greater than, or equal to 6 hours, then make the Watch Ad button interactive again, then when the ad is finished, the new time is saved and the button is set as not interactive, and next time the Sugar Store menu is opened, the same loop occurs.

On Thursday, in class, SpaceRace had come up with a few things they wanted me to do to their game, that they hadn’t thought of before we left class on Tuesday. These changes to the game were as follows:

  • Alter how the ship selection works – Instead of scrolling to a ship and then having to click on the ship to select it, I was instructed to make it so that the ship that was scrolled to automatically becomes the selected ship. 
  • Ability curve – This one was badly named by the Designer’s as they meant ‘Agility’, but what I was instructed to do was to make it so that the different Agility values of each ship would actually change the speed that the ship would move at.
  • Change the way you paint your ship – Each wanted colour is a whole new sprite with different shades of the wanted colour, instead of how it was where the colour of the whole sprite was changed to a close-to-solid wanted colour. It looks a hell of a lot better, I must admit, but it also means we now have 18 ship sprites, not 6.

Dramatically cut down the app size from 83MB to 42MB by getting Alex to better compress audio and delete all the unnecessary assets from the project. This brought us down from the 83MB to 57MB and he admitted defeat, so I came in and compressed all the sprites and images, which cut down the size of the app that additional 15MB. Solid effort all around. If you want to understand why I wanted the app to be under 50MB, refer to the last blog post I made about the limitations of the Android platform.

Release date is this Tuesday, it was delayed for a reason I can not remember at this moment. I am sure the Designer teams will have more things they want done before the games have been published for real, and us Programmers will find out tomorrow what they are. I have asked my teams if they had anything for me so I could preemptively do them, but both groups stated that they are at the stage where they can publish.

I tried to get all that was wanted from me done for Studio by the weekend, as I wanted to focus on doing Final Project stuff this weekend, although Friday was dedicated to helping finish up the apps, as the release date was supposed to be on Saturday, but as you know the release date is now tomorrow.

Actually thinking about it now, doesn’t it take a while for Google Play to check out the app to make sure it is safe before they publish it on the Play store? It may be sent to be published tomorrow, but may not actually be on the store until a few days from now.


This is Daniel Jochem, signing out.

Studio_3[week_nine]; How I am Handling the Limitations of the Android Platform — November 20, 2016

Studio_3[week_nine]; How I am Handling the Limitations of the Android Platform

the-android-platform

Weekly Roundup –  http://textcraft.net

The ultimate goal for any game, let it be for PC or Android or a gaming console, is the magic 60 Frames Per Second. If we are to achieve a solid 60 FPS, each frame needs to take 16 milliseconds to go through logic, calculate the AI, do collision detection, calculate physics, load the sound, and render the frame onto the screen. We can achieve this by taking into consideration how we handle objects in a scene, the visual and audible quality of assets, and implementing smart and mostly simple optimisations. A byproduct of such methods will be a smaller app size as well, which is also an effective optimisation method. A smaller app size will ensure that most of the population that would be interested in our apps, will be able to download our apps, even if they have very little space on their devices already.

The device in which I have been focussing on developing these games to support is a Samsung Galaxy Note 8″ tablet, since that is the only Android device I have access to, it resides at uni. The following table shows the device specifications for the Samsung Galaxy Note 8″ Tablet.

Screen Size 8 inches
Processor 4 Core 1.6 GHz Pentium Pro
RAM 2048 MB DDR3 SDRAM
Internal Storage 16GB

It is a great device to develop for, it isn’t too old, but it also doesn’t have the best specifications, although they are still reasonably comfortable specs to work with. The games I have been developing for this tablet are not heavily resource intensive or large games, even with how simple the games are, they still are reaching high app sizes for what they are. Without any optimisations, Splop! is 22MB and SpaceRace is a whopping 63MB.

Object pooling is a good way to optimise a game, instantiating and destroying objects over and over can be quite intensive at times. Object pooling also allows for control over the number of elements active in a scene at a time.

For an example of visual asset optimisation, after I had implemented some small-ish changes to how animations work, having less of them overall, SpaceRace is now 51MB. It will require more simple visual optimisations like scaling down the dimensions of the visual assets which will in turn cut down the file size of each of the scaled assets, shrinking the app’s total download size as a result. SpaceRace has quite a few different animations and other visual assets such as sprites, which are currently vector images and the default dimensions are way oversized, so I hope to get the app down to ~30MB at least by just modifying the sprites and animation sizes.

The total application size is another thing we should take into consideration, we should aim for no larger than 50MB for the total APK size, so that players can download the game over 3G, like when they are on a train or bus. This 50MB limit is both achievable and should be aimed for because devices running Android 2.2 and lower (API level 8 and lower) can only download APKs that are smaller than 50MB on the Google Play store. For Android 2.3 and higher (API level 9, 10 and 14+), you can download 100MB APKs max. One more thing to consider is that if the APK is going to be larger than 50MB, we will need to tick the “Split Application Binary” box in the “Publishing Settings” section of PlayerSettings in Unity, as this will turn the APK into expansion files. These expansion files are an attached pair of files that are no larger than 2GB each, that come along with the APK on the Google Play store, but we won’t need anywhere near this 4GB of extra space, so we won’t worry about that for both games, forcing us to be under 50MB again.

There is still more to learn and research about optimising and handling the limitations of a game for the Android platform, but I believe this is a good starting point to have and my games can only be more optimal from here!


This is Daniel Jochem, signing out.

Studio_3[week_nine]; Weekly Roundup —

Studio_3[week_nine]; Weekly Roundup

weekly-roundup

Weekly Roundup –  http://textcraft.net

This week was again spent on the Designer’s games. I think I have finally got to a point where I can start focussing on my Programming LOs instead of focussing on the Designer games. Both of my games don’t have any bugs that we are aware of, with only some minor-ish features still not implemented. For SpaceRace, we still need a Highscore system, the Missions system needs to be worked on a bit more. For Splop!, everything is in and working that needs to be as far as I know, just maybe need a highscore system, and there is still some beautiful juice we need to add to the game that uses the gyroscope and the accelerometer on Android devices. We still don’t have IAP, Ads or Social stuff integrated into the games yet, but hopefully Eli is onto that this weekend as he may have hinted he is going to dedicate time to figuring at least one out. We will see on Tuesday if he came up with anything.

I gave the Common folder fix to Eli to put on his project, but Unity Cloud Build still failed to build it for some unknown reason… I think Eli said he isn’t really using anything from it anymore anyway, and Ryan confirmed to me that he is just using his own scripts for things that were in the Common folder anyway, so he doesn’t need the fix.

We have a total of 4 weeks to go, and I had planned to get everything LO related done by the end of Week 12, but I still have 0/24 completed, with 3 weeks till my self-set deadline, which worries me a bit. Hopefully I can leave the Designer games alone until Tuesday of Week 11, so I can focus on LOs for the rest of this weekend and all through next week and next weekend. Hopefully. I WOULD be able to do that, for sure, if I also didn’t have stuff to do for Final Project, but hopefully I can sort something out with my Designer’s for FP, so I can get these LOs completed!

We are still yet to be taught some networking by Greg and we also haven’t taken our 3D photo of us Programmers to try to optimise the rendering of for another LO, so hopefully we get to work on networking this week so I can, next weekend, work on that as well as the optimisation LO. I am going well with keeping my blogs to the word count of around 500, which amazes me, but I am glad that I can do it, it gives me more time to work on other things for this Module. Expect another blog from me later today, I will be writing one about limitations of an Android device in relation to making games for the platform. That blog’s count may go over the 500 word mark, it probably should, but I can not be sure just yet.


This is Daniel Jochem, signing out.

Studio_3[week_eight]; Weekly Roundup — November 13, 2016

Studio_3[week_eight]; Weekly Roundup

weekly-roundup

Weekly Roundup –  http://textcraft.net

Well we are one week closer to the end of the trimester and no closer to crossing off any Programming LOs. Our Designers keep giving us more to do to the games, and I am afraid that we won’t have enough time to do all of our personal LOs. We still haven’t started on ads or IAPs or social integration for the games, but luckily the Betas for the games were due this week, so hopefully we are on the final stages of integrating new features the Designers have newly thought of, so hopefully our list of things to do only shrinks from now.

Initially when we were divied out our games to make Alphas for, Anthony said that I should be working on the two Alphas whilst the other two Programmers work on their one and also on the additional systems (hopefully modularised) we would need for our Alphas, the main three being Ads, Social Integration and In App Purchases. This in fact did not happen, the additional modularised systems were not created and I am quite annoyed that they aren’t done even to this very day, three weeks after the milestone has passed. I may have to also do these systems by myself :/ *is not impressed*.

I spent the majority of both Tuesday and Thursday’s lessons with my two groups, helping integrate what needed to be integrated before the end of the week so that the Beta versions could be downloaded onto Adrian’s phone before the weekend. When we did put both apps on Adrian’s phone, Splop!’s level selector wasn’t working how it was intended and if you clicked on a level, the level would appear not to load. The level selector issue was solved, but the loading of the levels is still a slight mystery as they load on the computer but not on Android devices. Greg mentioned something about being able to debug and show the profiler in Unity whilst the app is loaded and being played on an Android device, so we will need to find out how to do that and figure out what is going on.

I have also fixed the Common folder issue wherein the contents inside that folder were not getting built by Unity Cloud Build as they reside in a different repo. My solution was to, instead of using the Update Common menu item in Unity to handle all the logic, I would make that menu item call a batch file which would pull the repo to the Common folder, copy all that is inside to another folder which I called “Programmer’s Stuff” and then it would delete the Common folder. That way we can now push the Common scripts and not have any script namespace conflicts as using a batch file to do all three steps allows for the automatic wait-till-task-finished-before-doing-the-next-task feature of batch scripts so that only at the final step will Unity try to compile the scripts.

As for the rest of this weekend, I hope to work on the level builder for Splop! more both tonight and tomorrow, although Toby (from Team SpaceRace) wanted me to help him with the Missions system tomorrow, but so far he has not messaged back confirming any times or anything.


This is Daniel Jochem, signing out.

Studio_3[week_seven]; Weekly Roundup — November 11, 2016

Studio_3[week_seven]; Weekly Roundup

weekly-roundup

Weekly Roundup –  http://textcraft.net

Apologies for not posting this blog when I promised, I am not getting lazy, just very busy. So let’s travel back in time…

For Tuesday’s class, Greg and the three Programmers went to another room and Greg talked to us about our optimization LO. He showed us the program he made which we are going to speed up through optimization methods we put into it. We are going to optimize to the best of our ability, the rendering of a 3D picture of us Programmers, made from spheres which are placed based on points data taken from a Kinect photo. Ryan was not at university on Tuesday, so we couldn’t take the photo on Tuesday, but once we have the photo, we can start working on it.

It is that time of the Trimester again, it is Study Week! It is also Melbourne International Games Week, which means GCAP, PAX and Unite are on, which also means that a lot of lecturers and students are away this week. Study Week also means that this week we are doing our KPI / TSA meetings. The meeting went well, Greg had only known what we were doing for a max of two lessons, so he was coming into these meetings kind of blind, he didn’t have much feedback for this trimester, instead basing his feedback off of what he remembered of our progress last trimester and what we had written in both last trimester’s and this trimester’s TSA assessments. The rest of the lesson we worked with our Designer’s to get closer to the completion of our games to the stage where they can be released as Betas.

Next week, the Designers have their apps due for Beta, so I am guessing both Tuesday and Thursday will be focussed on finishing the app features up. I still have a couple of things I need to do to Splop! but it shouldn’t be too hard to complete in time. Hopefully none of my Designers ask me to do anything else to their games (apart from bug fixing), Alpha was supposed to be due around 3 weeks ago, but both groups keep asking me to do more!

Alright, back to the current timeline, I am definitely less busy this weekend, although I still have a lot to do, so I am 90% sure I will post this week’s blog on Sunday (two days from now). Thanks for not giving up on my lately-inconsistent blog postings, unfortunately they have been late due to a high volume of workload needing to be done in a short amount of time.


This is Daniel Jochem, signing out.