Dev-Diary: 6


The past two weeks have been pretty hectic with both work-life and personal life, so I’m afraid this won’t be too long.

That being said, aside from a few more patches and rooms being completed, the audio optimisation I was discussing last post has been completed! Instead of now updating over-overwhelmingly, the engine will now update individual sounds in a cycle to prevent running too many alterations. Additionally, the update also accounts for when too many sounds are running and decreases the frequency of updating to accommodate the updates, although this is also an option that can be toggled for people noticing the audio causing lag issues.

I look forward to completing more rooms and updates to get this demo and the revised engine fully functioning! Till next time!

Dev-Diary: 5

Sorry I’m a day late!

I’ve been spending a lot of the past 2 weeks just working on the maps, trying to get more done. I’ve been working on the trigger-related rooms, demonstrating how trigger functions work. This also opened up a few situations where I’ve found bugs so I’ve been patching them as well.

The main thing I’ve been working is optimisation! I work on a semi-powerful computer so it doesn’t serve as a good standard-benchmark for how the game engine runs on other machines. I’ve tested the engine before on other devices, but that was when it was bare-bones. The demo has a lot more content; full visuals, more dynamic sound, and more complex triggers. I’ve been running the demo on my laptop I use for note-taking, which, not exactly being a powerful device, I’m using as my benchmark as a standard device. Without any optimisation, there was obvious lag in many rooms! There are a couple of factors for this, but currently the two main reasons are visual rendering and sound complexity.

Visual rendering is actually very easy to fix; while building the rooms I had all the visuals set to constantly render as vectors, which looks nicer but eats away at processing! A more common render process, which I’ve used on my earlier games, is to render only once when the level loads. This process only applies to static visuals though, but it does help out a lot and removed all the lag issues in many of the rooms. Animated visuals have to remain as vectors, though can be exported as much simpler graphics should the need arise.

Sound complexity is a fair bit more difficult, though I believe I’ve managed to get it mostly fixed. There is a sound function in the engine which renders a sound as a positional object, constantly updating it’s position so that it sounds as if it is originating from a specific location. Originally, this updated every single frame, which is a lot, but worked without problem in a bare-bones scenario. However, multiple positional sounds all running in a fully drawn and animated map causes some problems. This has been addressed by making sure the sounds only update every few frames; not enough to be noticeable to the player but enough to ease up on the processing. I’m still working to try and have it regulate between multiple sounds to spread out the processing, but it’s getting there. The aim is to also have this as a quality setting, letting the player chose between more accurate sound rendering or better processing.

Other areas which I thought would cause lag issues are luckily running smoothly! A room that spawns a mass of projectiles, with the intention of causing lag, actually runs a lot smoother than anticipated! I have a lot more to go, and bugs are popping up still, but I’m trying to make sure I can not only have a fun game but a working game. Till next time!

Dev-Diary: 4

Hello! Mid-Month update time for September!

So the past 2 weeks have been mostly consumed with getting levels done for the demo. Collision maps, triggers, dialogue, visuals, and code patches; all the things a growing game needs to get big! While, being a demo, visuals aren’t supposed to be as important as the mechanics getting tested, I find myself free-drawing a lot of the more interesting areas instead of using the assets I made. The demo has been quite the little learning project for getting back into drawing, but also getting faster at using the trigger systems I made in the engine; even though I designed them, I hadn’t really had a chance to make so so so many triggers, and this demo is providing a perfect opportunity to get faster at it! Though it’s going to again step up it’s game when it comes to the NPC Programs, the AI can get rather complex when you want them to obey certain patterns.

And as always, I’ve been passively working hard at the lore and stories. Drawing up the characters, writing out some language, and planning the history, to give the world a bit of depth. A lot of these things though won’t be immediately apparent in the first few projects, and are more something for the long-term goal.

Of course, all this talk of level design and visuals, I’m sure you want something to look at. Well here is one of the completed rooms where the player can experience the various sound functions in the game. Till next time!

Monochrome Engine - Demo - 02

Dev-Diary: 3

Hello! 1st of September, so time for another update!

The past 2 weeks have mostly been consumed with working on levels for the demo. I’ve done most of the visuals for the demo levels I have built, and begun writing the triggers and dialogue for them. This, along side a few code updates to engine, has been the bulk of the progress made to the demo. Part of me definitely wants to go straight into working on my first game, but I guess I’m a bit of a perfectionist, and I want to make sure the engine is working just right before I jump into anything, so I’m looking forward to hearing what all you testers have to say about it!

In additional news to my work, I’ve been in conversation with my music composer again since the first project will be dawning on me soon; I’m excited to get some amazing tracks for the game as I feel this composer is a fantastic fit! I’ve also been drawing up some sketches and writing out some lore for the future projects coming up, and while I won’t spoil anything too early-days-drafty here just yet, some of this stuff may be included in the demo, so if you want to jump onto the list to see what I’ll be working on in the future, let me know!

Thanks for keeping up to date on this site! Remember I update here on the 1st and 15th of every month, so remember to check back!

Dev-Diary: 2

This is the first Dev-Diary that is being posted on this site that is not being published in parallel with my other progress-posts (Newgrounds and DeviantArt). What this means is on this website, I’ll be posting twice a month (1st and 15th), while only once a month on the other sites.

On-to the progress made!
I spent a lot of these past two weeks juggling a lot of different aspects of the demo; I’ve set-up the skeleton for the free-running level (the most complicated area where people can experiment with the majority of the player physics) and worked on the visuals for the other levels. However, I’ve spent a lot of this time working on the visual assets and fixing bugs.

Because this is a demo, the visual side of this mini-project is odd: I want to show-off what is possible, what I am capable of, and test varying degrees of visual data being processed during a test. However, this is just a demo, and while I will be using this to hopefully get some people interested in backing my games, I don’t want to put all my efforts into making this pretty, as that time can be spent finialising code and preparing for the first major project. So visual assets are essentially my folders of little re-usable walls, floors, ceilings, and objects that I can throw into the level to make it visually appealing without the time wasted on drawing it all. Of course, this is how all the other games will be made, to a degree, but the demo will feature predominantly recycled assets.

With the bugs, I am happy to say I have FINALLY fixed angled collision. While each level only seems to feature one or two angled floors, they are a crucial player mechanic as they serve as either an obstacle, or a boost (depending on the player’s approach). So having the player clip through ramps if they hit them at a certain speed, or fly off the end if the ramp was at the wrong angle, became a major issue. But it is a major relief to say I believe they have been completely and complexly patched. This comes along side many other bug-fixes such as sliding through walls, grinding through walls, and generally moving through things that should not be moved through.

Well that’s it for this mid-month post! I’m going back to work, so everyone have a wonderful rest of the month!

Dev-Diary: 1

Welcome to the first Dev-Diary on my own site!
From now on, I will be posting here twice a month (1st and 15th), but still continuing the same posts on both Newgrounds and DeviantArt for the time being. During this time, the website will continue to be updated and tailored to assist me delivering news on my production progress!

To bring this website up to speed, for about the past 2 years, I’ve been on/off working on a Flash-based micro-game engine called the Monochrome Engine; a 2D side-scrolling non-linear RPG engine with focus on player movement. What started out as a learning task (making a game engine is a good way to learn how they work!) soon became a full-time project. Now, the engine is in a working state and I am preparing a demo for both testers and potential sponsors, in an early bid to get everything ready for the string of projects I have lined up!

Continuing on from where I left off with my last dev-diary, (available on Newgrounds and DeviantArt) the engine has revealed a nice selection of bugs that have occurred in the physics functions outside the developer environment. While most of these have been fixed, there are still a few problems that are being addressed. However, I have still been working on the levels for the demo, as well as preparing a handful of visual assets to be used through the demo. I would like to have this demo done in a month’s time, but that comes down to how the bug-fixes work out, as the physics functions are some of the earliest code and re-writing them has been proving quite the task, but not one greater than I can accomplish!

Below you will find a little screen-dump of some snaps from the demo, where you can compare a nearly-finished room to a hardly finished one. Check back on the 15th for the next update on this website! And don’t forget, if you would like to be a tester for the demo of this engine, send me a message either on this website, or to my Newgrounds or DeviantArt accounts.

Monochrome Engine - Demo - 01