Sunday 24 September 2017

XZ-03: Post-mortem

It's been a while since I've posted anything here! I mostly use Twitter these days for talking about what I'm working on but I figure it's easier to write longer stuff here. Writing anything of any length on Twitter makes it read like the ramblings of a madman. Which it is but that's besides the point.



XZ-03 is finished and you can now download a copy here. I actually finished the initial version about a month ago, but I've been going back to it every now and again for the past few weeks to tweak and balance a couple things in relation to feedback. I've also added a couple of features, mostly backend stuff to smoothen the experience out but I've also gone ahead and added a stat tracker so you can see fun things like the amount of enemy aliens you've slain, bullets fired and time played! I love things like this in games so I had to go ahead and add it. I also vastly improved the look of the UI with only a few simple boxes. There maybe an update or two coming during the next month if any bugs or other issues arise but at this point XZ-03 is officially a finished project. My first in Unity! The project itself was really enjoyable and challenging to work on & I'm so glad I decided to put in the extra energy to finish it. That said I am burntout as all hell and will probably be taking a week or so off from gamedev to just chill. Well chill and look for work. Which is like the opposite of chilling.

Also of note is my entry into Ludum Dare #39. For those that don't know Ludum Dare or LDJAM is a sort of challenge/competition where participants are given a theme and 2-3 days to make a game from scratch. While I've entered a couple of these in the past I've never put much work into it but this time around I decided to give it a real try. The result was a short platformer game called "Delivery To The Underpass" which you can give a try here! It actually did really well and helped a lot with XZ-03's process as it worked as a fun playground to test out Unity's post-processing effects and audio functionality.

As the Mood category was one of my main targets I was incredibly happy with the result.
Graphics is another big one for me as well, as I am not an artist in any sense
so to nail a high mark like that is a good sign I'm improving!
Placements are out of 1361 jam entries.

But now back to XZ-03, and why I made it.

The Goal:

I started this project with the goal to make a game covering many various mechanical techniques and bits of functionality that I hadn't used in Unity before or at all. Things like: more complex AI spawning & functionality, randomisation of various elements and locations (object spawning), object pooling, weapon selection, pausing, UI menus, turret building (a big one for me as I love Tower Defence games), volume options and many other little things. In addition I wanted to put additional effort into 'game feel' and graphical/post-processing effects to make a game that plays and looks just right, as poor graphics and a lack of what I've taken to calling "Gameplay je ne sais quoi" have been common elements in past projects. All in all my goal was to use this short project as a jumping off point for Unity. Learn how to use the engine proper, get some stuff in place I can use for future projects & even get some experience I can put to use for an actual job!

So. What went well?

What went well:

For the most part I achieved everything I set out to do. And more. I managed to make massive progress with the programming side of things. I wrote a bunch of scripts to handle various useful bits of functionality that can easily be transferred into other projects. For example, I wrote a neat ass daylight script that effectively handles light intensity (brightness) based on ANY length of time (effectively emulating a day/night cycle) & a reusable object that can control the audio in my projects and link to simple volume settings. The former while not reusable among many projects, the mathematical functions themselves (which use a percentage to affect variables between 0 and any other number) can, and will be used again. The latter however is something that I will most certainly be building upon in future projects as I am a huge fan of audio as a dynamic component in games & would love to work more with such concepts in future games.

I also got around to learning and in some cases better using other programming techniques & features of Unity. For one, I finally got around to learning object pooling. For those that don't know, object pooling is a way of handling the creation and destruction of objects (sometimes many 1000's of objects) by creating them all at the beginning of a level and deactivating them. Then, during gameplay, if an object, let's say a bullet, needs bringing into the game, this collection of pre-created bullets is searched through for one that is currently deactivated. It is then activated, given some properties (direction fired, bullet speed, damage, etc.) and let loose. Upon hitting an enemy or wall instead of being destroyed it is instead simply deactivated. and thus available to be "pulled" again. It seems long winded, especially as creating (Instantiating) and destroying objects is so simple & readily built into Unity. Problem is it's also REALLY intensive and thus a game with lots of bullets, enemies and pickups (kinda like this one) slows down terribly. This system allows me to have games full to the brim with stuff & things, with minimal worry about in-game slowdown. That said it does increase the initial load time of a level so it's not a "silver bullet" by any means!

Creating a bunch of bullets (400), giving them a basic name, deactivating each one,
then adding it to a list for later use.

Searching through the list of bullets until one is found that is deactivated.
We then pass this bullet object to wherever it needs to be used!

We take the bullet that was passed  through (if one was found!) and
give a bunch of info for it to use. A direction, rotation & speed for movement.
Various stats for mechanical effects. Then it's activated and sent on it's way.

Another thing I tried for the first time was some element of random-generation. It's something I've surprisingly not gone near before. I say surprisingly because it can be a really effective way to build games like roguelikes & dungeon crawlers and other types of explorative games. Some of which are my favourite games! It also saves a lot of time on level design, although that time is passed into developing the random-gen so... not always the best solution. All in all I made a compromise with building the level manually but placing elements, mainly crates & escape pod parts, in randomly chosen locations. To me this gave the game enough randomisation that players wouldn't always go to the same few points of interest to beat the game but not so much randomisation that they could still learn where the various points of interest were on the map. This meant they could still find where in the crater they were, which was especially important as I chose not to add any sort of map (only a short-range compass) in-game. The code itself actually works by searching through a list of placeholder objects placed around the map, picking one at random, spawning a crate or part at it's location and removing it from the list. Once enough of each type of object has been spawned it destroys any remaining placeholders to leave only "randomly" placed objects. While it's not much this is just the start, and I definitely plan on working more on this sorta thing in the future.

On the graphical side of things, this was the first game I've truly put some forethought into graphics, and use of graphical design principles I know about, but have yet to properly implement. Examples include: using graphics as elements to aid player decision (light components on defences to show range), use of graphics to set mood, specifically increasing tension (growing dust storms and particles in ratio to difficulty increase & to affect players ability to see), thematic effects and overall style (using a limited palette but using post-processing to apply a red tint & other effects to the game, giving it a more distinct look).

During day the red tint is low. At day one the dust storm has yet to arrive...

At night the red tint is much stronger and by day 21 the storm is here!

I put a lot of effort into the graphics themselves as well. It's the first time I've even attempted any sort of perspective before and while it shows in a few places some look pretty damn good. I made vast improvements on shading in pixel art and thanks to Aesprite I started to get a handle on some animation as well. By no means is it anything special but it is still a massive improvement over what I used to draw.

A Mining Droid. Somewhat suggestive but nicely animated.

The Mechanic Turret (Terrible Name).
Perspective is a bit wonky on this one but it still looks great in-game.

HIGH QUALITY TWO FRAME ANIMATION!

As concentrating on game feel was a big part of this project I'm super glad with how it turned out. Putting the effort into making the camera movement feel smooth and adding an effective and variable screen-shake system (I can edit both how strong and how long I want the shake to last whenever I want) made a huge difference to the quality of the game. It's an especially good accomplishment as I've written the scripts in a way that I can easily use them again in later projects. Hell, I used the same camera script in my LDJAM entry, albeit with changes on the camera movement from following the players mouse to shifting between positions based on player input. I also made sure to follow other simpler game feel principles, big ol' bullets, bassy sound effects & hordes of enemies. It really made a big difference to the overall outcome of the game and it is something I'm going to keep in mind for future projects. I highly recommend anyone wanting to look into improving the 'feel' of their game to check out this video, as it's made a big difference for me!



Of course not everything goes great when making a game, in fact most of it goes wrong most of the time, but that's all part of the process! While I was able to solve most of the problems I wasn't able to solve them all. On top of that there are some other aspects of making game I struggled with during this project...

What went wrong (and how I learnt from it):

Let's start with game issues first, yeah. So while I covered a veritable multitude of techniques and mechanical methods and other stuff I still wasn't able to get everything I had originally planned into the game. Now this is common. There is a term in most development disciplines called scope. Scope is a definition of the boundaries of the project. It's a way of making sure that a small project doesn't keep having features added to it. In software this could be a list of features and functionality that the product should grant to a user. Perhaps your software can do X & Y but Z would be a step too far. Z might take more time to develop, rely on X & Y already being built and working near bug free, be too expensive or be otherwise not of interest to your target demographic. While XZ-03 had a big ol' list of things I'd personally like to add to it, adding these mechanics and features would've added too much time onto the project without additional help.

Trello list of ideas. Some fully implemented,
some half implemented. Co-op was off the books
as soon as it became a 1 man project.

All in all though, most of the important stuff was there. Bar any multiplayer functionality (which would've made the dev process & game much different) everything else was just increased complexity. It would've added to the games quality, if done well, but could've still been a mistake to add. We'll just never know.

So what of the stuff I did put in? Any issues there?

Short answer. Yes.

Long answer...

Even now, post final update, enemies will still occasionally botch their path-finding. I'm not one hundred percent what causes this, but enemies will just sometimes glitch out and get stuck in their current location. I've tried various things to no avail. It's nothing major though as it's an incredibly rare event (both when it appears and how many enemies it effects). It also doesn't affect more than 2 or so enemies at a time across the whole map (out of a max of 200 enemies) so it's also unlikely to be seen if it even does occur, but I know it's there and it bothers me. Apart from that the path-finding is actually really good. I actually went ahead and bought a 2D path-finding asset from the Unity store because at the time I was aiming for a 3 month deadline. Which I hit! The scripts and other assets can be found here, and despite the issue that I've had it is a fantastic tool and I still recommend it. It's simple to implement and works very, very well in simpler circumstances. Bear in mind I've got 200 enemies trying to path-find at the same time. I'm not surprised some issues occur.

Speaking of code. As this was a learning project a lot of my code started out, how should I put it, absolute garbage? While I can program well, ofttimes really well (I have a degree y'know!), but I am prone to taking shortcuts. While this isn't a massive problem in a really small game (like a game jam game) or as part of a prototype, I do pride myself on writing code that is robust and easily reusable. Not long nasty nests of if statements or code that works now and then but only if it's a blue moon and I've completed at least two different rituals for each of the elder gods. Buuut sometimes I'd get lazy. Well it's not just that. My inexperience with Unity led to writing single scripts for each object. This is not good. In an ideal world you'd probably have a script to handle the players movement, something simple that would take in players key presses for W,A,S,D or the arrow keys and apply the correct movement. A different script to handle the players health mechanics, increasing/decreasing as required and setting up anything important such as the player hitting 0 hit-points and triggering a game over screen. Another script to handle... you get the point. NOT IN XZ-03 THOUGH. Nah screw that, I'll just have 1 script for each object that handles EVERYTHING to do with it. This is bad for so many reasons, I'll just list them quick.

-It's harder to find bugs
-Scripts become less reusable
-You end up re-writing code between scripts because you don't have basic mechanics segmented
-It's harder to understand when you come back to it later (this is big if you're solo dev)
-It's harder for others to find where the working parts for certain elements are (this is big if you're not solo dev)
-Other issues probably

The code shown isn't what's important here, but it's far too many lines.
In larger projects I'm sure that 650 lines isn't much for a player character
but for a smaller project like this, it's too messy to deal with.
This script handles movement, health, inventory and too many other
elements.

Now. This isn't the worst crime ever and in some cases a larger script that handles a bunch o' stuff is better. I tend to create a handful of "controller" objects for a game this size that manage the user interfaces, enemy spawning & control at a higher level and higher level game mechanics (level transitions, object collection, etc.). But I went a bit overboard in places and that has to stop. It's made updating mechanics & bug fixing much more difficult than it needs to be, to the point that I've put off or ignored known issues (never anything too serious mind you) for the sake of my own sanity. I've learnt my lesson not to push it though, that's for certain.

So the GUI controller handles a lot yeah. That's a lot of UI elements to handle
in one place. I hate this script. Issues with it are the worst to find.

Boy did this game have some weird graphical issues. Chalk it up to inexperience working with particle effects, lighting & the like. To be fair most are rare & unnoticeable. Hell, a lot I've been able to fix pretty well, but it's really shown me how hard some aspects of game dev are for me. I'm good at designing and implementing gameplay mechanics for games but graphical effects can be really difficult. That said I did manage to get a decent day/night cycle working using Unity's lighting effects and some percentages, but there were many problems getting this set up.

The slightly convoluted day/night cycle. To sum it up, it splits up
a full 24 hour day into 4 parts. Morning -> Midday, Midday -> Evening,
Evening -> Midnight, Midnight -> Morning. Based on which part of the
day it is a different function sets the brightness based on how much time has passed.

As I mention above, while it is a little convoluted I wanted to build a system that could handle any maximum light intensity and length of time. For reference it uses a percentage of time remaining (1.0 to 0.0) and uses that percentage to calculate how bright the light should be out of the maximum. This actually went through many iterations to reach this point. Initially the max intensity was 1.0 meaning I could use the time remaining percentage DIRECTLY. While useful this had to be changed when the game felt too bright at that high an intensity and thus more complex functionality was born. It took far too long to implement though and other issues arose due to the time percentage being calculated after the daylight meaning that the first/second half of day switches wouldn't hit correctly and the game would light up like the Blackpool Illuminations. So pay attention to the run order of your scripts kiddos. It can save you a lot of pain in the long run!

Let's not forget about the music. While I did leave time to compose multiple songs (5 total + 1 variant) I really should've spent more time making sure they were just that little bit better. Out of the 6 I'm honestly only happy with 2, 3 at a push. The others were not far off though. If I had decided to spend more time on them the music would've been much better overall though. That said I did enjoy the challenge of trying to write music for a more atmospheric purpose and feel I did a good job at the day themes. The night themes feel, out of place? I dunno quite how to put it, but trying to balance an atmospheric tone with the intensity of EVERYTHING ON THE MAP wanting to eat your tasty flesh was difficult and I don't feel I nailed it quite right. In the update I do slightly alter the music to better fit this (mainly a slight BPM boost helped) but it's still not perfect. But hey nothing is, and it's not bad. Just not good enough damnit.

Maybe, just maybe, I should tell more people that I'm making a game. I've always been a bit resentful towards self-advertisement of projects I work on. Call it an anxiety related issue. The reality of the matter is that while I've yet to make anything groundbreaking I do good work and can share a lot of what I do know with other folk. At the very least I know there are people like me, who would like the games I make as I have, for the most part, always followed the rule: "Make what you'd like to play". I enjoy most of the games I've made, whether for one part of it or as a whole and I know others have too. It's more a case of I need to get the word out and find the market that would enjoy what I make and, at least in part, cater a little more towards them. It'd help with getting more people playing what I make, which in turn will help me in countless other ways, but most importantly I just want people to have fun with the stuff I make. I do sometimes have moments where on Twitter I'll post multiple times a day for a week or so but I'm quite inconsistent. I used to use this blog (almost) weekly as well but that fell by the wayside a while back. All in all I need to be a little more proactive with showing off what I've been making because it's a hugely important part of any sort of creative endeavour that I ignore too much.

Lastly, I somehow still managed to burnout on a 3 month learning project. I say somehow but the reality of the matter is that work of any length can be demanding if you let it be. As a bit of a perfectionist and someone who suffers, sometimes badly, from anxiety and depression any sort of work that requires deadline, especially personal creative work is a burden. It is difficult as f*ck to make something, and even harder to go ahead and share that with people. While it may not have been the healthiest choice for someone of my "disposition" to go ahead and stress the hell out of themselves to make a game using many concepts & techniques new to themselves I'm still bloody glad I did. I've learnt loads, improved my process and garnered valuable experience. I've just gotta get better at working effectively. 12+ hour development marathons day after day until exhaustion is not the way to do it. I know this now.

So what's next?

If you follow me on Twitter (and you should) you know that for the last month or so my main goal has been to study various other aspects of Unity development and to start a few small prototypes to give myself some "tools" to work with for future projects. I've covered the basics of generating meshes & grids, shaders and proper animation. I'm also gonna start work on a small game called One's Black Dog at some point, so y'know, keep an eye out for that! It'll be an extension of working on narrative stuff (as my LDJAM entry went so well) as well as trying, as always, to learn new stuff. I'm going to keep putting working into graphical polish as well, as I've been enjoying seeing my games go from low-end programmer art to mid-level programmer art. It is truly an accomplishment...

Also I'm looking for a job! Mainly looking for work in the Sheffield area but I'm fine with moving further afield if I have to. I'd love to get something in game development (in case you haven't worked that out yet) but I'm fine to keep it as a hobby and getting work in developing software in general. Either way I'll be happy to get an opportunity to work with other people. I work far better in groups than alone, and while the idea of a job is kinda terrifying to me it's kinda exciting too. I look forward to moving towards bigger and better things.

Lastly I just wanna show you something.

This is what XZ-03 looked like on the first day of development.

And here it is 4-ish months later.

So, no matter what anyone says, always be proud of what you've done. I am! Learn from your mistakes and criticisms & know that with time and effort you have the capacity to make anything you want. Have fun with it. It's yours, and you have a right to be proud of it.

-Beau

Monday 7 March 2016

I'M NOT DEAD!

So I haven't been very active recently for a number of reasons, which I don't really want or need to get into. Mostly I've just been "not up to it". That all said, it's a new month and that means a new Game A Month. Kinda. I'm still learning Unity, in-fact I'm quite far behind where I was to be at this point, but I'm still working on it. There will be a game this month, but it will most certainly be very simple, I'll try to squeeze all the content I can out of whatever it is going to be, but we'll all have to wait and see how this month turns out. I'm feeling positive about it!

So what did I do during February? Not much to be honest. The website I was supposed to build didn't get off the ground. Between the both of us being busy we never got a proper idea for it together and communication about the website has hit a standstill (we haven't spoke about it for weeks now). In my personal life I hit a bit of a rut, causing me to basically do nothing productive. That said I did begin learning to make a platform game in Game Maker and began learning Unity 5 by following this guys tutorials, on a friends recommendation:


Dude's named Jimmy Vegas and I quite like his teaching style. Check him out here if you are interested.

Honestly, that's all I wanted to get across today. I'm alive, feeling better & still working on game dev. Hopefully by next week I'll have something cool to show you!

-Beau

twitter.com/Bocodillo

Tuesday 2 February 2016

Continuing into February

I finished a game yesterday! Go here, give it a try & tell me what you think!


What a beautiful intro screen.


NOT THE BEES!


This level is actually quite difficult. Aim for the turrets!


What's this rising from the bottom of the screen...


Super bonus ultra hard wave!

Now onto my plans for February.

Firstly I'm building a website for someone (my boss specifically) which will be fun but difficult as I haven't done any web dev since uni. It's paid work though, which is great and means it definitely takes top priority. This brings me onto point two.

There will be no official game of the month for February. Between the website building, more time at work (we've got a busy month ahead) & wanting to do some other things, which I'll cover in a moment I'm going to be too busy to guarantee that I'll produce a full game worth a month of work. That doesn't mean I wont release anything, just I'm not counting it as a proper game a month.

Instead what I'll be doing is spending time learning Unity some more as well as getting to know physics in game maker. Why? Unity is a very powerful environment to develop games and in game make I currently have no idea how to build a platformer or use physics. Both things I'd like to do/use in the future.

That's all today folks and thanks for the support so far!

-Beau

twitter.com/Bocodillo

Friday 22 January 2016

4C Progress: 22nd Jan

I am very happy to say things have been going pretty damn well with this project so far. There is still a decent bit of work to go (which I'll cover below) but so far so good. This week I've added powerups, a fully functioning upgrade system, improved graphics and other HUD elements. Here's a few gifs to treat you eyeballs too:


Collect powerups from your foes!


Look, it's not as shitty looking a rectangle anymore!


Upgrade your powerups to become big and strong!
660 bullets per second for 10 seconds = 6600 bullets!


Upgrades for all!

So what's next? I hear you cry across the cosmos. Firstly I'm going to experiment with two new enemy types (one is a boss!) Whether they'll work or not I dunno. Next is a proper wave system with specific enemies spawning in specific numbers on specific waves. Simple really and the reason I'm testing extra enemies before doing this as I don't want to be rebalancing the game multiple times. Not. Fun. After is sound design (which is pretty self explanatory) and lastly a bit of graphical polish and a couple of simple menus. A lot for 7 days, but definitely doable. So I hope to see you at the end of the week with my first monthly game in hand!

-Beau

Thursday 14 January 2016

4C Progress: 14th Jan

Update time! Development is going a little slower than I'd like but overall I'm still making decent progress. 4C now has three types of enemy and the AI has been vastly improved. The game also has a "wave based system" now as well. While at the moment it's just used as a break between levels (it increments a wave counter that effects the enemies health among other things) it'll soon have an upgrade system built in too allowing the player to upgrade a variety of stats, between levels. Still deciding on whether the player can actively use powerups or will just gain them occasionally during levels. The player will definitely be able to upgrade the strength of them to ridiculous proportions though. I love mad abilities. Other than that, my main goal next week is adding some proper graphics (still gonna be pretty simple but much nicer to look at) and a few sound effects.


Wow, that rectangle...

Otherwise all is well!

-Beau

Thursday 7 January 2016

January's Prototype: 4C

What's this!? A midweek blog? From now on, in order to fit my new working system (which I talk about here), I'll be doing blog posts on the 7th, 14th, 21st, 28th of each month. At least I'll be aiming for that.


Say hello to 4C, at least the first prototype. In case you can't guess from the gif, 4C stands four colours. It's a simple shooter with a mechanic you've probably seen before, change colours to be able to damage specifically coloured enemy ships. Which at the moment have a shockingly stupid AI and just fly towards the ship constantly firing bullets (that's you!). As a prototype it's actually surprisingly fun, especially when the ships get close and panic ensues. If you're looking at the gif and thinking, "Damn that looks bland." you'd definitely be right though. Being a prototype lots of features are to be added of course! Here's the general order of what I'm going to add:

-Improved ship AI: The basic enemy ship will fly around the top of the screen and shoot bullets at you, get hit too much and BOOM, you ded son.

-Multiple enemy ships: I'm thinking three main types. The basic variety as mentioned above, a smaller variety that will spawn in clusters and fly towards the player damaging the them on impact and a battleship class that soaks damage and can fire a lot of bullets. A LOT OF BULLETS. Of course these may suck in practise and I may come up with more, who knows.

-Player abilities/powerups: With the enemies being kitted out the player should be to. Spread shots, fire rate bonuses and the like will be available to the player. How this system works I'm still deciding.

-Levels/Waves: Certain enemies/mechanics I want to introduce over time so I'll be setting up a basic level system. The enemies will become more numerous and stronger as you progress but perhaps you'll get stronger too...

-Sounds & Music: I'm actually going to make a start on the sound design a little earlier than usual. I want this game to have the best sounds and music I've done yet so I'm going to dedicate a lot of time to getting it right. Plus it'll be the first time I'll be writing fast paced songs in a while so it's better I don't rush.

-Tweaks, balancing & everything else: After all that it's a case of tweaking the game to make it as fun as possible. This'll be the bit that takes forever (I'm calling it now) but will ultimately benefit the game the most so it's important.

-Menu & UI: I'm leaving the menus and UI to as late as possible for two main reasons. One I like a minimalist UI anyway so I don't think it will take much time to do (he says), and I also hate making UI elements just to rip them out once the game has been tweaked or altered in some way making certain bits redundant. It's a waste of time on a task I don't like that much anyway.

-Polish: Here's where I spend about two days messing with slight glow effects just to make the bullets look a tiny bit nicer.

And that's the plan, I've three weeks to do as much of this as I can and for once I'm feeling like I'll actually get close to finishing it all (and now I've said that I'm doomed to do fuck all).

-Beau

twitter.com/Bocodillo

Saturday 2 January 2016

A New Year!

So as 2015 has come to a close 2016 begins, it's time for me to reflect on the past year and share my plans for the year ahead! Also I ramble far too much...

Being totally honest I feel the last year for me was kind of a mixed bag. I learnt a lot of stuff but I can't shake the feeling I could have had a much easier time of it. Developing Revolver has taught me a load it's true. I've learnt some indispensable lessons from time management & planning to more of the nitty gritty of game dev, but I feel that should I have not terribly inflated the amount of work for Revolver and kept the scope small I maybe in a better position now. If I'm not getting it across clear I want to say I don't regret working on such a huge project, just that I wish I took the advice I'VE SEEN EVERYWHERE to start small. Seriously I can't say it enough, and this is from personal experience, DO NOT start with a big project. It just tires you out, it will probably not turn out any good and you'll just end up feeling bitter about the whole thing. Let's face it. If you want to develop games or already do it's probably because you enjoy it. The second you stop enjoying it is a moment you should take a step back and work out why. That doesn't mean give up of course just take a breather and work out what's up. It's taken me a whole freaking year to get round to doing that and decided on a much better plan of action (which I'm writing about in the next paragraph bear with me), don't do what I did and just frustrate myself working on something not worth it. Again I feel I must reiterate, I'm not saying, "If it gets difficult, give up and do something different." That's stupid, game dev is difficult, hell life is difficult, don't give up. No what I'm saying is, "If you're on your sixth month of a one month project, that working on makes you feel like you're scaling Mt.Everest with broken legs take a step back and work out what you should/want to be doing. Or something."

ANYWAY.

What's in store for this year. Taking into account all I've said and done the plan for this year is a simple one. I'm going to make one game a month for at least the first six months, hopefully more but we'll see how it goes! It really is a simple as that. Each month I will design and develop a new game, from scratch and release at the end of the month. General plan is first week I will work on ideas, design and attempt some prototypes. Second week will consist of building the main systems, functionality and building a majority of the game. The last week will involve major testing and adding additional stuff, think extra powerups, gamemodes and the like. The third week will be a halfway point between the second and last. If I need extra time to finish the main functionality I can or if I've done with that I can move onto the extra features stuff, or take a break. Whatever is best. "And it really is as simple as that." he says, "It'll be totally the easiest shit." he says. Nah joking aside doing many more, smaller projects is a far better for me and it'll make much more interesting reading for you.

That's that really. Forget everything I said last year and come join me on what will be a much more interesting year of game dev and other stuff too.

Also Happy New Year!

-Beau

twitter.com/Bocodillo