You are here

Right, so how does this start?


I guess at the beginning.

So I am developing a game. My sole motivation for this is that I would probably like to play a game like the one I am making myself. This website will either be a record of my progress, or a testament to my failure. I don't intend to make any money, or do a KickStarter, or have an Early Access project, or have any other delusions of grandeur -- I want to make a fun, free game where you are a tiny robot that blows up other robots with big guns.

I don't have a name for the game yet. Mind Relay is just an umbrella studio name I can slap on this and future projects.

It's not particularly original -- my game is a 2D, side-scrolling arena shooter/platformer, definitely with the obvious modern influences of Super Crate Box and Risk of Rain, and definitely Rogue Legacy to some degree, but really the big gods to me are games like Contra, SmashTV and other old-school action platformers. I really enjoyed how in Risk of Rain enemies had particular attack patterns or gimmicks, and I feel like this could be expanded a little bit. I also like games with lots of big, 2D explosions, lots of bullets and massive bosses, so I've got some mechanics in there that support that, and involve blasting tons of enemies at once with over-the-top weapons. My aim is that moving around the arenas will be very important, as staying in the same place for too long will get you swamped and killed. I seem to draw in a colourful, chunky style most of the time (see logo), so I guess I'm stuck with that sort of feel (as Dick Hogg said, Well, that's just how I fucking draw.). There's even going to be a few light puzzles -- I'm quite happy with how I've found a way to work platformer-style puzzles into an arena shooter, and I think it adds a bit of depth and variety to the levels. I got a bit bored of just staying in the same, static arena the whole time in such games. It's hard to think of a nice way to reconfigure the arena that makes sense, so the most natural thing seems to be to just make the levels bigger. I'm particularly influenced by the way things work in the Gears of War games -- you have a combat scenario, typically in a static area, then some connecting puzzle bits where you have to flip a switch or navigate some obstacle, then the whole thing repeats. I think it's a really nice way of getting the benefits of static combat areas (which can be really interesting), while keeping a sense of progression through the levels which stops things getting stale.

Here's one of my early concepts for a bit of one of the levels, which I expect is set on a sequence of rooftops.

It looks way better now, and I'll be posting some pics of it up in a few days.

So I've set this website up to track my progress. I feel OK doing this now -- I've been working weekends and evenings on/off on the project for about two months now, and recently (this past Sunday morning) had a Eureka moment where I realised I'd passed through the majority of the technical slog I expected to have to deal with. I have a playable, one-level alpha with most of the mechanics good to go and about 80% of the art done, and this made me feel very motivated, as if things were coming together. I realise there is a lot of hard work left to do, but I wanted to be able to share my progress from this point, because this is the furthest I've gotten in a game dev project before. I also have Twitter. Maybe if I share my experiences someone else might get some use out of it, so even if I fail at this I might not feel so bad!

I'm developing in Stencyl but I thought I'd also write a bit about my experiences with different engines, and how/why I came to settle on Stencyl.

So Slick2D is a Java framework using LWJGL. I built my first prototype in a week or so with it, working on-and-off. I wanted some tight, old-school platformer physics/control mechanisms, so I re-implemented much of the physics from Sonic the Hedgehog based on the excellent information on this site. I soon realised however that I was spending far too much time writing beep boop computer code, and too little time experimenting with actual game mechanics, which is what I needed to do. A bit of background about me: I have an undergraduate degree in Computer Science, a MSc in Advanced Computer Science, a big background in AI, Robotics and Software Engineering, and I am (at time of writing) about 3 weeks away from finishing my PhD in Artificial Intelligence (hey check out my academic site!). So, I'm definitely the last person to be afraid of a bit of coding. But I think, for someone with my kind of background, it's very hard to work with a code-based framework without being swept away. What I mean is that I felt I was spending too much time engineering my solution, and working on things I felt were trivial. To my mind, it makes no difference to the end user how *~*~beautiful and elegant~*~* your software engineering solution is, and how many wonderous abstraction layers you've used. Indeed I think those things are important for larger scale projects with larger teams, but for the scale of my project, it really isn't. It's difficult to break myself out of that kind of thinking, so I decided to look for a framework that required less (or ideally no) writing of code, because I needed a working prototype to experiment with gameplay ASAP.

I didn't find one at first, but Unity has quite a lot of out-of-the-box functionality, so I gave it a crack. Unfortunately, when I was experimenting with Unity it's 2D features were not fully developed, so I had a bit of a harder time with it than I would now. It seems to be a standard engine these days, so I'd definitely take another look at it for future projects. I built a prototype, decided I really dislike skeletal animation systems (or, the way I draw things isn't well-suited to being animated in that way, at least) and moved on. This was a good learning experience.

I definitely did not give this a fair enough evaluation because it looked like something where I would spend 90% of my time wrestling with the interface. I know a lot of excellent games have been made with this, and there are a lot of talented people that use it, so discounting it based on my first impressions of the UI was probably unfair.

So I found Stencyl in the end, which uses a version of MIT's scratch language for programming. I'd used this before to teach Undergraduates and School-age kids how to program Lego robots, so I was slightly familiar with it. I quite like it in general, but there are some downsides -- it's quite a lot slower than writing your own code, but the trade-off is that it's quite easy to snap things together, re-use bits and peices and get something working quickly, and the event-based system is very, very intuitive. I'm sure the underlying code looks like hell when it's compiled, but like I said I don't really care for a project of this scale. Stencyl comes with quite a lot of existing functionality in terms of pre-made blocks, and also Stencylforge which is sort of a place where code can be shared between users. My typical workflow is to find something on there that's close to what I need, and then modify it to suit my specific needs. I think this a really valuable approach, as it means you're not constantly reinventing the wheel, which is what I felt like I was doing when writing my own code. It really helped me get through the initial technical slog.

Well that's about it for now. I expect no one will read this, but it was useful to record my experience.