DevLog: Missed a week, Hitting feature lock early, Trying not to be a C# only programmer



This week I’ve done a bunch on my capstone project and last week I did some, but it was relatively insignificant (a lot of back end stuff). This blog I'm going to brush over what I didn’t blog about last week, then move on to reflect on what I learnt this week!

Some of the following writing about my current capstone project may be confusing without reading my previous 2 blogs!

Missed a week

Surprise surprise, I forgot to do a devlog last week. Well, I didn’t forget, I was fully aware. But yeah, what’d I do last week?

Last week I fixed/cleaned up the tuning mechanic and player movement tool. I added in some functionality to improve adjustability for the designers (giving them more to adjust with the tool).

Also, I reworked some code in tools, In an example the player movement, I improved it so the speed increases over time to more you move. So there’s some acceleration to the players' velocity so that moving long distances was far less tedious.

Hitting feature lock early

So we hit feature lock early, and by that I mean we implemented our features a week early and with any further work we can use the tools I’ve created to improve our product, or we can easily improve the tools already there.

We hit feature lock early because I worked hard to get in some tools quick and early. I made these tools so they’re adaptable (it was quite nice when our “producers” suggested ideas, asked how hard that would be to implement and my designers response was always ‘I think we can do that with the system we already have in place‘ - they look at me and I’m like “yep! we sure can!!” ).

This is also because our feature list, to begin with, was quite small, which is quite worrisome, but I think we’re doing a lot of unique things with our features, so I think we’re good.

Now with that aside, what did I do this week?

New Game State System That's Actually an AI state system

I thought, and so did the team, we likely shouldn’t have the state being all handled in the game manager and poorly at that. The current system in place would get the job done but it was becoming more and more un-maintainable and generally messy.

So with that, my solution was to make a more spread-out system that’s far more maintainable.

In the past I haven’t had much experience in making a game state system but… I do have experience in AI states, so my solution was an AI finite state machine tweaked to suit the whole game and not AI behaviours.

We have yet to fully implement this system into action, being as though we can't afford the time or risk that comes with switching systems currently. That said, I am confident that this system would work given the time.

Tuning Mechanic Meets Environmental Interaction

As it stands we have environment the reacts if the player enters its space. And so to tie the tuning mechanic and these environment interactions together. I simply made these environmental features activate (how it does when in proximity to the player) with the direction the right thumb-stick on the game controller when ‘lockpicking’ the music.

This was super easy to hook up and added a large amount of value to the product we’re creating. This kind of implementation (quick and simple implementation - maximum value) is exactly what we need to continue focusing on.

Trying not to be a C# only programmer

What I’ve been doing instead of writing devlog is expanding my knowledge of programming outside of C# and unity.

I looked at my GitHub and saw that a lot of them were C# projects and assessment work at that, which I think if I were an employer, I would sigh at the sight of that. I knew what I was doing by focusing on C#, I was perfecting my speciality, and that’s great but it’s done now - it’s time to move on! It’s not that I only know C#, it’s just that I don’t have anything worthwhile to showcase that isn’t just C#. So from here on, I’m going to dedicate the little free time I have on side projects that aren't just C# (focusing on AI of-course), and learn A LOT in the process - which is all I can ask for really.


Simple Clock

I made two projects with Javascript. The first was more of a warm-up project and its what I’ve gathered a lot of people start within javascript. And this is to make my own take on a clock. Some make their clock more visually appealing, come make it quite technical, I made mine kind of a joke… classic.

After some research into this, I decided to implement this using the P5.js library. Through some reading of their documentation and some quick testing implementation, I quickly got a grasp of the library and JavaScript itself!

First, with my clock, I got the basics working, making arms rotate based on the built-in time functions available. The ones I only care about here are of course are, Seconds, Minutes and Hours. A little bit of math and some trial and error. I got the clock fully functioning. Next is the visual clock itself and a little button to make an assumption of what Ethan (me) is doing right now.

This was all done relatively straight forward, I had some fun making a silly clock visual and moved it in.


For the button that spits out an assumption of what I’m likely doing was simply done with probability.

5% chance of sleeping, 40% chance of drinking coffee and a whopping 55% chance of programming!

Neural Network - Genetic Algorithm Flappy Bird

Now with the warm-up practice out of the way, It time to get into what I really wanted to do! That being: Put all the countless theory research I’ve undergone for Neural Networks, Genetic Algorithm and just in-general Machine learning - finally into practice.

This project in-short was a blast! I was worried that my love for doing late-night deep dives into deep learning (see what I did there?) wasn’t going to be the same as implementation. Boyyy was I wrong; I couldn’t have been further from the truth.

Watching my little agents bounce their hearts away, learning and learning until they solved the game, couldn’t have given me more joy.



This week with Python I fixed up a little project I did a while ago and published it on GitHub. This program simply looks at the file it’s currently in, looks for any zipped files extract them and finally deleted the old zip files.

As I said in my readme on GitHub for this project, ‘The program was inspired when going on a download spree on and having to extract all them was a pain. So I quickly though together up this program to do it all for me.‘, I was sick and tired of my cluttered mess of a downloads folder, came to the realisation that I am a programmer and I shouldn’t have to do these mindless tasks.

In conclusion of this wild ride of making projects that aren't just c# was a fun and rewarding experience and I’m definitely going to continue this adventure.

Level Design

This past week I’ve been rushing to get a Level Design Document (LDD) done and out of the way so I can use it to make my sweet-sweet level in Tesseract!

StudentNote-v0.1.0: Level Design’s harder than you think. (duh)

Making a good design choice is hard, but adequately justifying that decision is even harder. ‘But maybe I just felt like putting that light there!‘ - You’re wrong! You always have a reason for your design choice and if you truly don’t have a reason, you’re doing it wrong… Any old idiot can slap a level together without any thought. And I can almost guarantee you it won't be a good level by any means. Just after learning the basics in level design (ie, level flow, rational level design, use of aesthetics, etc) - I started seeing it everywhere in games worth their salt. Level design is so fundamental to any good game development and I don’t think it’s given enough credit.