Bloop Boop Critical Reflection

After working on Bloop Boop for the last 11 weeks, I have learnt a lot about myself as a team member and as a programmer. It’s good to say that I have defiantly improved my programming standards, using more advance techniques and methods to create my solutions and branching out into new and interesting forms of programming like shaders, which I have found an interest in. However did have some issues with learning and understanding other concepts and sometimes lacking the motivation to try and learn and understand them so they can be used in the future.

Firstly, as a team player I felt I preformed well overall throughout the course of development. I work diligently on my tasks, for the most part, to try and get them done on time and to a suitable standard, using Google drive and slack to check off and update people on changes I have made. I was, for the most part, available in slack while I was working for others to contact me and ask questions. Issues did arrive however when people needed to contact me on updates and work progress and I wasn’t on at the time or day which caused some uncertainty and gaps in our schedule for when tasks were complete.

I was a part of every meeting that was setup for this project and gave my opinion when needed along with suggesting changes and cuts to the game when it seemed needed. Example being the more fleshed out animations, due to the process of setting these animations up, individually changes each frame to a material and cycling those through or storing many lists of frames and trying to swap them out when needed would have taken up far to much time for a system that would have been very buggy and messy with many fixes needed after its initially made to be usable. Therefore I suggested cutting them and focusing on polishing other aspects before the gallery.

Some improvements would be,

• Quicker response times, have notifications setup to tell me when I have questions would drastically help improve my response times and would have solved some previous issues of team members not knowing what I was working on or when I was finished.
• Doco updating, there was a few times that I didn’t quite understand what something was or how it was meant to work and therefore had to guess and implement it that way, which is no efficient and something that I need to improve on.

In terms of being a programmer, I felt I was much more efficient in this project then I was with others. I stopped relying heavily on basic, beginner tactic’s and started thinking more in depth on creating systems and methods that can be used more openly or are just built better then previous attempts and iterations of that system. I’ve heavily removed away from if statements and focused more on Switch statements to control the flow of the code and what its affecting, using jump tables to skip repetitive and sequential checks that If statements do.

I worked on more advance systems like a splatter system, which took into consideration shaders that I had made to create the effect of paint splatter of objects. This involved me researching and learning more on shader lab, Unity’s in built shader language, and CG, which is Nvidia’s graphics shader language, and how they work. I also learn’t a lot on stencil shaders and the power that they have to create some great illusion effects.

I also worked creating the illusion of screen wrap using multiple balls and the camera varrible of .isVisible to check what was visible to the camera and what wasn’t. However there was some issues that came up. Due to me working a lot on the front end of the project, I didn’t have much time or experience working more in the back end with the game’s or Unity’s networking setup. This caused issues where I was unable to work properly for a while to compiler errors of Unity’s IAP systems not being active or imported in my particular project I had no idea how to solve it.

Others were Json and creating the level loader as I had not done many readers and parser before and had to rely on others for help developing, maintaining and updating it. However I learnt some new concepts like dictionaries. Overall a lot of the issues I had last time have been improved on, I have had less issues lately coming up with new and efficient solutions and plan on continuing to get better in the future.

Improvements that I will be making:

• Improving my CG knowledge, this is to allow me to create better and more intricate shaders for my future projects.
• Continue to learn new concepts in Unity C# programming

 

Hardware Limitations of a 3DS

As programmers, you need to be aware of the limitations of any particular platform you wish to work on. This involves understanding the hardware that is being used and how far you can push them to get the best performance possible. Other factors that need to be considered are FPS, resolution, active elements, file and application size, along with a lot more. In this blog I will be going over the limitations of developing a game on the 3DS and how its hardware and other features could affect that game’s development and performance.

Firstly I will only be covering the New 3DS, not the Original, XL or 2DS. Even though they have similar setups, there are other factors you need to consider like increased resolution, lack of 3D capability and different hardware. So lets cover some hardware,

• Processor – 804 MHz ARM11 MPCore quad-core
• GPU – 266 MHz DMP PICA200
• RAM – 256 MB
• Resolutions – Top Screen: 800×240, Bottom Screen 320x 240

So what do these mean for game development, well the 3DS isn’t all that powerful of a machine. It’s processor is a quad core so it present a decent opportunity for multi-threading but overall is fairly weak when it comes to performance. Its GPU is a PICA200 which is a Japaneses specific GPU design that’s embedded into the system and was designed for high-performance arcade systems. Has 256 mb of memory which is tiny in comparison to today’s standards. So overall not to great, however this system is not meant for high end AAA gaming but instead portable arcade games and apps.

In terms of its core limitations, its lack of RAM is a major concern as you need to be careful with what and how much data your game will cashe into the system for quicker processing. This would suggest reducing as much data information into the bits possible for cashing, data like player and enemy position are simple enough as they are an X,Y,Z coordinate (3 bits), player stats can be saved as string of numbers that can be called a processed quickly. Optimisation methods like these would need to be thought off to counter the lack of RAM in this system.

Another major limitation is its resolution but this can also be a good thing. Since the resolution is quite small it will take less processing time to render sprites, animations and other data. This means more time and effort can go into making more detailed assets and system as they would run smoother and have less of a performance hit. However caution is needed as the processor, as mentioned before, is quite weak with the smaller resolutions being a way of countering it. Have many active elements on screen at once in comparison to higher detailed assets would cause much higher processing to be needed and therefore lower the entire performance of the machine.

Its duel screens is another factor that needs to be taken into consideration, When designing a game for the 3DS you will probably think of interesting game play features that the second touch screen could be used for, however touch screens dont tend to be the fastest, processing wise, and performance needs to be considered if the feature works better on the main screen and just using a button. The 3D functionality of the system can also take a massive amount of power and processing to maintain and determining how that affects your overall performance is needed.

Another limitation is the file and application size of your game, you cannot have a massive 3oo hour long RPG on the 3DS without a better SD card used. As the base system on has four gigs of storage memory, its quite low and that can easily be taken up by a couple or semi-large arcade games and apps. Optimizing and compressing files would be suggesting for the 3Ds to lower the entire file size as small as possible for easier installation and usage.

That goes over a number of limitations that the 3Ds has.

Thanks for Reading 🙂

 

 

Security and Data Risks to Bloop Boop

Like most games, Bloop Boop is careful when it comes to its security and privacy to make sure the game runs correctly and safely and that all player data, including analytics, IAP information and Google Play details remain safe and secure to avoid breaching peoples privacy. However that wont stop people from trying to get around these systems in order to, break the game, steal personal information, modify the APK or do something else they aren’t meant to.

Some risks that can happen are,

1. People no paying for coins – This would involve then loading the game on PC and trying to backwards engineer the game to get the source code. Then modifying how many coins they have thought code before rebuilding the game and putting it back on their phone. Methods around this would be to check how many coins hey had, before and after they load the game and seeing if there is a difference, if there is then delete the difference. Another would be check how many purchases they made and calculate how many coins they should have. However since this quite a low tier game I doubt this would happen.
2. People trying to steal other peoples IAP details – There is always a risk of people trying to steal other peoples credit card when it comes to IAP. Since the purchase isn’t necessarily through us but instead Google Play Store and we just check things off a list it passes, the risk of this happening is quite low as they would have to go though google as we don’t save any of those details, it would be a major privacy breach if we did.
3. Privacy statements not correct – There are many details you need to be careful on when you write your own privacy statement as it outlines what data you will be receiving from the user and using in your game. This can cause issues with people if you try to take excessive amounts of data and access from people, Pokemon GO’s first privacy statement shows this well with them gaining full access to your google account and have full reins to do what they want with it if you play their game. Actions like these can cause legal action against you and we will be certain to avoid this with only taking data we need like names and friends.
4. EULA issues – An End User License Agreement is document that is agreed between both parties of the software. Just like the privacy statement you need to be careful with what you write to make sure you aren’t doing anything stupid with it. Stating that you gain access to profiles and all contents inside would breach privacy laws stating that you own the software and all its aspects will stop others from taking and copyrighting your game.

One account of an existing data leak would be the famous example of Value’s Half-Life 2 game leak in October of 2003. This was when A German man named Gambe sent a email to one of the employees of Value with a link inside that contained a virus. The employee click on that link and Gembe suddenly had access the the entire Half-Life 2 game source code. He then proceed to post the entire game onto the internet, causing extreme damages to the company as a whole.

Gembe then started to brag about his accomplishments to Value directly and instead of threats in return, Gabe Newell decided to offer Gembe a job as a security manager for Valve as he did such a good job of breaking into their system. Gembe accepted and went to get on the next plane to America before being stopped by German forces as there was American FBI waiting for him for when he landed as he was going to be trailed and prosecuted for breaking into their system and causing so much damage. Gembe then spent a lot of time in jail in Germany for that crime.