So it’s almost been a week since I finished All Ways Down, and seeing as everyone else is doing one :-), I figured I’d do a bit of a postmortem of the game/experience, looking at what went right and what went wrong. Like many who entered, this was my first Ludum Dare, and whilst at times it was stressful( especially the last two hours), in the end it was an amazing 3 days and I had a lot of fun taking part. Overall, I’m very happy with how the game turned out, though there are plenty of things that I think could be improved (more on that at the end). The jam also meant I got to learn a bit about Unity webGL exporter, which up to now I had not really been following.
What went right:
The mechanic: The basic concept started quite simple, ‘a rolling ball that has to be a certain mass to finish a level, it does this by consuming objects and growing. Player can spin the world?’. From this I sketched out what I thought a level would look like with a simple storyboard for play and put some ideas for level hazards underneath. Thankfully I was able to implement this mechanic and it worked.
Thankfully most of the core development went quite smoothly(unless you count Unity crashing twice), with no major issues or bugs.
Sound: This is an area I generally find the hardest, but I’m quite happy with the end result, and have got some positive feedback on it.
Unity webGL, a day before the jam I decided to update unity. In hindsight this could have ended up going very wrong but, in the end it meant I learnt more about unity’s WebGL exporter, deciding from the start that I would use WebGL as my target platform.
What went wrong:
Whilst not wrong per se, based on feedback the ball could be a bit heavier at the start of levels, so that it moves around the level a bit quicker.
Deciding to make 5 more levels 4 hours before the end of the jam, resulting in no playtesting of these levels.
The size of the web player. I would have liked the actual game screen to be the max size allowed on this site, but unfortunately as this was the first time I had used the WebGL exporter I didn’t realise that the export size set in Unity doesn’t include the custom Unity bottom bar, thus cutting off bits of the game screen when its embed size is set at the same size as export. Meanwhile exporting without the Unity bar means you need to provided the functionality that makes it go fullscreen. I really wish I had known all this before the jam, and not learnt it in the last two hours when I was trying to submit😀
I think I’ll be developing this game further post comp. I’d like to make more levels, add in a couple of hazards and puzzle that didn’t make it due to time, along with polishing the graphics and adding more effects, maybe even a camera shake 🙂 . I’d also quite like to port it to mobile as I think its control mechanism is very well suited for the platform.
Overall I’m very happy with end result, and looking forward to working on it a bit more and making it even better 😀
Here’s a collection of the various posts I made during the Ludum Dare jam. Originally I wanted to post these on both the Ludum Dare site and here on the noddingTortoise, but unfortunately I was a little pressed for time over that weekend and never got round to it. So I thought it would be nice to have them all in one post, acting a bit like a timeline, which could show the gradual development and progress made on the game All Ways Down during the Jam.
These were originally posted on the Ludum Dare website between 12/12 and 14/12.
Early Control Test
Started a little later than hoped. So far have tested simple two button control mechanic for a puzzle game where the player controls the direction of gravity by rotating the screen rather than controlling the player directly(the player is the ball).
Very Early Prototype
Very early prototype build of my entry, you can give it a test here, feedback welcomed 🙂
End of Day One
End of the first day, I think I’ve made some good progress. Since the prototype I’ve tightened the controls and tweaked the gravity and mass, making it slightly more responsive, along with scaling the play area down a tad so it all fits on screen. I also started making the levels, so far I’ve finished 6, though I’m not yet entirely sure how many I’m going to make in total 😀
In any case I think now it is time for some sleep 🙂
A Quick Update
Finished the minimum number of levels for submission, decided 15 was a good number to aim for in the end. Which only took a few hours to design(paper and pencil ftw!) and build. If I have time tomorrow I might try and put a few more together but for now 15 will do. Now to find some sound.
Oh, and here’s a particle effect:
Submitted My First LDJam Game – ‘All Ways Down’
Finally finished submitting my entry ‘All Ways Down’. You can check it out here
It was a bit of a rush to submit in the end, I thought I gave myself plenty of time, I finished making the game about 2 and a bit hours before the submission period started. However, I ran into a couple of issues with the unity web player sizing. Thankfully I think I got it all sorted 🙂
Anyhow, the game.
I decided to try and tackle both the themes with my entry, with the game making use of just two button input, with elements of growing as well.
All Ways Down is a puzzle game where you must collect growth pellets in order to increase the size of the ball, which is needed to push a switch to progress to the next level. As the game progresses levels have more pellets(5 is the max), which in turn makes the ball harder to control. The ball is controlled by the player rotating the level either clockwise or anticlockwise, and then letting the always downward force of gravity do the rest, though some skill may be required :-p
The game has a total of 20 levels, I would have liked to have made more but unfortunate I ran out of time in the end. In any case I had a lot of fun making it, and I learnt a few new things along the way.
All Ways Down can be played either on its entry page(best played full screen) or over on itch.io(link on entry page). It’s also available to download, though I haven’t had a chance to really test those builds yet.
Now for the voting… actually, I think now is time for sleep, it’s been a long weekend 😀
It’s been a few weeks since my last post, a busy few weeks, so I thought I would do a quick update on a couple things.
First there was loading jam. This was a bit of a last minute decision to enter, though I’m glad I did. I didn’t hear about the jam until three days before it finished and even then didn’t decided to enter until the next day, which gave me less than 48 hours to make a game based around loading and possibly patents if possible, though totally optional.
You can check out my finished results over on my new itch.io account(pc, mac and linux) which probably deserves a post in itself.
I think the game turned out well, though there are a couple things I’d like to improve based on feedback, such as adding some tutorial text, stopping the mini games from going straight to the main game if you fail, and maybe build a web version.
This brings me to my second game jam of the week/two weeks, Ludum Dare. This was my first Ludum Dare so I decided to take it easy by entering the jam rather than the competition. I was slightly more prepared for this jam, though only slightly. The theme was two button controls and or growing(there was a tie, so two themes were chosen), which seemed somewhat familiar. It was an amazing three days, stressful at times, but still fun! You can check out my entry page for the jam here, or check out the game over on itch.io.
I’ll probably do a recap post, which will included ludum dare posts and screens from various stages during development. And eventually I might do a reflection post on the experience and the finished product(or not so finished???)
Finally, TaOvarg update:
Yes, I have been working on an update to TaOvarg. Unfortunately, progress on the update was slowed by an input bug, however, as soon as I’ve ironed it all out it will be ready for release, and will give TaOvarg full controller support, along with a couple other new things. Joe
It’s been awhile since my last project Mamore, almost two and a half months in fact, but during this time I haven’t just been playing through my Steam back catalogue whilst refreshing the Fallout 4 countdown timer(even though I may have a couple of times), instead I’ve been busy working on my next project. In fact you may have already seen some of the early screenshots and concept art for the game that I’ve been posting over the last month. Now today, I’m happy to officially announce my new project TaO-VARG.
TaO-VARG is a challenging action puzzle game where your goal as the player is to guide a Ballistic Acceleration ellipse(BALL for short) to the goal by using two special gravity particles: Thrusts and Orbits. Further, in order to successfully complete a level, not only must the BALL reach the goal, but it must do so within certain limits, these limits are imposed on the number of respective particles that can be used each level, with three pass marks(bronze, silver and gold) associated with how few(or many) the player uses. If the player reaches the goal but uses too many of a particular particle then they must try again.
In total there are currently 40 levels to beat, with the later levels becoming more and more challenging for the player(though some of the early levels can be a challenge as well). The levels start simple, but as the player progresses through the game they will encounter a variety of obstacles, ranging from turrets to lasers.
The game is currently still in alpha, though it is finished for the most part(I’ll list the things I want to possibly add to the game at the end of this post, along with download links). But the game does need some fine tweaking. This is where I’d like you, the reader, to come in. Unfortunately I’m a bit too familiar with the game(having made it and all), so it’s hard to tell if some levels are a bit too hard. Therefore, I need some more widespread playtesting and feedback on the levels, so that I can put the finishing touches on the game. Basically, I’d like you to just play the game; if you finish it that would be awesome but its not a requirement, and hopefully whether you finish or not you have some fun doing so. And if you want to give me some feedback on the experience that would be awesome too, all constructive criticisms are welcomed.
Below you will find a link to a windows installer along with a standard Unity standalone package.
Been a while since my last post, so I thought I’d post some screenshots of my current project which I’ve been working on over the last month. Still a way to go until it’s finished, so things in these screenshots may change, hopefully for the better 🙂
It’s been just over a week and a half since I finished my last project Mamore. Similar to my previous project, now I’ve had a week to clear my mind, I’ve decided to write a post reflecting on the experience and summing up a couple of the things I have learnt or came across during development.
The idea and design of Mamore was solely the result of the IGM competition. In fact as I mentioned in my last post, it was brainstorming with the idea of growth from which the game was developed. As a result, during the ideas development stage I was very much aware that development of game features was going to be constrained by the limited amount of development time. And that, whilst the competition stated that games did not need to be perfect or necessarily finished for the competition, they had to be finished and/or complete in a playable sense. At times I felt this limiting in terms of creativity, stopping me from going down and trying different avenues. However, I did find that it kept me focused on the core game and gameplay, preventing me from going down rabbit holes that would take time away from areas that needed it. For example, during development I focused on making a minimum viable product (ExtraCredits did a great Youtube video on the subject). This way, if time became constrained I would at least have a playable game. For Mamore, this was staying focused on the enemy block’s AI and the life block logic, the two elements that I felt around which the game was based; in hindsight player movement should have been in this list, but I’ll get to that in a moment. Elements I left until last were the purchasable items, turrets and traps, particle effects, animations and sounds; things I wanted to add to the game but felt weren’t necessary to the core experience.
Physics of Movement
This is something that caught me near the end of the project, in fact on the day I submitted it. Much like in Click ‘n’ PoP where input was key, in Mamore a key element was making sure that movement felt right. Too often I have played a game, this applies to platformers especially, where the players movement just feels off, and for Mamore this is the core gameplay element. Now, I should say that unlike Click ‘n’ PoP which was actually broken, Mamore was not broken, it just didn’t feel exactly how I wanted it to; the player’s movement was just a bit slow and sluggish in nature. It played fine, and performed as it should, it just needed some refinement. And so this is exactly what I did; on the morning I was planning to submit my project I decided to put my head down and spent the whole of the morning playing with various values, tweaking them until the player’s movement felt just right.
In hindsight I should have done this a lot earlier in the development cycle, which would have allowed for further refinement. However, unfortunately that was not the case, though in the future this will definitely be at the forefront of my mind when I start a project.
I feel that this projected helped to highlight that sometimes you need to focus on the core game and try and keep feature creep at bay, as this can consume time you may not have, especially if you have a tight deadline. It also made me realise that you should make sure you have all the base mechanics tuned, at least close to ideal, early in development, so as to allow for more time to fine tune. Overall I probably learnt many more things from this project than just the two listed, some I don’t even realise, but I feel that the above two concepts are things that, after a week and a half, stand out clearly in my mind. Much as I said in my previous post, whilst I realise the game is far from perfect, I am happy with how the game turned out and most of all I enjoyed the process.
Finally you can check my IGMC2015 submission, Mamore, here
A few weeks back, around the time I was finishing off Balloon pop, I was visiting HumbleBundle, if you haven’t heard of this site you should seriously check it out, games + charity = Awesome, to check out their new main bundle, what I found was a bundle dedicated to making games, specifically, a bundle supporting the Indie Games Maker Contest 2015 (IGMC2015).
I wanted to find out more about this contest, and as I didn’t know much about IGMC I decided to investigate further. I headed over to the site and had a quick look through the rules and guidelines. At the time I thought it would be interesting to enter, but felt that I wanted to concentrate on finishing my then current project.
After I finally wrapped up balloon Pop, I started thinking about my next project and what I wanted to do both in scale and type. I wanted my next project to be another simple-ish project but to be slightly larger in scale, a tad more ambitious.
It was then that I remembered the competition and thought it might be an idea to make a game that follows the rules and guidelines, that way if I finish it before the cutoff date, and I think it is good enough, I could enter it into the competition. And so I decided to investigate the competition a bit more. I headed back over to the site and reread the rules and guidelines, making note of the twist growth. At this point the competition had already been running for almost a week, leaving me about three weeks to make a game, which aligned nicely with the amount of time I wanted to dedicate to my next project.
After rereading the rules and guidelines, I started brainstorming ideas for projects that were somewhat simple and incorporated growth. I played around with a couple ideas, including a platformer where you must grow a central beanstalk to reach higher levels, but I felt this would take longer than 3 weeks to make. I wanted something simple both graphically and mechanically but still had some depth, whilst also adhering to the theme of growth. Eventually I settled on an idea where the aim of the game was to protect a central block from a growing number of incoming blocks, and where these incoming blocks could also grow in size. I created a few concepts, settling on a style I liked before starting work on the prototype.
For most of the development from prototype to finished game not much really changed in terms of core gameplay and graphical style. Not to say things didn’t change, in fact as a game starts to flesh out you find somethings just don’t work or could be done differently. For example, initially there was going to be a health bar at the top of the screen to represent the health of the block the player must defend. But early in development I decided I didn’t want the top of the screen obscured, so I came up with the idea to use the block itself to take on the role of the health bar, changing colour as it loses, or gains, energy; along with the introduction of a two stage size increase as the energy drops/rises; I also felt this was a nice nod to growth. But for the most part the core remained the same.
The majority of development time was probably spent on the enemy blocks, as not only do they add variety to the game, but also because I wanted each block to be slightly different. With different characteristics such as speed or its behavior once it got close to the target.
The last thing to really get added, other than last minute particle effects, was the inclusion of turrets and block traps. These were in fact in the initial design outline, but I felt I should leave them until last in case I didn’t have enough time to implement them properly, as the game was still fully playable without them. Thankfully this wasn’t the case however, and I feel they add a nice element of strategy and resource management to the overall feel of the game.
I realise the game is far from perfect, with plenty of areas for improvements, such as difficulty balance and different game types etc, but I feel that it’s a good improvement, even an increment on my last project, and was completed in roughly the same amount of time.
Overall I’m pleased with how the game turned out and glad that I stuck to the time window so that I could enter the competition, and most of all I had a lot of fun making it.