Welcome to Custard Games!

Hello, my name is Dominic Mortlock (locknic), and Custard Games is a small brand/site created to showcase the games that I’ve developed over the years. My girlfriend Dennise-Marie Leon is the resident marketing guru here, she handles our social media accounts and works hard on expanding our audience.

Sudokil, our current project, is a game about controlling robots with a unix command line interface. It’s turned into a pretty ambitious game, and I would highly reccomend that you check out it’s page!

Feel free to contact me with any questions you might have. Enjoy!

Dennise’s Corner #1: PlayCrafting Fall Expo 2016

Hey there all! Yesterday Custard Games attended the Fall Playcrafting Expo in San Francisco for the second year! We have been working really hard on Sudokil, our newest game that is still in the works. Dominic Mortlock our game developer has put in so much effort into making Sudokil an amazing and fun game.

The Playcraft Expo was a great experience to learn and play! We had a lot of people stop by and play Sudokil. We had the opportunity to meet a lot of new people that stopped by our table to play, talk, or even offer us advise on possible ways to better the game. To make things better we had a ton of pizza for dinner. One of the most awesome encounters was with an eleven year old boy who asked if he could play our game. He immediately dove in and after a few minutes yelled “I get it! This game is awesome!”. He kept stopping by later on in the night only to help adults if they struggled with the game.

All in all our experience with Playcrafting’s Fall Expo was a great one to say the least. We met many new people, had the honour of playing many new games, and showed off our passion along side many talented locals from SF.



Sudokil Devlog #4 – A problem with perspective

I was supposed to release a new build of Sudokil with the released art this week, but a problem with the art perspective has ended up halting development somewhat. Right now we are using an orthogonal 3/4 camera perspective. Trying to figure out a perspective that both looks good and is as functional as possible is hard. My art requirements are that it should look good, and CLEARLY show ALL entities and objects on map in order not to obstruct puzzle solving. Here is a screenshot of the game:

We’ve gone for the perspective where the upper wall just takes up 1 tile, while the lower wall starts a bit higher and overlaps the lower floor a little bit. The art works quite well in the case of having a square room. However an issue arises when trying to design some rooms with one thick walls, and having overlapping walls. This is my attempt at it.

While it looks alright, there are definitely some issues with the 1 thick walls because they don’t look like they are indeed 1 thick. Also, once we start putting walls into the actual level area as opposed to the outside, we place them slightly differently as to not obstruct entity movement and such, but this creates inconsistencies. Another issue is that we are trying to make doors that span over multiple tiles and having a lot of trouble with the current perspective. I’ve looked to some other games for solutions and found a few.

Halfway. Here the one thick pillars take up physical space in the tile above them.


  • Nothing blocked/obstructed
  • Looks like it is in perspective
  • Looks good in general


  • The minimum height for a wall/pillar is 2 tall instead of 1 (restricts level design)
  • When being physically obstructed by the upper half of the pillar, perspective looks off
  • Lack of any overlap does not help perspective when above wall

Steam Marines. Here, all walls stick to their own tile.


  • Nothing blocked/obstructed
  • Very clear which tile entities and walls are in
  • Level creation will be much less labour intensive


  • Tiles look strange in some places (such as vertical doors)
  • Height of walls might not match entities
  • Perspective less realistic

Nuclear Throne. Here all the wall tiles overlap the tile above them slightly.


  • Perspective works
  • Kind of what we are currently doing, but our walls are a different height


  • Entities sometimes obstructed and less clear
  • Obstruction may limit level design for objects that might be covered
  • Height of walls might not match entities

This is our previous placeholder art. It uses a more true top down perspective.


  • Nothing obstructed
  • Entity position very clear
  • Cheap art


  • Looks kinda shit

And finally here are some images of playing around with perspectives

While that middle island wall pillar thing looks great in terms of the perspective (where the perspective overlaps half the tile above it), it does present the problem of blocking entities. The robot works fine because it is tall, but once you start using small objects such as crates, it is hidden behind the wall.

Just some playing around with cheap and dirty “3d models” I made out of paper. Helped a little bit when trying to go for realism, but does not help much in the gameplay practicality as it isn’t always tied to realism.

If anybody has anything at all to contribute, feel free to share! Should I stick to the current style or try for another? Would love to hear ideas on the current options, proposing new options, or any games with perspectives that might be interesting to look at and consider. Thanks!

Sudokil Devlog #3.5 – A sneak peek

One month later and I am already late on my plans to do a monthly release. I’ve been hard at work co-ordinating with a very talented artist to create some assets for Sudokil. Current delays are caused by some of the levels not being fully updated to the new art. Instead of staying quiet, I thought I would release a teaser screenshot of what is to come, and put up an experimental nightly beta build for the upcoming alpha v0.3 release. I expect the proper release to be out next week.


Warning: These builds are broken, and not considered stable. Only download if you wish to have a peek at what’s to come. New art is in level 1 and playground-rafal. Press F12 to switch rendering style if you want to play an old level.



Sudokil Devlog #3 – It’s starting to come together!

Over the past month and a half, I’ve been working hard on getting some new features into the game and getting a new version of the demo out. One of the first things I worked on was adding a level loader so that you don’t have to start from the first level every time you close and open the game. Plus it is really helpful for testing since I can easily make playgrounds and add them to the game. In terms of gameplay features I added a new networking system, and started the works of a current system so that you can have things like pressure plates releasing a current that can open and close doors or fire bullets from a turret.


While the programmer art is still in, I’ve been working on getting the game looking a little bit better. The first thing I did was to update the UI a bit so that it is a more polished and consistent style. Next I added lighting into the game! It was a lot easier than expected since I just had to implement box 2d and use the library box2d lights. The only thing I had to add that was a little difficult was giving each entity a box2d body that the game updates as entities move.

As for content, I polished the first two levels and completely redesigned the second one. After that I added level 3, 4 and a few playground levels for testing. With the new level loader you can try any of these out.


On some non visible features that I’ve worked on to help develop the game better, I’ve been working a lot on how my level construction works. Previously I was constructing my entities by hand in json, which was great because I could make entities really flexible with my entity component system, but got tedious when it came to making levels with many entities. Now, I’ve added a parser to read object properties from the tiled editor so that I can construct the entity components from inside the map editor! It has been a massive help, and I’ve now updated all the previous levels to use this new system.

I have a few focuses for the next release that I would love to get done. I am planning to start putting out new releases at the end of each month.

  • get some better art into the game
  • add a new puzzle and level (probably to do with circuits)
  • polish the older levels and split up level 1 so it isn’t so long
  • polish up level 4
  • bug fixes

Discoblade – A rhythm based swordfighting game

Hi friends! I am working on a new game project called Discoblade.

Discoblade concept art

Rough concept design



A rhythm based swordfighting game where you have to block and attack to the rhythm of the music. You have an enemy in front of you who charges up attacks from various directions, and on the beat, you have to block in the direction that the enemy is attacking. On some beats, you also have the chance to attack the enemy back, and will try to attack in the opposite direction that the enemy is blocking in. So for example if the rhythm goes “dum dum dum tshh”, you would have the actions “block block block attack”.

Discoblade programmer art

Early programmer prototype art


Each level presents a unique setting, with completely different environments, characters and context. I also plan for each level to be created by a different artist and musician who are free to express the game in their personal art styles. So for example, one level might be based in a medieval setting made in pixel art with a chip tuney type background music. Another level might be based in a cyberpunk world using dark illustration type art with a more techno based rhythm. The goal would be to have as much variety as possible, and allow many artists and musicians to be as creative as possible.


The game is currently being developed in Java LibGDX, and is planned to be released on Windows, Mac and Linux.


Planning stage

Internal deadlines

Playable prototype – Right now the plan is to have a playable prototype with one level by the end of July. This will be used see game concept works, experiment with different ideas, and get feedback from players.

Art & Music – I have commissioned an artist and a musician to create the assets for the prototype level.

Discoblade concept designs

Early character designs

Current plans

Gameplay – Score based gameplay where you build your combo multiplier by consecutively blocking and attacking without interruption. Each block and attack will be worth a certain number of base points. Possibly failure state if you fail to block too many.

Leaderboards – Each song should have a unique leaderboard based on score.

Future brainstorming

Mod support – Make it easy for people to create their own levels using their own artwork and music.

Other gamemodes – Thinking about other gamemodes, for example a gamemode where it isn’t based on the rhythm, but just how fast you can react correctly to the enemy.

Own music – Make it easy for players to use their own music library. This will likely be tied to the other gamemodes.

Base score multipliers – At the start of the level, have various options that affect difficulty and score multiplier. Options such as beats per minute, UI toggle, directional helpers, failure state, etc.

Sudokil Devlog #2 – Computer terminals!

I’ve spent a bit of time coding a system that allows you to connect to a different filestructure from your terminal window. This means that I can have different access terminals around the level that you have to send a robot to in order to use their devices. In this example, I use a robot to connect to the terminal in order to open a door blocking the path.


I am starting to get a clearer picture in my head as to how I want the gameplay to be. I think I might have wires going out from each computer terminal attaching itself onto different devices. This way the player has a clear idea as to what computer terminal can access what. All the different connected systems could be colour coded? Maybe there could be some kind of wifi system? I did say STARTING to get a clearer picture.

There is still a lot of foundation work to be done, for example code infrastructure wise, I would like to at least get started on an in game level editor,  and improve the command line interface code. I think I might put that off for awhile though, and focus instead on constructing a prototype level. This way I can get  a clearer picture of how I want to game to be, and whether I can actually make it fun or not. On a different design note, I’d love to talk to some people familiar with unix scripting, and get some feedback to redesign the command line interface structure. This project is starting to sound more serious than I originally intended, but I am really enjoying it so I am going to keep dev-ing!

Sudokil Devlog #1 – Playing with CLI mechanics

Here’s the first video showing off the work I started on a new project nicknamed Sudokil. The game revolves around having to use the command line interface to type commands into the game. Through the CLI, you are able to navigate a file system full of scripts and entities using UNIX like commands. Using the scripts, you can control various entities, devices and machines like robots, doors, cameras and computers.

I started making this game just as practice while warming up for LD30, but recently have picked it back up again because it was an interesting concept. The inspiration for using a command line interface to control a robot originally came from the game Duskers by MisfitsAttic (I AM SO EXCITED FOR THIS GAME). As I developed more and more though, I realised the potential of using the CLI for more things like possibly hacking into things. There are quite a few games that have the theme of hacking in them, but very few of them actually resemble hacking in any form at all (a few exceptions like Uplink). I am currently trying to build up my code base of things to use for future games (some boilerplate code for a level editor, main menu, game saves and game preferences) while also playing around with the command line mechanics to see how far I can take them. I usually swap around between working on the game mechanics and the code base I am building because it does get tedious focusing on one for too long.


Strangely enough, after making the video I stumbled upon Quadrilateral Cowboy by Blendo Games (I love his games, my favourite being Atom Zombie Smasher), and it seems to have a few similarities in terms of the CLI. Brendon is a god of game design though, so I might end up having to steal some of his ideas on how to implement the command line mechanic well. From what I have seen so far, the scripting in it seems fairly basic (though the rest of the game looks oh so beautiful), so maybe I can take that aspect a bit further. Unfortunately, focusing on the scripting might put off a lot of people (especially less tech savvy ones), but if I can make a short game that a few people enjoy, I’ll be a happy camper.

Aside from coding, I want to do more research on writing bash scripts and using the UNIX command line terminal. Hopefully I will have some cool new ideas next time, but feel free to give me any suggestions and feedback!

[LD29] Eskimo Run Post-Mortem

Eskimo Run is my fourth entry to the Ludum Dare competition. The theme this time was “Beneath the Surface”, and the optional theme was “Pepsi Consultant”. I opted to go for the infinite runner type gameplay where your character is constantly running right and you have to jump to avoid obstacles (except with a finite number of hand crafted levels). The twist I incorporated into the game to follow the theme is that you are running on a surface of ice that you can dive through to then travel beneath the surface. While above water, you jump to avoid spikes and blocks, while underwater you dive to avoid spikes and fish. In order to follow the optional theme, I made the enemy chasing you the pepsi consultant! You have to make sure to move faster than him by avoiding obstacles, otherwise he catches up with you and sponsors your game jam!

Play the game | Ludum Dare

What went wrong:

Level design

Oh dear. I personally consider this the biggest flaw of this submission. Because of the poor level design, the levels just don’t feel like they flow well. Ideally, a good player should be able to run the entire map perfectly without any stoppages. In this case, I rushed through the level design, and the poor placements of tiles and spikes cause the flow of the game to feel lacking. You constantly get stopped and slowed down, which really detracts from the feel of the game. The other issue with level design is that I made the underwater section too difficult! The theme is almost ignored because it is almost always detrimental for you to go underwater. If I had a few extra hours to work on my levels instead of rushing through them, I think the game could be multiple times better.

Code efficiency

For the first time in all my game development projects, I ran into performance issues. This was mostly caused by the stitched together particle emission system, which constantly produces snow, ice and bubble particles. In the end, a lot of people had trouble running the game smoothly enough to play, and I ended up making a light version which does not use particle effects. In the future, I will try to use a game engine that incorporates opengl just so I don’t have to worry as much about performance.


Unfortunately the physics for the spikes often produced a buggy feeling due to gravity not being handled properly. Sometimes, the game would think you are standing on spikes even though you are slightly elevated next to it. This greatly impacted the game as it made it feel incredibly unfair at times when you actually do make the jump but get slowed down anyway.

What went right:

Art art art

I dare say that this project is a massive improvement in terms of graphics. I like the pixel art for my character, the background, the clouds. the tiles and the fish. I find that all of them match well together to form a cute and polished looking game. I spent quite a lot of time drawing the sprites, and I feel that it really shows. I also spent a lot of time on some subtle particle effects like the snow, bubbles and ice shards when diving through the water. While trivial, along with the fish and clouds, they really help in making the world feel like it is actually alive.


Instead of spending all my time coding, I decided to put a bit more effort into making more assets like sprites and levels. This time, I managed to make a variety of sprites and three different levels. This made the progression a bit more fun and interesting than last time because you are introduced to new things every level.


I DID IT! I ACTUALLY HAVE MUSIC THIS TIME. Ok, I kinda consider it cheating a bit, but I used a random music generator that I found online. Apparently that completely conforms to Ludum Dare rules, and I’ve seen quite a few people do it. While feeling cheaty, I think it was worth it. It didn’t take much time at all to implement into the game, and it really helped the atmosphere and variety to have this lively music playing in the background. Will definitely be doing this again in the future.


Although the level design didn’t really accommodate well for it, I felt that I had a fairly unique spin on the theme and endless runners in general. I really like the idea of having two channels to navigate through the level which you can switch on anytime. While you could technically complete the level only using one path, sometimes it was easier to go the other way. The use of the pepsi consultant was also a huge plus as a lot of people who understood who he is found it hilarious. For three out of four of my Ludum Dare games, I’ve used a strange twist like the pepsi consultant for the story context, and I think it adds a lot. Even with identical gameplay, a silly story can make the game feel more fun because you get a little more immersed and amused as you play. Hopefully I can keep thinking of gags revolving around the theme!


I think this was probably my ‘best’ Ludum Dare entry if you look at it overall. While I found the gameplay more fun in The Naughty List, Eskimo Run simply had more content and polish. The art and music just made the game feel much more complete. Hopefully in my next game, I’ll be able to strike up a better balance, or perhaps just work faster so that I can get in all the features and assets I want!

[LD28] The Naughty List Post-Mortem

My third Ludum Dare entry The Naughty List! This time the theme was “You Only Get One”, and I decided to interpret this by making an archer where you only get one arrow.  The premise of the game is that you have been put on Santa’s naughty list, and he is fed up. He’s decided to send his hitmen elves after you, so you have to defend yourself against the waves of them. I am actually really pleased with this game. While it could be improved a lot as always, I think this is my best entry so far.

Play the game | Ludum Dare

What went wrong:

Failed entity system

Oh dear. The first twelve hours of development ended up getting COMPLETELY scrapped. I attempted to use this entity component system I made, but because I’d never really made a complete game with it before, I really struggled to get it implemented correctly. In the end I had to scrap it and go back to using the traditional inheritance way. This cost me a LOT of time, and I think the game would have turned out much better if I had used that time for something else. Oh well, I will continue looking into this entity component system to use in the future since it is interesting!


Man was this game buggy. I struggled as hard as I could to implement the features I wanted and to get everything into a functional state. This means a lot of bugs and strange quirks. The physics was kind of horribly done, mostly caused by poor and cheap collision code. The way I did collision can sometimes cause trouble as it could make entities teleport on top of each other in specific circumstances. This is especially dangerous when you desperately need your arrow and it suddenly flies off somewhere difficult to get to. The good thing about the poor collision code though was it facilitated for some interesting mechanics which I’ll talk about later in the ‘What went right’ section.

Gameplay and asset variety

The entire game only consists of three identical levels with an increasing number of total enemies and their spawn rates. This meant that each level was the same as the last with just a few extra identical enemies each time. I would have loved to have made some different levels. blocks and enemies but as usual, time was the limiting factor. I really developed right to the last minute of submission hour. In the end, in terms of blocks only had the snow/ice block, the snow/ice background block, the sky block and the water blocks so the only level I had was fairly bland looking.

Music and sound

Like my previous game, I didn’t have time to add in any music or sound effects. This is something I would really like to work on for the next game. I have no experience with this whatsoever, so I’ll either have to learn to make them or use some random sound generator.


Because I had such limited assets, I had to find a way to artificially increase the difficulty of the game with each level. How did I do this? I simply raised the number of enemies that spawn at the same time, and raised the cap of how many can spawn. This caused level 3 to just be a large horde of bloodthirsty elves looking to shank you. While that sounds awesome, in the end it just didn’t work well with the only one arrow theme since the arrow would just get stuck in the middle of the horde with no way for you to retrieve it.

What went right:


Despite the large difficulty jump and lack of content, I actually found the game quite fun. I really liked the bow and arrow mechanics. To be honest, I was actually quite pleasantly surprised by the outcome of the game. The shooting and collecting your arrow while trying to kite the elves around actually worked together quite well.


While the movement was OK feeling, I REALLY loved the feel of firing the bow. The charging up mechanics and animations made the bow feel like it had some weight to it. I think this is a big factor of why I find the game to be a success to me.


While I would have loved to have been able to make more assets, I am actually quite pleased with my art for the character and elves. I am primarily a programmer, so doing this character pixel art was quite a large step for me that took quite a lot of time. I particularly thought the player character looks cool and cute at the same time.


The theme just worked out so perfectly. I managed to fully incorporate “You only get one” into the gameplay by making there only be one arrow for the player to pick up. In the end I felt that the game really fully revolved around the theme rather than being hindered by it. If I had given the player more arrows, the game would have been completely different. For one, the player could just hide on a ledge while shooting the enemies one by one. Secondly, I would have had to make the enemies soak up a few arrows which would take a lot away from the feel of the shooting.


Since Christmas is this month, I thought I would use it for the setting of my game. I managed to come up with a pretty funny storyline revolving around Santa Claus and his elves being kind of evil. The whole ridiculousness of the situation kind of made it funnier and gave some context to the game rather than making it a mindless violence game.


Overall, I am extremely pleased with the outcome of the game. I think everything came together very nicely to form a fun and complete game. I learnt quite a lot from this experience, and I think I can really improve for the next game jam. Firstly, I learnt that the entity component system I designed does not work. Secondly, I practiced my pixel art skills a lot and was quite pleased with the outcome. I really enjoyed this Ludum Dare, and am looking forward to the next one!

[LD27] Dissociation post-mortem

It is a few days after the competition now, so I’ve had some time to rest and reflect about my performance over the weekend. Although I am not entirely happy with the outcome of my game, I am very proud that I managed to string together a functioning game with an actual goal. I would have loved to have more time to implement all the features I wanted, but I guess every LDer runs into that issue.

javaw 2013-08-28 04-16-26-89

Play the gameLudum Dare

I managed to render my ridiculous timelapse video after having a lot of trouble. The biggest lesson I have learnt this weekend is not to record a time-lapse in fraps because 10 hours of footage is about 500 GB of data. Sadly, this meant I only managed to record about half of my work over the weekend, but it is symbolic enough none the less. I’ve compressed about 12 hours of footage into a few minutes, but I had to render multiple times so it really screwed up the video quality. Oh well, I have learnt from my mistake. In the future, I will use fraps to automatically take a screenshot every 10 seconds or so, and instead use the image files to compile the time-lapse.

What went wrong:


I spent way too long fussing over how neat and reusable my code was, that in the end I was very short on time. I managed to program all these brilliant tools for making maps, characters, and weapons, but because of the lack in time, I couldn’t make the assets to actually use the tools. I ended up with only a few building variations, 3 characters, and 2 weapons. It really doesn’t take long to add variety to the game because of all the infrastructure I coded, but because I didn’t have time to make any art assets for them, the tools proved to be useless. I really should have just hard coded everything. That way I would have been able to focus more on the art, and actually make some sound effects and music. Next time, I will definitely try to manage my time better.


The theme was actually another reason I ran out of time. I decided to do a more ambitious project in hopes of using the theme in a more interesting and unique way. I originally planned for you to play as the good personality, trying to keep your other personality out of trouble by hiding weapons from him, or taking pills to try to suppress the amount of control he has over you. Unfortunately, I realised I was running short on time and had to change the rules so that you play the psychopathic personality that is obsessed with murder. In the end, the theme felt very tacked on, and not an essential part of the game even though the whole game was planned around it.


Because of the lack in time, I really skimped out on the art. I didn’t have time to texture the buildings, floor and doors. And I had to design the characters as just emoticons so that it would be faster to make. I really want to focus on this more next time.

Music and sound

As I said before,  I didn’t have any time to make the music or sound due to the lack in time. To be honest, even if I did have a few hours, I’m not entirely certain I would have been able to make any. I have absolutely no experience in any sound software, and was very unprepared.

Mental stamina

On the first day, I should have gone to sleep much earlier. I spent a good amount of the day doing proper work, but I started to slow down near the end. I started day dreaming, getting distracted and making bad decisions due to being tired and having worked on the game for so long. I would have been much more productive if I went to bed a few hours earlier and woke a few hours earlier the next day.

What went right:


I personally felt that I had done some very solid coding. The game is relatively bug free, works as intended, and has some very reusable classes. I spent too much time on coding properly, but that did mean it came out quite nicely. I might pull out some of the stuff made in here to keep for later as some basecode.

Blog posts

I think constantly forcing myself to step away from the coding to write a development log about my progress really helped me. It gave me a good break, and allowed me to take a step back and evaluate the choices I was making. This helped me slow down, think more about what I was going to do without just rushing into a decision that would have turned out badly.


I managed to get a few people to play the game and give me feedback. This helped me find a game breaking bug that I could not replicate on my own computer, but I managed to fix that. I got a lot of great suggestions, and I wish I had time to actually use them, but I didn’t even have enough time to fill in my own stuff.


In general, I thought development went well. I spent a total of about 25 hours of pure development (taking out breaks, etc), which is quite a lot in 48 hours. I also felt quite productive in that time, even though I might not have been producing the right things.


Overall, while I wish the game could have come out so much better with all the features that I planned, I am still very pleased that I managed to make a functioning game. I think it can actually be quite fun once you understand all the rules and controls. The competition has definitely given me a kick of inspiration to continue with game development once again, so I hope to use this to be a bit more productive. My next project will likely be the October challenge, where you have to try to make at least $1 by making a game. I think completing a challenge like that will be absolutely crucial to moving up a level in terms of game development.