Rect is a local multiplayer game I've worked on in 2014. Each player plays as a rectangle (hence the name), the objective is to colour as much of the board as you can within the time limit.
Yeah. Damn. 2014. This wasn't my first major-effort game (that was Altair), but this was the first where I wanted to take this game dev thing seriously. Which meant also doing all the things around game development, like dev diaries, trailers, media, etc. This was mostly done on IndieDb, a great game sharing site for independent games. Actually, it still has all my diary entries if you wish to see more of the development process. It also paid off taking the things around it seriously. I remember when I've logged in one day to check my download statistics, I've seen this crazy spike. I couldn't belive it! As it turns out, because of having a competent game profile, with pictures, regular releases and articles, I got featured on the IndieDb homepage. I think that was my proudest moment of game development to that point.
This was also the game I've submitted to the <19 freestyle programming competition.
Today, I've played it again, with my flatmate and my girlfriend. You know what, it's still a good game. I was genuinely surprised. I remember it being a loads of fun playing it with friends in highschool while I was working on it, but yeah, it still holds up. I can see some bugs, it's far from perfect, but it's a really solid little game. You can download the final version from the link below. Be warned, the final version also has LAN multiplayer, but I have no idea if it still works. I couldn't get it working. But LAN was never the main focus.
Download Rect (Win) - Indie DB
Now in terms of actually loading it in Unity, I have some bad news. Given that it was 6 years ago, the Unity UI Engine and networking Engine that this was using was fully depricated. If you're feeling brave, you can dowload an older version of Unity from the Unity Archive. I used 4.6.6, so you should use that or above. In terms of source code, here you go. Don't expect to see best practices. As I look back, I cringe at all the horrible solutions, but that's what 6 years of extra experience gives you I guess.
What is of worth learning from this game, is not really technical. I'd summarise it in these key takeaways:
- Never underestimate the usefullness all the things surrounding game development. Write a journal. Do a vlog. Talk about your projects online, share it with others. I know often all you want to do is focus on the game and nothing else, and you're right, the main focus should be the game, but there is value in letting others in on the process.
- Sometime a core gameplay loop is enough. Not always, but sometimes. This game doesn't really have depth. Yes there are game modes, and levels and sillyness, but this game can be boiled down to a solid 2 minute gameplay loop, that you play with some friends.
- For this style of game, fun should be your only metric. When doing any change, ask yourself, does it allow me to have more fun. If yes, do it. This is not an excuse not to make a competent game, a buggy mess is no fun, but there is no point in polishing and adding depth, to a game where the point is the chaos and being angry at your friend who took the powerup from you again!
What you should try with the source code:
- Add more powerups! New weapons, new poweres, but also think evil powerups that would hinder the player for picking it up accidentally
- Add more levels! See what you can design given the high speed and chaos of the game. Be careful not to have maps that slow down the gameplay
- See how you can change the AI. Once you understand how it works in the first place, see if you can make it more aggressive, more tactical, etc
You're welcome to show me what you made out of it. Email me on tituszban@gmail.com, or message me on LinkedIn.
Elevator is a mobile game where you controll elevators to deliver players to their floors, published May 2014
One day at some mall I was waiting for someone and watched this pair of elevators going up and down. This was around the time I started seeing the algorithms behind everyday things. I started wondering what was the logic behind the how the next floor is selected, and how it would change, if the algorithm knew ahead of time exactly how many people will board, and which floors they were going to. That was about the time I realsied that this sounds pretty fun, and I should make a game out of this. So I did.
This was the typical side project, that got out of hand. After that first burst of inspiration I started working on this to take a break from my big project at the time (Altair). Yes, I took breaks from game development, with more game development. After an initial proof of concept, where people wanted to go to floors, got in to the elevator, and got out on the right floor, and you could tell the elevator to go to floors I felt like I was onto something.
There were a couple difficult things during the prototype. Difficulties that face a novice developer, but to this day I remember the satisfaction of solving these problems. Generating random people, getting the elevator to snap to floors correctly, but the one that I remember the most, was a simple yet annoying issue: Once the elevator arrives on a floor, each person starts moving towards a random position inside the elevator. If the elevator leaves before reaching that position they go back to where they started (so you can't prepare people near the door, but leave them there). However, if they were inside the elevator car, but not yet at their desired position, and the elevator leaves the floor, they ran out of the moving elevator. This was clearly wrong, but the solution, obvious it may be for the reader and for me now, was quite difficult. I did find the right way, checking before turning back, if already inside the elevator, and continuing if so, but also setting the elevator as the parent early, so the person isn't left behind.
After having completed the prototype, and realising that I have a solid primary gameplay loop, I started focusing on secondary parts of the game. I came up with objectives, calibrated people's speed and how quickly they start to get angry and leave. This was also around the time I came up with powerups. You may sense a theme in my early games, I love(d) powerups! They added a sufficient amount of extra exictement, however, thinking back some of them should have been permanent, as certain levels are just impossible without activating some right at the beginning. Spoilers if you actually want to play the game. (If you're interested, you could try and fix these issues. Try downloading the game, and see what happens if you modify the people and the powerups.)
This was followed by the thirtiary loop, setting up levels, creating different backgrounds, multiple elevators, persisiting money, etc. And right there, in a couple months, you have a pretty solid game. What's next?
The first game I actually published! As it turns out, publishing a game to Android is cheap and easy. Like really cheap. At the time of writing it's $25. Which is not nothing, but also negligable compared to some other platforms. That is $25 as a one of, not per game. If you're serious about game development, and intend to publish games onto android, it's 100% worth the cost.
I definitely thought it was worth the cost. Porting over to Android was not easy, but Unity makes it as simple as it could be. And there it was. Out in the world, my first published game. I couldn't wait to tell the everyone I knew. Some did download it, which as it turns out is really helpful, as that initial interest the Play Store interprets as it being a relevant game, and it goes ahead and recommends it in the store.
Throughout its life it had quite a bit of success at least by my standards. At its peak it had a couple thousand people download it from all over the world. And ratings! Oh, the ratings, yes the first few were my friends. Obviously. But as time passed, I started getting random people rating it! Yes, some people didn't like it, or didn't understand it, which always happend, but on the whole it got positive ratings, and I was happy! A couple years ago it was pulled due to some play store changes that I didn't update the game for. I missed the emails, and it was far in my rearview mirror. But you know what, I went back, fixed the Play Store listing, and you can go and download it from here. Yes, you'll get a warning, that it's for an old Android version, but it still mostly works.
So what about other platforms, IOS more specifically? Well, to publish on IOS you have to pay $99 a year as a store fee. Which while makes sense for professional developers, it's a bit steep for a hobbist such as myself. Also, you have to have some Apple computer and even a Mac Mini will set you back $799 which I'd rather spend on anything else. You may decide that it's worth if for you, but it wasn't for me.
This too, is an older game, so you'll have to grab an older version of Unity from the Unity Archive. For this too, I've used 4.6.6, and it worked just fine. You can download the full source from here
Key takeaways:
- Publish your games. It's very easy once you finish, to close the project, smile at a job well done and move on to the next project. But publishing games is easier than it ever was, on platforms like Android and Itch.io. Try putting what you do out there. But do so, once what you have is actually any good. There is way too much shovelware on these free platforms. You need some good qualities to stand out.
- Take your hobby project, and run with it. This has seen way more success, than the main game that I've actually worked on during this time. Why? This was a better game. It had a solid primary loop, with well designed secondary and thirtiary loops.
- Inspiration can come anywhere. Let your mind wonder on every day things. Let it see the game in everything. Almost everything can be turned into a game!
What you should try with the source code:
- Try messing around with the powerups. See how you can change the balance of the game by modifying how powerfull these are
- Try chaning the ballance of people. What happend if they're faster/slower? What happens if they get angry earlier?
- See if you can add new level mechanics, besides more floors or elevators. Elevators on two sides?
- One weakness of this game is it's looks. Charming it may be, it looked old fashioned even in 2014. Can you re-texture it? Make it look actually good?
You're welcome to show me what you made out of it. Email me on tituszban@gmail.com, or message me on LinkedIn.
A note on monetisation: as you may see, there are no ads, no microtransactions in this game. Not to say I didn't consider or even experiment with avenues of monetisation, but at the end, I decided that it wasn't right for this game. This was a passion project, but as such, I want to be able to move on once I'm finished. I was much happier with a great pure experience, than something cluttered with ads. You may chose to monetise your games. And yes, something that you've worked hard on is a great feeling, but keep in mind, why you're making games.
Altair is a 3D first-person exploration-puzzle game I've worked on 2013-2014 as my Year-long project in highschool.
Oh boy. The story of Altair is more a cautionary tale. I've discovered the world of game development at around mid-2013. I was amazed. I thought I could do anything. I was wrong. After building a couple prototypes for moving around in first person, I thought it was a good idea to start working on a full length first-person game as my year-long project. That seems perfectly reasonable. I was wrong. I thought I should start writing lore, come up with characters and a story, design a map, and of course, fill it with puzzles. Because that's what a game is supposed to be. Wrong. Wrong. Wrong. Luckily the friends who I was pitching ideas to convinced me not to do my original idea, which was a Portal-like puzzle platformer with some witty AI. That would have been an even bigger disaster. Here is a hint: you may think you're as funny as professional writers with years of experience, but you're not.
Here is just a taste of all the things I've tried to include in this game, and got wrong
- Have a strong and distinct atosphere! It was just dark. Way too dark.
- Animated graphics! They didn't fit or light properly.
- Multiple abandoned areas! It was way too big, ofter wrong proportions, and felt empty because populating 3D environments is very difficult to get right.
- Voice acting! My biggest thanks to the couple people I managed to drag into my schools radio studio and record a script. Then the editing rouined it. Too fast, no breaks, difficult to understand.
- Story! I didn't write it. It was a friend, who actually came up with a very competent back story for the game, (it's almost like people can do a good job if they focus on one thing they're good at and don't try to do everyting) but we've scoped it to be way to big, so none of it made it into the game, except for a wall of text in the menu and a single audio log. (Again, huge thanks to the people who recorded it)
- Realistic graphics! They mostly just looked bad. Scaling was off, they were too big and unoptimised, meaning that the game was just slow, but fear not, they were also uninteresting.
- Puzzles! By trying to make realistic equipment, where interaction would mirror real interactions with the objects, I just managed to create a set of disjointed puzzles, where solving one did not aid in solving any other ones, but also very difficult to figure out how to progress, without getting hints.
- Sound effects! Volumes were all over the place, and step sounds were seemingly random.
- High fidelity models! The game ran terribly. Also, it was both busy and uninteresting at the same time, lacking the industrial beauty of real equipments, with lots of details where you know everything has a purpose. They also took way to long to make. I've spent more time making 3D models than programming the game, the part I've really enjoyoed.
- And many more...
Certanly every one of these issues could've been avoided or fixed, but not all of them, or at least not in one year. I bit of more than I could chew, and than stubbornly kept at it, not seeing most of these flaws on a project that I've dedicated so much time to. Based on how critical I am with this project now, you might think I consider this project a failure. I don't. Don't get me wrong, I don't think I've made a good game, but I've learnt so much from this, that at the end of the day I'm happy I've tried this. And you should be too, because it's a mistake you don't have to make.
If looking at the above list of failiures you still think, that you want to attempt a big, feature length 3D game as your first, you know what I understand. I also thought that "to hell with anyone who thinks otherwise, I'm building the game of my dreams!". I do hope, that you listen to me, and start small. I am so much prouder of some games that I've built in a weekend, than this that I've worked months on. But if you insist on building something big, at least try to learn from it, as much as you could. Here are some of the things I've learnt from this project:
- Time management: deadlines are the worst. But they're a fact of game development as much as they're a fact of life. And I was lucky enought to be force into setting multiple deadlines throughout the year, which I had to hit. I've learnt so much about setting my scope for a game correctly (or cutting down on the scope as the deadline approached) and forward planning.
- 3D modelling: It's not a skill that I've used for games since, but one that was crucial for doing Computer Aided Design (CAD) during university.
- Programming: this was essentially a year long bootcamp on having to solve difficult problems. A lot of programming is learning specific skills, methods, design patterns, etc, but a lot of it is just putting in your time, and gaining experience.
- Working with people: whether it be running design sessions, or directing my friends in the studio, I've learnt a lot of so called soft-skills from this project. Although my key takeaway at the time was that it was way too hard.
You can get the source code from this link if you really feel like exploring this disaster of a game. Unity 4.6.6 from the Unity Archive as for some of the others. I don't think there are really key takeaways here, other than to start small, and build games you can actually finish. Or build your dream game, I won't stop you!
There is no list of things you should try with the source code for this project. You can try fixing some of the issues, but it's not worth your effort, instead, tell me about one of your projects that turned out to be a disaster, because it was too big. Tell me about what you've learnt from it! Email me on tituszban@gmail.com, or message me on LinkedIn.
Artificial is a 2D narrative driven arcade game I've developed with a couple others for the Indies VS Pewdiepie gamejam in November 2014
A bit of context about game jams and this one in particular. Game jams are special. While they're technically competitions, it's more an opportunity for free creative expression. There's a common saying that creativity flourishes within restrictions. Game jams are the embodiment of this idea. You have 48-72 hours, and sometimes a concept/theme (but not always). And with that blank canvas, you're invited to build something. It's stressfull, and sometimes what comes out isn't spectecular, but sometimes, something special is created. You also get to experiment with ideas and collaborate with new people. This game jam in particular was the Indies vs Pewdiepie gamejam in 2014. This was a one of game jam hosted by online game hosting site gamejolt with YouTuber Pewdiepie. At this point he was already a well known creator, but it was before he became a YouTube superstar, and before his various controversies.
I think this was my first proper game jam and I took it very seriously. I've recruited two artists and a musitian, just on some online forum, and got my best friend involved to do some design and writing. Funny story, during the first day of the jam I was busy recieveing an award for Rect in the <19 freestyle programming competition, but I ran off right after the award ceremony, to go over to my friend's and work on this game. I've always cared more about building things than recieving praise for them.
Please note, as this is a story heavy game, and the following discussion will contain spoliers for said story, I strongly recommend playing it first, and than reading this. Here is a link for it: Artificial on GameJolt
From this point, I'll assume that you've played the game. So there we were, my friend and I and two artists online, looking for an idea. It's difficult to pinpoint, what inspired us to do create this game, but there are a couple things that lead us to creating this game. First of all, round this time both me and my friend were obsessed with Thomas Was Alone, a brilliant, werid indie platformer by Mike Bithel that featured some amazing characters who were also happend to be rectangles. This inspired the antrophomirfisms of the characters and the style of the narration. Second, we had two really talented artists, who have completely different artstyles. It's a game jam. You can't interview people, you take artists as they come and come up with something to fit them. This inspired the split world idea, so both of them can work in their own style. Last, my friend was a brilliant writer even at this point, so we decided to make this a story focused game.
The first big obstacle we overcame was getting a voice-over artist. At this point I was a huge fan of HocGaming, a YouTube channel mostly doing Kerbal Space Program gameplay. It was ran by Harv, who has an amazing voice. We've emailed him early into the project, asked him if he wanted to do the voiceover, and to our surprise, he said yes. This sealed in that we wanted the game focusing on narration.
So let's talk about the game itself. Wanting to do multiple smaller games, we've decided to make them simple acrade games, simply so there'd be nothing to explain for the people, instead they can understand each of the four games, just by looking at them. Shoot the baloons, save the people, escape from the lava, find the objects in the maze. which could very easily lead into, through the collapse of their reality, the real objective of the four characters, defend the city, destory the towns, escape from the firewall and provide hacking support. If you haven't played the game, I imagine this last sentance was very confusing.
So step one: create the four games, and a way to jump between them. Step two was, having a slider, to controll the probability of "reality peaking through", which required the randomised replacement of sprites, with a given probability. And then step three was, wiring up a narrative. This was the first time I ever had to do this. It was not easy. I still remember clearly, the deadline was 7 in the morning on a Monday, and from around 10 o'clock last night all I did was story scripting. Everything else was done, the artists and composers did a top-notch job, and delivered everything on time. All the animations in place, all the soundeffects triggering. Harv also delivered an amazing set of narration files. It was all in place, I just had to make it bring it all together. At this point I was at home, and from 10 to 7 the next day, I was scripting the story up, with my friend kept the life in me by chatting over Skype. But it was done. It worked and we watched the upload bar racing the end-of-jam countdown. I'm gratefull to my mum that I didn't have to go to school that day.
To this day, this is one of the games I'm proudest of. It came together beautifully. Not to say that it's perfect. I've plaid it today, and while I was wowed by how well it still worked, I realised that it was increadibly difficult. I've failed some levels over a dozen times. And it makes one of the mistakes that underpolised games oftem make, that if you replay a level, you have to listen to the same narration over-and-over again. The only thing saving it, was how good Harv sounds, but I can see how this could have been really annoying. It also fails to explain why some screens get locked. I've realised that the person who was different, the black balloon, the gold nugget and fourth thing to find in the maze were the reason this happened after I've plaid, by reading a text file in there. The red border communicates that something is going on well, but what is that thing should've been better explained. Lastly, the biggest mistake of all, which is somewhat related to it being too hard, was that two of the games were not really necessary. Nothing happens, if you don't save the people as the ambulance, and you can just hide in the corner from the cars, so Natalie can be ignored. And poor Glen, while he wants to provide support, if the player has no time, they can't use him to help the others. I think there should have been more significant gaps, where the player have time to fix up the other games with Glen.
As always, get the full source code and an older version of Unity (4.6.6) from the Unity Archive to see this project for yourself.
So what are the key takeaways from all this?
- Participate in Game Jams. It's an excellent way to try new things, meet new people and learn new skills.
- If you have access to a good writer, gameplay can become secondary to the story, as long as they complement each other, not just exists in parrallel to one and other.
- Turn weaknesses of the project into strength. We could've tried have the two artists emulate each other's style, but instead we let each focus on how they work, and used it to create something unique.
- Have good people in your life who enable you to spend the whole night working on something you love.
What you should try with the source code:
- Tweaking the difficulty should be fearly easy, see if you can make some of the sections easier while not making it too easy, so it becomes not fun
- Try to introduce gaps, mostly in the balloon game, so the player has time to breathe and maybe use the mouse to help the others.
- See if you can fix the car spawning logic in the ambulance game, so you can't just hide in a corner.
- Think of ways to better communicate why screens are getting locked. Maybe try the same red colour scheme around the culprits of the locking.
You're welcome to show me what you made out of it or any of your game jam games. Email me on tituszban@gmail.com, or message me on LinkedIn.
Lasers is a puzzle game I've worked on in 2015.
Lasers was really a passion project of mine. For a long time, I had this obsession with seeing lasers bounce back from a reflective surfice at a perfect angle. So with a couple games in the can, I wanted to make one, where you get to play around with bouncing lasers all over the place. I also wanted to make a puzzle game and I wanted to make another mobile game. So, the concept of Lasers was born.
You may see many similarities in art style to my other games, where I was doing the art. Flat primary colours, simple shapes and names that tell you exactly what to expect from the game. Art was never my strong side, but with these at least got me a point where the game was stylish, even if not pretty.
As puzzle games go, especially level based and for mobile, the steps in development are fairly straight forward.
- Come up with a core mechanic. In this case it was lasers reflecing from surfaces, going from an emitter to a target.
- Create a set of levels using this core mechanic, starting at the very simple to the more complex.
- Introduce new conecpts and mechanics (obstacles, multi colour lasers, black holes, portals, splitters, etc)
- Create a set of levels using just this mechanic, to let the player have an intuitive sense to it.
- Create a set of levels that use a combination of previous mechanics in combination
- Repeat from step 3.
Working on puzzle games are always tricky. Because what you think you'll be doing is coming up new mechanics, which is the fun and enjoyable part. What you really be working on most of the time, is designing levels. Which is a lot more difficult. For each new mechanic you introduce, you should probably have at least 5-10 new levels. So you can see, you will spend most of your time on levels. And designing puzzle levels are very difficult. It's a balancing act between difficulty, ranging from the trivial to the impossible and satisfaction, creating puzzles that feels good to solve. My recommendation, is before you decide to do a puzzle game of your own, master level design in other puzzle games. There are numerous that have level editors and community sharing. Practice making levels in those games and share it with friends and the community. Once you are skilled at creating compelling levels, then you should start thinking about creating your own mechanics.
Alongside the puzzling aspects there were a couple other parts I was working on. I was trying to do some sort of story. Why? I don't really know. What I ended up with was a weird, existential storry line, where the tutorial text starts to gain consciousness and tries to figure out the meaning of it's existance. It all lead up to the introduction of the level editor. Yes, there was going to be a level editor, and community map sharing. How? I don't think I've figured that out, other than encoding the levels in a strange sort of encoding of my own. I haven't discovered JSON or XML at that point. Looking back what was quite strange, is that even tho there is a level editor, the actual maps of the game didn't use it. It was an afterthouth, after having handrolled most of the map on various levels. Also there was going to be proper mobile integration with achievements, leaderboards and so on. And I was trying to do monetisation. Yes, you may see references in the game for calculating where ads shouls go, and a strange approach to having adds you can turn off where if you do the game tries to shame the player. That was a silly idea.
However, as I was adding more and more side features, I lost sight of what was important, which is is creating a compelling puzzle game. And that's what killed this project at the end of the day. A lot of the later levels, turned into pixel hunting. Trying to find the one right layout to solve the level. I made a mistake, that's so common to bad puzzle games, where the difficulty of the level isn't coming up with the solution, but actually executing it. It didn't help, that I kept introducing mechanics that amplified minor movements (such as the black hole and the splitters) while precision was already the issue on earlier levels. In hignsight the solution was probably to make the cubes rotate on discrete angles, to eliminate this issue, but that would've required a complete rework of all of the levels.
I didn't end up publishing Lasers. I am happy, that I've worked on this idea, but there is so much I which I've done differently. Here are some of the takeaways from this project:
- Prepare to do a lot of level design, if you want to do a puzzle game.
- Focus on perfecting the core gameplay and build your set of levels before adding more and more features. Avoid feature creep.
- If you want a level editor, use it for your actual levels. It will make you perfect the editor as you try to build more and more complex levels, which will allow your users to also build more and more levels.
- If you want to do community sharing, you better have at least a basic idea, of how you'll want to do it. Learn how servers work, and how to use some sort of cloud provider.
- Be able to identify is a game isn't working. Try to fix it if you can, abandon if if you can't. Don't keep building onto it blindly, hoping it'll all work out. It won't.
- If you have a passion, obession, something keep thinking about while your brain idles, make a game out of it!
Get the full source code and an older version of Unity (4.6.6) from the Unity Archive to see this project for yourself. It's important to note, which took me a bit to figure out as well. If you want to start from the menu, and play the full game, not just individual levels, you have to start with the Startup scene, not the Menu scene. It creates some important GameObjects that I didn't bother to instantiate in the menu if they're missing. Something you could try to fix! Other things you can try:
- See if making cubes rotate on discrete angles would make it work, and see how many levels it would break
- Try this as practice for creating levels. With the lack of proper community sharing you can't really give it to others to try, but it does provide a unique set of mechanics to play around with
- See if you can come up with more mechanics that make the game compelling
You're welcome to show me what you made out of it or any of your game jam games. Email me on tituszban@gmail.com, or message me on LinkedIn.