DevLog: Concept Iteration, Input system & Player Movement



This past week has been the first week back to continue development of our final project. Last trimester we stumbled about getting a prototype together - a chance to, well, prototype (duh) our concept, features and general design of our major project. And now, this trimester is our last to work on it, really bring the project together and polish it as best as possible. We’re now in the full swing of things and the steaks are high. Here’s a look at what our rough plan is for the next 12 weeks:


In this devlog and in the following 13 (hopefully), I aim to give an outline my perspective of development on this project and generally share what I’ve been doing. Sometimes, but not always, I will discuss unrelated to this project type of stuff (For Example, Internship Hunting, Side Projects and Level Design).

Concept Iteration

As displayed in the picture above, we played our final prototype before proceeding any further on the development of this project. After doing so we all pondered on it and discussed what we want to potentially change about the project.

Being as though we had all last trimester to change the project and iterate (and by golly, we sure did), we now have little time going forward to make changes to the project. So what ever we change, we have to be dame sure is the right choice, because we do not have enough time to pivot.

So, what did we change?

  • Camera

    • We decided to limit the control the player had with the camera - seeing as though we’re doing a mix of 2D & 3D for the environment, we want to be mindful of that.

      • This allows us to have generally more control and not allow for weird bugs that occurred during development of the prototype.

  • Story

    • We decided to basically entirely rework the story so its short and sweet - as much meaning as possible with as-little work to get that across.

  • Features & General Concept

    • In the prototype we set out to have a skill shot with an arch, but we mid-trimester scraped that and simplified that and when for a straight line and yank to the player to then ‘Thwack‘ the object to a target.

    • This time around we scrapped all that and we plan on making it a lot more simple with less systems and more meaning. Essentially we just cut scope and made it so we can easily achieve what we plan early and leave plenty of time for polish.

Last trimester there was a lot on my plate being the only programmer, and so we had to have designers take on some of the programming responsibility. This lead to some understandable duct-tape in the code base, of which lead to a bunch of bugs that often made it through to playtest.

This time around, giving that the scope is smaller, we have less features to implemented, so all the programming is my responsibility. This also gives me more time to make tools.

Input system

Last trimester in the prototype we used Unitys input system and towards the end we implemented XInputDotNet and only used it for the rumble. As a result of using unitys, we had messy input checks all through out the code base. Learning from my mistakes I started taking input more seriously this time around.

I implemented XInput from the get-go and used it to it full capability.

With this input system I used XInput and made an event system, so that when any input is pressed, released, etc. It sends out an event for anything listening.

The goal of this system is to easily switch inputs for certain interactions without issue. Maybe even have an adjustable controls option menu if there’s time.

Player Movement

With the player movement, I used the previously mentions event based input system, fed through the X and Y input on the joystick through an event and for listeners to use.

After doing some simple movement scripting, I thought the feature was done and dusted, although I should have checked collisions because later my designer teammate notice collisions were ignored (even though everything was set up okay). It turns out (of course) that I’m telling it to move every input frame before unitys physics system update and does any calculation - causing it to power through a wall without caring about collisions. I changed the movement slightly so it relies more on the physics system and it worked beautifully.


To conclude, I got up to a bunch this weak and above i detailed some of them. Although, next week’s a good one and I’m not even half way though it. We discover a mechanic that could really add value to our game and I start smashing out the prototypes for it and create tools, we also make a huge decision that could be incredibly beneficial to us moving forward, or doom us. So keep an eye out for that.