Coding, gaming, and Dara O'Briain

I had the pleasure of going to the Cheltenham Science Festival today to listen to Dara O'Briain talk about coding, gaming, and neuroscience. It was brilliant, and nerdy, and interesting, and informative, and all the other good things one of these things should be.

The session was called Coding the Game, and also featured Alex McLean, Chris Cummings, and Luke Clark. Though it was only an hour long, it covered an awful lot of territory. The topic for most of the first half of the session was purely programming. They talked about how many programmers they used in one of their games, how the hundreds of thousands of lines of code are divided up and then put back together, and how you can follow all the rules of good coding right up until a few weeks before release - and then you're breaking every programming rule in the book just to get the game out and working on time!

The second half of the session looked at neuroscience, and how the brain responds to playing games. This was where I found myself only vaguely aware of the things talked about. Risk and reward systems in games I understand, but how those specifically relate to the dopamine effect was completely new to me. There was some very interesting info here, particularly on how the dopamine effect is just as present when a player nearly fails as it is when they simply succeed. It made me realise that, as a player, I feel a greater sense of achievement when I succeed after nearly failing then I do when I simply win. This is, in turn, something I feel like I could include in my own games quite frequently - but not so frequently that playing the game becomes to tense to continue!

In the last bit of the session, there were some questions which led to a variety of different topics being very briefly touched on. There was talk of women and gaming (which was very well handled, in my opinion), PS4 versus X-Box One, Raspberry Pi, getting into the industry without qualifications, fractals in game development (that one kinda went over my head), and so on. There were several other things discussed, but I can't remember them all off the top of my head.

While some of what I heard I already had guessed at, or already knew, there was a lot that I didn't. I came out of the session feeling more positive about game development in general, and my own hope of eventually working in this industry as well. And I got to hear Dara pop a few well-timed jokes as well. Major win for me!

Making games with SLUDGE

Yep. There is actually something out there in the world called SLUDGE that has been created for making games. Adventure games, to be specific. I've been having a look at what it can do, and I'm intrigued.

Firstly, it's multi-platform, both for running games and for using the editor. It looks like it's got some relatively simple system requirements, so I should be able to use it with any of my computers or devices. (Not so sure about iOS, but hey, nothing's perfect!) It also looks like all the game logic, as well as a great deal of the lower-level stuff, is coded, rather than a drag-and-drop interface. This to me actually feels like a benefit, as the language features are easy to understand and use, and it gives the creator far more control over what everything does. Plus it will strengthen my ability to code quickly and efficiently if I have to do it for everything.

But, of course, I've never used it before. And while the temptation to download it right this very minute and start playing with it is very strong, I'm resisting. (I'm in the process of re-learning my C# skills, and don't really want to distract myself from it with Ooooh shiny!) So, instead of diving head-first, I'm going to ask: do any of my developer friends have any experience with this one? Has anyone tried it, and what did you think? Enquiring minds and all that.

The New Boston

Just a short post today, as I'm recovering from being poorly the last 24 hours.

Recently I stumbled across a website I had never seen, or even heard of, before. I don't know how I missed it, and quite honestly I wish I'd seen it a lot sooner! It's called The New Boston. It's an absolute treasure trove of information for anyone who wants to learn programming, web development, game development, the list goes on.

Thing is, it's not just computer stuff you can find there. There are sections for education-focused stuff (algebra, chemistry, etc.), game playthroughs, how to build a go-kart (yeah, dangerous one for me there!), even survival in the wilderness. All of these are presented as video tutorials. You have to forgive the early videos for their sound quality, but the stuff you get out of the videos more than makes up for it. Go check it out and learn something. Really.

Too many engines!

There are a lot of game developers out there that insist that there is no point in reinventing the wheel. In other words, when making a game, if there's an engine that makes the work easier, use it. You don't have to build your engine from scratch.

And I agree with that, wholeheartedly. If there is an engine that works for the games I want to make, I use it. The problem, of course, comes in when you have to try to decide what engine to use.

You see, there are literally dozens of game engines out there. They range from the small and rather useless to the huge, professional examples of game middleware. They also range in price from free to very expensive. There are plenty of engines that fall somewhere in between, and a fair few that have made my short list for potential engines for several things.

So how does one choose? 2D or 3D? What platforms does the IDE run on, if it has one at all? What scripting language does it use? What platforms can it create games for? What is the license like if I decide to take things commercial? What kind of support is there for learning how to use it? Is it accessible for someone who does not have much experience making full games?

It's a lot to take in, and I'm still wavering. Hopefully I'll come to a decision sometime this year.

Coding on paper

(I have no proper introduction to this post, so please insert a perfectly clever and enticing post opening here.)

I'm loving C#! (For non-programmers, C# is a programming language. If that doesn't float your boat, this post will be a bit more nonsensical than usual.) It's proving to be an easy language to learn so far, for the most part. What basics I know about general programming logic (variables, loops, input/output, methods, etc.) is proving to be a great help with getting me through the book I'm using to learn. I'm working my way through Rob Miles' C# Yellow Book 2011, and I think the only thing so far I really don't get is try/catch stuff.*

I'm using Visual Express c~ 2010 for my programming, and also mostly enjoying using it. The Intellisense actually really, really irritates me. For whatever reason, it keeps thinking if I type "i", I really mean "if". But you know what? Using "if" in a "for" loop really causes problems. So I turned it off. SO much easier now.

But, I've noticed it's a bit difficult to sit down to a blank screen and just write a program, even if I know exactly what I want it to do. A few days ago, I sat down and decided to write a mad lib. I was able to hash something together on the screen, but the coding was downright messy. It wasn't organised well, and I didn't make use of the many other things I had at my disposal to do it right. Largely, I imagine, because I expected to be able to just rough it up quickly, like I do a rough draft of a novel.

However, like when I write fiction, I found it much easier to write in on paper. I was able to first write down all the stuff (variables) I needed, then what I needed that stuff to do (methods). Looking at it written down on a piece of paper like a recipe was so much easier. I was able to sit and recode my mad lib from scratch, and as a result it is much more readable and adaptable. I'm quite happy with it, for now. I'm sure I'll find something to add to it later.

Also, I bought a notebook specifically for coding notes and references. Looks like it will become my "program rough draft" notebook, as well.**

*Seriously, it looks like try/catch is only there to catch things you think might cause an error. Surely it's more logical to simply make sure that you're thorough in your coding to make sure such an error doesn't occur? I just plain don't get this, and can't see where I would need to use it.

**As well as lacking a good intro, I'm also lacking a good closing to this post. So, insert a good closing paragraph somewhere. I'm too tired, and I'm going to bed.