A Hand Drawn Christmas Game is a short but charming platformer featuring children’s book art and a 14 page Christmas adventure.
In A Hand Drawn Christmas Game you bounce on living chimney pots and dive into piles of colourful presents in the search of festive poems.
As Christmas is a time for giving, 10% of every sale isdonated to the World Land Trust (David Attenborough’s favourite wildlife charity). Pop in your desired price below and hit “Add to cart”. Then use the download link in the email and Merry Christmas!
Yesterday I uploaded the first version of the ship-building tool for public download. Even though I totally 100% expected no-one to download it, one person did! So thank you mystery visitor!
Though it might seem odd or even counter-productive to release such rudimentary software this early, it actually has several very useful benefits for me as a developer:
Probably most importantly, it’s good for me to just get it out there. I’ve always had a fear of releasing things that aren’t perfect. Give me a year-long release deadline and I’ll be the guy up on December 31st at 11:45pm trying to squeeze in those last minute adjustments. The awesome thing about overcoming this fear is that later releases can only get better.
Even if people who download early builds have the understandable reaction of “Jesus this is terrible, who does this guy think he’s fooling?”, at least I’ve faced that criticism and know where I stand, and later builds will have taken that feedback into account and hopefully improved on it.
When more people are prepared to DL the game (after a certain amount of functionality is assured) it’ll give me helpful feedback on direction. A big fear of mine is spending a lot of time creating something people aren’t interested in, so releasing early lets me know where I’m going right/wrong.
It helps me know what kinds of descriptions, screenshots, etc… draw the most interest, so by the time I get round to having a more complete game I’ll better know how to capture potential player’s interest.
It helps me iron out any problems with the site, links, and downloading – with gradually increasing numbers (fingers crossed).
Now it’s just a case of improving the game, getting any small but valuable nuggets of feedback where I can, and improving things till larger volumes of people begin to download.
But yeah, shout out that first brave soul who DL’d Starship Explorers V001! You’ll always have a special place in this game’s history.
This week I created a few placeholder assets to set my materials up with. I set up a master material that takes an integer from 1 to 4 to display the correct direction for the texture.
I’m using an RGB (Red, Green, Blue) map to control the colours, and for the first few assets I painstakingly drew each map by hand. Fortunately, I quickly realised I could apply a block colour to certain parts in the 3D Modelling program. Using an orthographic camera I took 2 shots every 90 degrees; one for the texture and one for the RGB map. These were then composed in Photoshop.
For players that want that “custom look” without having to colour every item by hand, I’m hoping this system will allow for ship-wide colour schemes. It will give modders more or less complete control over the colours of their creations too.
To sum up, making master materials or master actors takes time to set up, but is a great time saver in the long run. On the programming side it’s much easier to work with a master that takes a few inputs, than creating unique assets for every item/material combination. From a player perspective this will ultimately grant the highest level of control whilst still being intuitive and simple to use.
The next item on the to-do list is letting players place, rotate, and delete these items in the Ship Builder.
This is a bit of a technical post where I try and explain how I’m handling the data during ship building. I hope with these posts I can provide info to anyone interested in game development, and maybe some answers to devs trying to do similar things later. I’m not too used to writing blogs so I hope my content will improve over time!
This week I reworked the way the game stores item information as the standard grid method I was using was too inefficient. In the original method, if a ship was a long flat shape, say 10×200 tiles, the standard grid method required a grid of 200×200, meaning an unused 36,100 (190×190) tiles were being stored.
Now, I’m trying to get the system working purely using 2D vectors (X and Y) relative to the ship actor’s origin. To get their neighbours I’m adding the tile size to the X and/or Y coordinates. Vectors get added to an array of “used” vectors as they are built on. To restrain ship sizes, instead of having a list of grid edge tiles, I now just check to make sure the new tile is within a range; between XY:0 and XY:’Grid Size’.
There’s a big global list of items that stores their stats and unique ID number. Rooms, zones, and individual tiles all have lists storing the ID Numbers of the items they contain. The item info can then be retrieved using the reference.
It’s been really interesting coding the ship builder features. It effectively turned into a paint program, so I’m drawing heavily from existing paint packages on the basis that most people will already know how to use them. I want to make it as smooth and intuitive an experience as possible.
You can use a tablet to draw with, so artists can go wild. I’m hoping we’ll see some really unique and beautiful ship designs being shared on the forum.
Coding-wise, I want to have a really solid foundation with the flexibility to support modding later down the line. At the moment you can only build smallish ships up to half a mile long. I hope to increase that up to 3 miles once I have optimised pathfinding in place. Although the game is designed for smaller ships, I know that many players will want to build the largest vessel possible (I know you will because it’s the first thing I did).
In Febuary my game idea was selected for the Tranzfuser competition. We recieved £5000 over a 10 week period, and in 1 month we get to showcase our demo at EGX 2017 alongside the 20 or so other teams selected.
I made Six Sided Slime as a project for artists, which is what the team are. It’s a fun project with some unique visuals but ultimately it’s not winning any awards for innovation. In Six Sided Slime you defend a centeral hub from waves of blob-like gelatinous cubes by building turrets and shooting the slime with scifi weaponary. The whole thing has a very 50s B Movie scifi vibe. The idea was also generated very quickly to meet the Tranzfuser application deadline. In retrospect my biggest mistake was going for an idea that I thought would be quick to make, rather than one that I was personally passionate about.
Since Febuary I’ve devoured a metric ton of game design theory in the form of books, articles, blogs, and verbal advice from experienced designers. This has led me to develop a brand new game design, one I think is far superior to Six Sided Slime, but I’ll come back to that in a bit.
When doing my research for Six Sided a big oversight on my part was the imminent release of Fortnite, Epic’s own building/crafting tower defence. It’s basically everything I wanted for Slime but with 5 extra years of production, and a large team of veteran devs behind it.
The only way to avoid playing second, third, or even fourth fiddle to OMD, Sanctum, Fortnite, and the rest of the reigning Tower Defence champs, is to come up with a game that caters to an untapped niche within that market. Six Sided Slime, as it stands, doesn’t do that. The vibe is unique for sure – Golden Age scifi is a rich field of untapped inspiration for developers. Lots of games draw from this era third hand, but very few go all in and actually replicate straight from the source.
Nevertheless, if the only thing we have going for us is our ‘unique vibe’, our potential audience are still going to see the design for what it is; a clone.
So I decided to make a clean break. Taking the lessons I learned I’ve created a design that could be a very big hit – at least in relation to other small team projects. It also resonates with me at a much more personal level, which is ideal for motivation.
This new design incorporates many features from existing popular games whilst doing something significantly new with them. It also has near infinite replay value, is highly suited to modding, and would create much more memorable, meaningful experiences for players. Best of all, it takes proven popular mechanics from several very different games and melds them into a wonderfully unique subset of its genre.
Space Ship Simulator (I have a thing for SSS acronyms apparently) would take the base creation of Rimworld or Prison Architect, and combine it with the star-trek inspired adventures of FTL. You build an entirely customised spaceship, man it with an eclectic crew, and set out to explore a rich procedural universe, filled with procedurally generated species, alien encounters, factions, planets, and, of course, other spaceships.
The aim is to replicate the feel of an episode of Star Trek, Battlestar, or even Firefly, but this time it’s you making the tough descisions; negotiating with proud alien warlords, scavenging wrecks for spare parts, or rescuing freighters of Targathian orphans.
The unique gameplay comes from the melding of ship-to-ship combat and the tile-based freedom of Prison Architect or Rimworld. You can handle encounters however you want; destroy their shields with your mighty guns then beam across your best men to take the ship from the inside. Launch custom-built fighters and destroy their hull so all the oxygen vents into space, or Picard your way to a peaceful resolution in a Civ-style negotiation.
Of course combat isn’t the only experience to have in the game. You have to manage your crews needs and keep your ship flying. You can take quests to improve your standing with factions and earn rewards, or go entirely freelance and earn a name as an infamous pirate scourge. There’s no plan to allow planetary landing beyond perhaps a few small maps, but planets will still offer resources, quests, crew, and new alien creatures to discover, eat, fight, or tame.
I’ve been working on Space Station Simulator in my sparse downtime for the past few months. The ship building foundations are already place – you can build a basic internal structure, clad your hull with shapes (currently a hastily textured semi-circle), and save and load different ships. Temperature and oxygen also works per tile, but is yet to be implemented into the ship structure. The next priorities are creating customised crew and letting them navigate the ship’s structure.
Six Sided Slime will be a fun experience at EGX. Players will enjoy the 5 minutes or so they spend playing the demo. I’m not expecting any “wow, holy crap, where can I buy this??” reactions though, which is ultimately what I’m gunning for in my game designs.
I’m taking a video of Space Station Simulator along to EGX to show players too. I anticipate a much more enlivened reaction to this game, despite its early development. If my predictions are proved right, I’ll take the idea to the wider gaming community and begin to build an early fan base.