Making Sense of the Spaghetti


It is daunting diving into a three year old project with a language I haven’t touched since. Generally, I work in Lua or C. I know both of those languages well enough to get into some serious trouble. JavaScript, not so much.

Being a three year old code base, I’ve learned a thing or two since I started, so certain things really stick out as being weird. I’ve grown, my code has not.

Ooze Factory is littered with copy/pasted code and odd sections that break with convention as I try to shoehorn a foreign concept into my existing code base. While I will defend this practice as being the right choice at the time, it is definitely giving me some anxiety now.

In that first month of development, it’s easy enough to keep the context of a project in mind. When so much is constantly in flux, I’d rather focus on implementing all the new ideas that are coming in faster than I can program them. In my opinion, it’s the worst time to take a step back and try to make sense of it all.

Making sense of it all is what I would have used the second month of development for. The process I’m currently going through right now.

But first!

I really want to get the initial prototype released and trying to make sense of it all is something that will really slow down the release.

Instead, I’m making more spaghetti. Copy and pasting, duplicating code all over the place; DRY purists will lose it upon reading this, but when making a prototype, chaos reigns. Until the prototype is published for the world to play, it’s anarchy in here.

Because I don’t quite have as strong of a grasp on TypeScript as I once did I will be relying on copying/pasting even more. I’m not exactly sure what I’m doing when I’m making changes right now but it’s working and is getting me closer to release.

What Needs to Be Done?

My focus is on getting the prototype off of my computer and released onto it’s itch.io page. I may take some time to tweak some levels and variables, but as far as I’m concerned, the game is ready to be played, warts and all. There’s just a few things that need to be done before that can happen.

Packing & Loading Assets

I’m currently finishing up with fixing how assets are loaded. During development, I chose the robust way of making sure the asset is loaded every time it’s needed so I always had the most up-to-date version. In production, this is the worst idea ever. Instead, I’m working on combining all the assets into one cozy little file that loads all data at game initialization. If I later find out this file is too large, I’ll split it into chunks and load it dynamically.

Presentation

During development, I use a dedicated Chrome instance which represents the ideal window size. In production, environments and window sizes will vary. While the game resizes fine (I spent a great deal of time making sure it would) I wrote that code before I was finished with all the on screen elements. So in some cases, the text at the top of the play area may be hidden or obscured.

Improved Mobile Support

There is basic mobile support already, it just isn’t great. Mobile has always been an after thought for Ooze Factory so it isn’t pretty either. Of course, the only reason I was interested in HTML5 game development was for accessibility, so to ignore mobile users goes against that very principle. Ultimately it’s still a low priority so while it may be playable on mobile, it may not be refined for the prototype.

Box Art & Promo Copy

Before I can even hope to release the game, I need box art, banners, icons, a tagline, short description, etc. Each item listed deserves its own blog so I won’t go into detail here. Once nice thing about all of this is it draws on a different skill set than programming so it’s something I can do to break up the monotony or when I just don’t feel like looking at a code editor.

Getting Ready to Release

I need to prepare all of the code and assets into a neat little package that can be easily consumed by the end-user. This includes removing unnecessary code and processing the remainder to generate an as small as possible result. Ultimately, I’d want as few files as possible, for example: index.html, game.js, and levels.json. There are no images (or few if any) so I’m not worried about them. However, if had enough, I would package them into a sprite sheet or texture atlas.

Leave a comment

Log in with itch.io to leave a comment.