Xerra's Blog

I’ve got so slow in adding to this blog now that I have to do a load of reading old posts and digging through archived threads on Syntax Bomb to remind myself of what I planned to write about. In the last post I closed off stating that there wouldn’t be another Syntax Bomb competition until May, 2022 but it actually all kicked off in February of that year.

The theme for this competition was titled “The six sides of Qube” which someone had randomly suggested and it stuck. The idea being to make a game relating to cubes. I didn’t think it was the best type of challenge but you work with what you get and I was determined to actually get something over the line this time after the failure of my Tapper clone, and Pixel Hell. The theme wasn’t popular and there were only four entries this time, including Qube’s effort, which never counted as a place officially. So what I came up with did come in second but I’d have to admit it wasn’t worth it. More on that later.

With the cube theme in mind I started thinking along the lines of games involving dice and jumped into working together a clever graphical dice handling system with external call handling, so, in theory, I’d be able to re-use the objects in future games if I did something cards, poker or gambling themed again. I spent too long on this and I never felt it was really very good, even though it did work. I was planning to potentially use dice in several mini games as part of the whole game package but hadn’t thought much further than that when I started work.

So originally I planned to create six mini games (six sides of a Qube, yes?) all themed around dice (which are cubes in themselves) therefore easily qualifying for the games theme, and have them all played out on a kind of casino table so I could possibly involve playing cards as well. It’s been three years since I worked on the game so memory is a bit sketchy but I remember dropping the cards part of the game pretty early as I was having problems with the code causing some to disappear due to not getting the core elements right before trying to build the game on them.

It wasn’t going well and the deadline was, as usual, coming quickly, and my poor effort at putting a lot of time in coding sessions every time I worked on it was giving me signals that maybe this wasn’t a project I was feeling but it was too late to drop it, and I didn’t want to abstain from a third competition in a row. I had, at this time, the record for the most submitted games in these competitions, outside of Qube itself, and I really wanted to keep it.

I got the first dice game done, “Drop Dead”, based on an old pub dice game which is played with five dice and requires gaining a higher score then your opponent over five turns, but you have mean penalties such as negating all your dice scores if you get a five or two on any of them. That worked out ok but even I will admit it wasn’t really very exciting.

The second game was “Crown and Anchor” – a much more complicated game involving dice with royal symbols instead of numbers and a token system on the game board. I got this in but it was bugged I discovered later on and would need some fixing to get it to actually play through a round. The competition was long over by the time I discovered this – mainly due to poor testing by me and probably lack of interest in anyone who tried to play it – so I’ve never got back to actually sorting the game out, even though I have bug fixed some other stuff in the project since.

I’d come to almost deadline day when I started work on the third of the six games I was planning to put into the package. Instead of creating another dice game, i found a decent set of words in a royalty free archive and implemented a simple but reasonable Wordle game instead. I was sick of the project by this time but, fortunately, I had done all the front end work I was going to need already as I had wanted to use the dice stuff for the title screen attract mode system.

So that was the end of that. Some parts of the project I do still quite like, and I’m a bit more positive about “Faces of Qube” now it’s been a few years since I worked on it, but I don’t feel I’d ever want to go back and actually turn it into something on the same level as some of my better games.

As it was, it ended up being the only game I’d complete for 2021, so at least it was more constructive than 2020, where I’d failed on everything.

In 2022 there was also only one game competition during the year and I did start work on a kind of Fort Apocalypse game with a helicopter, lots of aliens, unlocking doors, multiple hazards including flooding tunnels and stuff like that. As the theme of the competition was “It’s all about YOU!” I was creating it with a story of a mercenary using his helicopter to rob a wealthy persons cave system where all his treasure was stored with heavy security. That’s why I came up with the snappy title “Swag!”

The game was coming along ok, but I kept messing with graphic sets trying to create the large map area I wanted, when I probably should have just tried to keep it simple. I also spent too much time playing with particle effects and getting the “right” control system so the inevitable deadline came up on me before I could even have a basic map in place, and develop some of the more involved hazards.

So that was the end of 2022 for a completed game as well. I had a couple of small games I’d been tinkering with based on Vic 20 games I had wanted to remake but neither of them were close to finishing that year.

In 2023 things would get better and, whilst I still only completed one game that year, it was another competition game, and I think it was probably my best game to date. More on that in part five.

Share your thoughts

In my previous post about Syntax Bomb game coding competitions (Part Two) I left off just after mid 2020, where I had finished Validius. The next competition came around October of that year, and had the theme “Go Nuts!”

I submitted Tommy Gunn for that competition, and, as I already wrote a development post about that game, I’ll move forward into 2021, which actually turned out to be a very poor year for productivity, on my part.

Post Covid, around Easter 2021, I moved to Devon from the hell of outer London, as I was now working from home pretty much all the time, and felt the odd commute day would be manageable enough to not change jobs. I still had more time to work on my games than I’d been used to, prior to the pandemic, so I was hoping to get back to possibly making at least three games this year. The first competition was announced in the April of 2021, and the theme would be “Virus”

Obviously, you weren’t actually supposed to write a virus itself, but rather a game themed about a virus outbreak of some kind that you had to deal with. An interesting idea and I had come up with a game plan pretty quickly of what I planned to do.

Again, I looked back at the Vic 20 for some inspiration, and remembered that Jetpac was a fun game that took up a lot of my time when I first got a 16k expansion for my computer, so I could actually load it. As usual, I tend to think of the kind of game I want to make and then try to fit the theme around that, so I came up with the idea of keeping the same player bouncing around platforms, picking up fuel and ship parts, and blast nasty virus types instead of just your regular aliens.

I had some assets from a few years previous of different germ types and planned to use all of them other progressive levels and have different styles of planet backdrops to play over, possibly using our solar system as the influence, like I did with Creepy Crawlies. I didn’t go the route of engaging an artist as I was just hoping to google and find some free, usable stuff instead for this. I never got beyond the first two test backgrounds anyway with the game itself as it became clear, after a few weeks work, that the game wasn’t working out.

I called the game Genome, and had Carl remix a great version of the old horror theme from the movie Phantasm. I didn’t mess around doing presentation stuff, and just jumped straight into coding the gameplay first and, if I’m realistic, that was mostly complete. I had jetman flying about pretty well, and that wonderful laser shooting effect that the game had, as well as implementing the ship building and fuel loading part that would break up the mindless shooting. However, once I put in the first aliens, and got the player shooting them (somewhat crudely) then I realised that Jetpac had been a great game that had enthralled the eighties kids back then, but there wasn’t enough of a game to stand up now.

By this time I was down to a week or so left so what I probably should have done is cracked on and finished putting the virus’ enemies in, and hopefully come up with an idea or two to make the game a bit more. I didn’t, though, and just pulled out of the competition instead. I believe that was the first one I hadn’t entered since I gave up working on RAM, due to time constraints.

Apart from a bit of intermittent work on improving my game framework ready for future projects, I didn’t actually work on another game until the next competition idea forum thread came up, and I suggested that it could be an interesting challenge for us to try making a one-button game. That idea was agreed upon, and became the Syntax Bomb coding competition 13 – “There can only be One”

By now it was November, and I hadn’t even completed a game in 2021, so I was determined to get at least one on the board before the years end, so I gave this one some thought and then probably jumped in too quickly on my first idea.

Tapper was originally an arcade game that came out on various other computers of the time later on. It’s basically a game where you have four bars to attend, and need to keep the customers on each bar happy, while they slowly walk up towards the end of the bar. This involves facing right to pour a beer and then facing left and moving up and down to select which bar you’re going to slide your drink along. When said drink is caught by a customer then they are pushed back a bit. If they get pushed off-screen then they will disappear. The idea being to serve all your customers within the time limit and not have any make it to the end of the bar. If they do then they’ll grab you and slide you along the bar and into the wall instead, losing you a life.

I prototyped this game with some really crummy assets and worked for too long trying to implement a decent way of controlling the action when the player is only allowed to use one button. It turned out really hard because I had to put a visual indicator on how long the button had been pressed, so the player had some idea that the action he was trying to accomplish would happen. I had to have a short press fill up the beer from a tap in one motion, and then turn back to the bar again. Another short press would send the beer down that table and, if you held the button down for a bit longer, then you would move down a bar so you could work on the customers there. It became clumsy having only one tap at the top bar, so I made it so you could refill at any of the bars to make it a bit easier.

I had Aaron testing all this as I developed the player control system, trying to get something that both of us would be happy with. After three weeks of tinkering with some other bits, such as the customer movement patterns, while Aaron tested the control system, he was absolutely convinced that I had picked badly and should rethink the game idea while i still had time.,

It took me another week before I had to reluctantly agree with him, so I had, by now, lost almost half of the development time for the competition, and was back to square one. One Button Barman, as i’d tentatively christened it, was history.

I wasn’t ready to give up on yet another competition at this stage, though, so I still had a bit of digging around looking at other one button games to see if I could get some inspiration.

I then went back to the very basic ideas of the early consoles and remembered a game I’d played on an old pre-Atari console that I’d been given around 1981, after it had been up in someones loft for a long time. This was a game that involved pressing fire to accelerate your motorbike to move across the screen and – because it was a one screen game, as i don’t think these consoles could do anything technical like scroll – it would then reappear a bit lower down the screen at the left side again so you could accelerate a bit further. The third section of the screen had the jump you had to clear, like in the days of Evil Kenievel (spelling), over multiple buses, and land on the ramp the other side. I’m pretty sure these games just randomised if you made the jump or not, as it was always 50/50 if max speed made any difference or not.

This game just required one button to accelerate the bike, or letting go of the button to brake, or slow down. However, i didn’t want to remake that game – just use the three sections of the screen in a similar way, as it would mean you could negate a level without using any scrolling. I deliberately went with this idea as i thought it would be a good idea to compliment how tricky using one button to control a game was going to end up, because at least a player could work out how to play the level if I let them see it all before they pressed fire to start moving. Having three play sections meant possibly being able to implement some interesting hazards and small graphics meant the levels could be bigger as a result.

I was leaning towards the platform game again, by this time, and had just dug up a lot of free hell backdrop images that I could lay out randomly behind each tile based level. At this time Aaron was working on a platform game himself that would have the player constantly moving but would have areas where his player could move back and forth without encountering a hazard. This allowed the player could work out their next moves, and the only thing the one button needed to do was control the height of the jump you needed to do. I wanted to do this as well as nobody likes a game that’s too hard.

As usual the player control system was the first thing to start laying down and I think I actually got this working pretty well because I’d given a lot more thought to the game than I really had time to do, and it was working. I got a level system in place and some test levels to put the elements in and make sure they worked ok, like the traps and trampolines. I even got some of the background stuff in place so the game was mostly in place apart from just not having the levels and enough traps/boosters and other random things to make it interesting, and give the player the odd surprise. I was aiming for 20 levels and only had 5 of them set up, and they were just full of testing stuff. I’d yet to actually get even one proper actual game level in place when I got the dreaded less than a week to go.

I’d like to think that, if I’d abandoned my tapper idea earlier on, like probably after a week, then I’d have got Pixel Hell over the line. It was going well until I had to admit defeat on the deadline. I know I had other stuff going on at the same time which was also slowing me down, but it’s always frustrating when you don’t finish something you’re working on. I’ve always said that I like the deadline that game competitions and jams give me, as it focuses me to get on with it and finish what I started, but it doesn’t always work out. Maybe I’ll go back to it one day and actually finish the game but it’s more likely I wont.

On a side-note, there were Eleven entries for this competition and Aaron’s game “Dexter” won it. Well deserved too, as it ended up easily the best entry of the competition by far.

So, in the end, 2021 ended up a complete washout for making games, for me. I had a couple of projects that I could have gone and finished to just at least get one done for the year, but i didn’t. There wouldn’t be another game competition until May 2022, either. More on that in part four.

Share your thoughts