Internship Pillo Games 2016

[ Pillo games ] Week 2 – Madness

Week 2 already?!

This week I’m slightly behind schedule, ideally I wanted to have the  workflow of the Pillo development kit (PDK) finished but I still have some question which I have to ask the developer of the PDK and he didn’t have time this week so I’ll have to finish this up next week. Meanwhile I already started brainstorming and doing research on how to write a well thought out survey. I will propose a first version tomorrow (22-2-2016).

So what else has been going on? I’ve been writing my Project Initiation Document (PID), which the first version of is now finished and send to the supervisor. I hope it’s good enough so that I can focus on the project itself form now on. the PID has taken most of my time this first week alongside the analysis of the Pillo Application Programming Interface (API) and the workflow of working with the Pillo PDK.

Lastly I discovered that I kind of made a error in the Internship period specified in the contract.. I used a calculator to calculate the days and I came to 86 days. The minimum is 85 so that means I am only allowed to have 1 day off at the most otherwise I wouldn’t meet the quotum. I thought I calculated it before and took 1 extra week but I guess I miscalculated before. I can always stay a week longer I guess if it seems I won’t meet the quotum :).

Towards Week 3!

Project Y

[ Project Y ] Bullet hell bullets system version 0.4

First things first, I decided to keep it a 2D game but started all over from scratch and building it up again. At the moment I have a working bullet system which I mostly have been polishing the last week. The result is that I can have around 2000 bullets on my screen before my frames per second (fps) drops to below 50-60. This is a huge improvement of the first version which only could hold about 400. Here is the version 0.3 which is only slight less efficient:

What I basically started out with was a simple system:
– a spawn script with bullet pattern coroutines in it which places an x amount of bullets over an y amount of time in a z degrees of rotation.
– a bullet script with constant forward movement attached to the bullet prefabs
– a simple object pool that pools the bullets that are not needed and where I can request new bullets.

This then evolved into a system where the bullet behavior are all regulated by 1 manager that does 1 update for all the bullets on the screen. Because having 1000 bullets on the screen all with their own update results in a extra 1000 updates which is not very efficient. After removing the script from the bullet prefab I immediately saw a performance boost, which was expected.

The last thing I did was giving the 2d prefabs their rigidbody back. Yes putting them back, I  initially removed the rigid bodies because I thought that would make it more efficient. But this is not true it seems. Thanks to Luuk pointing it out, it seems when you move an object with a collider and without a rigidbody, the complete static collision data needs to be recalculated, which is slow. So: what you should do, is to make sure that all objects you intend to move have attached rigidbodies,  if you don’t want the objects to be moved by the physics engine as me, then just set isKinematic on true. For best results, just use Rigidbody.MovePosition(). Which I did and BAM bullets on screen ++!