24/04/2017 – Working On A New Project

As I decided to write this, the date changed from the 23rd to the 24th. I am currently starting to write this just past midnight, whether or not I finish writing this tonight is yet to be seen (Somewhat likely, I don’t write much for these).

I can’t remember if I mentioned in my last post that I started a new project. If I did, then my apologies; if not, well guess what? I started a new project.

It’s a game, this time a 3D one that focuses more on traditional control methods (PC/Console friendly), and as such has opened the door to a slew of bullshit wondrous new avenues in Unity’s development tools. Well, sort of. The difference between the 2D and 3D tools from a programming perspective is negligible at best. But, I do feel the development toolset lends itself better to this perspective.

So what is the game? I can’t talk too specifically yet, but it’s a bullet-hell game. Which considering it’s a genre I am terrible at, is pretty surprising that I’m actually doing somewhat well in constructing it.

Now, I’m not quite ready to show any gameplay yet, but I assure you it’s coming along well now. I’m gonna talk about how the progress has been so far, and I am deeply sorry that I cannot go into specific detail about certain scene, scripts, or game objects. It’ll make more sense once I start showing the game I assure you.

When I first started it, I ended up over-thinking a lot of the base principals that would construct the game. Everything was very singular and separated, but still required to communicate with each other. This way of development continued for several weeks, and became harder and harder to work with, and made progress incredibly slow. I didn’t get player movement working on that system until maybe late February or early March.

Sometime after doing the player movement stuff, I got sick and had to take a couple weeks off (I may or may not have also been playing the crap out of Nier Automata by this point, but lets ignore that detail). And after I came back to work on the game, I realised something; Everything I was doing was very convoluted and difficult to manage, especially considering how Unity manages hierarchy of objects in the game scene.

Once I realised this, I broke down all of my previous code and bundled up a lot of the objects that I was generating separately into two slightly different objects (And then made another two based on those), and then generated the game scene based on those. This amendment caused a significant increase in my efficiency and made the other tasks for myself considerably easier.

For example, the player movement code that had taken me several days to make and work properly, now worked within a matter of hours and was much easier to obtain the components I needed from certain game objects.

One of the other issues I had was a little more specific to Unity. I found a need to destroy game objects in a scene, but said objects were being collected in a list. However, Unity’s GameObject.Destroy() function only operates at the end of the frame and not immediately. Which meant that the list I was storing these objects in said there were more of them than there were, which actually broke the player movement system.

Unfortunately, the WaitForEndOfFrame() function didn’t work as I had intended, so I had to resort to rebuilding said lists in the Update() method which is expensive. It’s kind of been nagging me, so I’ll likely end up fixing it at some point in the future. Additionally, the bug can still occur if the player is positioned in a specific way, but that’s also something I’ll fix.

That’s about as specific as I can currently get. Hopefully by the time I write my next blog post I’ll have some images and video to post. Although my next post will likely be a Den post.

That’s kinda all for now.

-Adam

P.S. Persona 5 is hella rad.
P.P.S. Nier Automata is also hella rad.