My one resolution for 2017

As always, I had quite a few cool ideas for what I wanted to focus on for 2017.  I considered focusing on making another game for the year, albeit something a bit more realistic than my last attempt.  I also thought about making a software development/game development blog which I’d update every week for the year.  And I also thought about spending a year trying to learn a new language, something I’ve been wanting to do on and off for a few years now.  In the end, I had to take a step back and think about another important skill that I absolutely dread learning, wouldn’t enjoy doing at all, but will be important for both my personal and professional life.  Learning to drive.

I did used to take regular lessons about 3 1/2 years back, but it was expensive, time-consuming, and I hated every minute of it.  Unfortunately there’s a lot of companies out there that just won’t consider you for a position unless you’re able and willing to drive.  Along with that there’s also a lot of activities in my personal life where driving would be a lot more useful (although mostly it would be acting as the designated driver).  Personally I prefer cycling everywhere, but this is one of those cases where I have to go against what I want, and focus on what I need to do.  The moment self-driving cars become affordable though, I’ll be making the switch.

The plan

As always, a plan helps for these things.  Last time I never got around to taking my theory test, and that’s what held me back from being able to take my final practical test.  This time around I’m going to be focusing on the theory first before I start spending money on the practical.  Thankfully there’s a lot of guides and information out there on what you need to do for the theory test and I don’t think I’m going to have any trouble with the multiple-choice part.  One thing that is worrying me though is the hazard awareness test, not because I don’t think I’ll spot the hazards, but because the system sounds very intuitive and confusing to use.  I’ll want to find a few examples of this online to use so I don’t end up doing something stupid like clicking too many times and failing instantly.

My plan is to complete this part quickly, late February/early March at the latest.  Then I’ll move on to taking practical lessons again.  I don’t think it’ll take me too long to get back up to speed with the skills I already learned, but it will take me some time to learn all the local routes.  I don’t think it’ll take me the entire year to do this, but the point isn’t to spend a year doing it, but to make sure I complete it within this year.  This is good, because I really don’t want to take my practical test during the autumn and winter, when the roads start getting bad and I’ll be spending a lot of time doing night driving.

One thing about the resolution that helps is posting about it.  I don’t see much reason to turn this into a regular series of posts, but I will be making a few updates along the way as I’m ready to take the different tests, and ultimately pass.

 

My 2016 resolution

Last year I decided that my new year’s resolution would be to read 6 pages of a technical software development book every single day.  While this might not seem like a lot at a glance, it works out at 2,190 pages across the entire year.  So what does that look like in terms of books?  It ends up looking something like this (plus another 100 pages from here).  I did start to dither and fall behind at one point in September when I had to ramp up my skills in a different area on PluralSight, but I managed to catch up in November.

Reading software development books is obviously important, not just for the obvious reason of furthering your knowledge, but also to reiterate the basics that are drilled into you early on that you often wander from as you go through your career.  Along with all the new techniques I learned there were also a lot of older ones that I’d somehow forgotten about.  I’ve read that if you’re reading even one book a year in the computing field then you’re already reading more than the majority of the people in your industry, and honestly I find that thought horrifying.  Expecting everyone to know and fully understand every single aspect of programming theory is unrealistic but if you’re not trying to build up your skills regularly then they’ll only begin to stagnate over time.

One thing I didn’t consider during this year was other avenues such as PluralSight in place of reading.  Having done a lot of both in this year I found both helpful, but neither one can replace the other.  The books I chose tended to cover a larger area, making you aware of a number of different techniques in the field they focus on, without necessarily making you an expert in any individual part of it.  Video tutorials such as PluralSight on the other hand take more a deep-dive approach into a much more narrow area.  In a few hours you can learn a lot about the SOLID principles and how they’re used, but you won’t get the full breadth of knowledge of the Agile process that you’d get from reading Robert C Martin’s book on the process.  As always a good balance of the two is the best approach.

Going forward, I’m still going to regularly read books on the software development process, but probably not 6 pages every day.  Instead I’ll be reading books for what I want to know about in general, then relying on PluralSight to teach and reinforce skills in a single specific area.

 

Ludum Dare 35 – Post-Mortem

This April I took part in Ludum Dare 35, my first ever game jam.  I was fairly apprehensive going into it, all I heard leading up to the event was that more than half the people who enter these jams don’t end up submitting anything before the deadline.  With that in mind my goal for this first jam was just to submit “something”, even if it wasn’t everything I wanted or even a good game.  Long story short, I did manage to submit something, and ended up somewhat happy with the end result.  If you’d like to see the final result, you can check it out here.

So how did I do?  Not too terribly if the final ratings are anything to go by

The ratings are a little hard to understand, although it helps to know that most categories have around 900 entries, except for Humor and Audio which have around 600.  With that in mind you can see that I hit rock bottom for both Audio and Graphics, although I’m fairly happy with how I did in the other categories.  I’m especially please with my Theme ranking, getting into the top 100 in any of them is something to be happy about.

I learnt quite a lot during this game jam, especially mistakes which I’ll be sure not to make again.  I didn’t read the rules properly until a couple of days before the jam started, and didn’t realise that I couldn’t use publicly available, pre-made graphics and audio, which meant I was woefully unprepared for how to create those.  I also messed up uploading my project several times, first by linking to the web version incorrectly, then learning that I’d uploaded the wrong format for the web version, then finally by having the default resolution be too big to display cleanly inside the web game window.  While you could get around this by entering full-screen mode, I’d assigned ESC to bring up the menu in-game, which then threw you back out of full-screen mode.  Every one of those is a mistake I’ll be sure not to make next time.

There’s definitely some things I need to work on before my next jam.  The graphics and audio are a definite must, although I don’t ever expect to be great at them.  I would at least like to get to a point where I can make a game out of something other than primitive shapes, even it still falls firmly into the category of “programmer art”.  Making music is also something I’m never going to be good at, but the rules of the jam allow you to make songs by remixing very basic samples, and it would be nice to learn enough to put together some simple background music.  Basic sound effects I made using Bfxr, but there’s still a lot I don’t know about even that straightforward tool.

The biggest area I found myself struggling with was level design.  I was fine coming up with mechanics and ways to use them, but when it came to spreading them throughout a level I just didn’t know how to lay them out.  You can see this in the game, every new mechanic is introduced fairly quickly and is only used a couple of times.  While this can be nice for a short game it’s not sustainable for anything longer.  I wasn’t expecting to have as much trouble with this area as I did, and I definitely want to spend some more time studying up and practising putting together some more levels.

I would like to fix up some of the bugs and minor issues I had left when I submitted, mostly the physics glitches and a couple of other bits that didn’t feel nice.  I have no plans to take it further at this point, but if anyone’s interested in what I did they can take a look at the source code on my Bitbucket Repo.

 

My one resolution for 2016

For 2016 I will be developing a habit of reading 6 pages of a technical software development book every single day.  6 pages might not seem like a lot, but I want something that’s a realistic goal and easily measurable, and when you do the maths 2,196 pages is quite a few books.  I’m only counting pages of content as pages read, so a new chapter title and humorous image won’t count towards my daily goal.  Nor will I spend several days leisurely reading the contents and index of each book.  My plan is to develop this into a lifelong habit that I’ll continue doing far beyond 2016, but for now I’ll just stick to my daily target until

I’m going to mostly focus on books that are language agnostic, books like Code Complete, and The Mythical Man Month rather than Teach Yourself Objectives in 21 days. I may change my mind for a couple of stand out books such as Jon Skeet’s C# in Depth, but for the most part I’m not short on choices.  Right now my list consists of The Mythical Man Month, The Pragmatic Programmer, Clean Coder, and Code Complete (which I’ve been slowly reading for a few years, but never finished).  After I’m finished with those I’ve got a pretty good list to choose from, and it’s only going to grow as the year goes on.

I considered making a professional software development blog and doing regular posts as part of this too, but then I realised I’d be breaking my original rule of only doing one resolution. I will still make a blog but it won’t be my primary focus.

 

Making a Game – Report 22

What I did

Well, one thing I certainly managed to do was get heavily sidetracked by “researching” other games like XCOM for several weeks.  As you can probably tell, that didn’t end so well, not for this game’s progress or for the people of planet Earth. Some progress was made, but it wasn’t exactly what you’d call stellar.  I read through a number of different articles on basic AI theory, and everything points towards it being as complex a topic as the rest of the game itself.  With that in mind I decided to for something simple which I could get working in the remaining time I have, rather than something more ideal which would be too complicated for now.  While it might not look like much, I did successfully write an A* pathfinder prototype.  I haven’t got any weightings added to the different items on Trello, but that was by far the biggest and most complex one.  From the research I did, I also rewrote the tasks I’d assigned for the movement prototypes as they didn’t quite work with what I knew I’d have to implement.

What I didn’t do

The movement prototype I have only works on a single vertical level.  I need to update it to detect ladders and scan across multiple levels.  Additionally, the movement prototype I have at the moment uses the A* algorithm which finds the best path to a specific point, but what I really need is closer to the Dijsktra algorithm which will find paths to a number of different points and take the one with the highest value.  I also haven’t started on the combat prototype yet, but I suspect it will be significantly easier to do than the movement one.  The tricky part will be deciding where best to move the AI player to take a shot without “cheating” by having them calculate shot percentages ahead of time.

What I will do next time

For my final sprint, I will be updating the movement prototype to work on multiple levels, and have it pick the highest value spot out of those it can reach.  I will then start work on the combat prototype and have it ultimately select the target based on the chance to hit, and whether they would kill it this turn.  I will need to do some weighting based on the amount of remaining health to reduce overkill, so they don’t eagerly take a shot with a 20% chance of hitting which would kill someone with 2 health remaining, instead of shooting the guy with full health and a 90% hit chance.  Then finally I will need to implement all of this into the game itself.  That’s not going to be super easy, so I will need to finish off the other tasks as quickly as possible in order to leave as much time for this as I can.  As I mentioned earlier, this will be the final sprint for this year, and for this game, but I’ll talk more about that closer to the end of the month.

For the final time, you can track my progress for this sprint on my Trello board.