Red Forest: Procedurally Generated Pod Racing -is the current working title of what was previously known as X-Speed and Red Forest.

It is a pod racer with a difference! You won’t see “With Six Tracks!” in our feature list, because upon release, Red Forest will feature INFINITE tracks. That’s right- The tracks are generated at runtime much like the levels in Worms.

Now add hover pods to that, and weapons, and upgrades, and speed! ON TOP OF THAT, Add the fact that even though we’ve not released it yet, you can still play it.

That’s right, we’re giving everyone early access for free. It is our view that the best feedback comes from the users, and it seems daft that most games miss out on this crucial feedback prior to release. This means that YOU have control over how the game improves at an earlier stage- and hopefully, you’ll enjoy the game far more for it. This is a bold risk, but we hope you choose to support your favourite games.

Right now, Red forest is limited to 10 tracks and four fully upgradable pods. The pod count will increase over time, and upon release we will remove the track limit.

This page will always contain a link to the latest Web Build of Red Forest. This will be periodically updated during development (Red Forest is Free to play during development- we are, after all, getting your feedback!)

Click here when you are ready to play!

Alternatively, if you have a recent, powerful Android device, Grab a copy of the current Android build from the play store

So, our little one, Sophie, is now fast heading towards 2 years old. Priorities change, and the awesome game you wrote that is taking longer than Duke Nukem Forever to develop dropped off the Earth.

Except I never did let Red Forest die- and work is still being done on it. As mentioned in previous posts, it’s not going to be such a huge project, I’m keeping it simple. Right back at the start this was about recreating a 90’s pod racer, so that’s what I’m going to ensure it stays.

So, what’s the plan?

Well, first, I’m preparing the office space. Equipment is being set up as we speak, and I have a lovely area to work with the development machines, several synthesizers for that Red Forest ‘raw’ audio feel, some budget phones, a cut up toilet roll (We experimented with VR in Red Forest way back in 2013, and I cannot recommend anybody use the toilet roll headset technique although at the time it was awesome! I’ll blog about that later.) some pretty boring chairs and a bean bag that will probably ruin what posture I have.

Second, we’re plotting out our time. I’m ramping up “office” hours to ensure some solid development is done, returning from the “As and when some time appears” schedule that took hold when Sophie was born. Because time never just appears!

Third, I’m going to be looking back at everything we’ve proposed in the past, and looking at what I originally wanted from Red Forest, and building a solid MVP. It’s basically what we currently have bar a handful of issues:

• The GUI overhaul was never quite completed so the current build on steam prevents you from finishing races since the UI for that wasn’t built. That was a huge regression in that build! That is to be completed first so racers can start progressing.
• The handling system is to return to the original system. The new handling system almost trippled performance and pod capacity but caused the game to lose character, so we’re going to pick character here. Yes, this makes the game a bit harder, but it actually feels more like you’re piloting instead of playing a game.
• The track generator will be peeled back, with features retired in place of memorable tracks. Too many features means the tracks all felt the samey and no features stood out. Earlier track generators were more limited, but somehow provided a much nicer feel. Again, character over feel.
• Unique Pod count: Artwork remains an issue, I am not going to lie. However, several factors need to be resolved here. I’m minimising the number of pods in the initial release to allow us to get this out of the door. Pods included to ‘tip the hat’ at Unity will be removed. Why? Unity has gained a bit of a bad name for ‘reskins’ and ‘asset store spinners’ that shove out assets from the asset store as games. This is unacceptable, and the idea behind including any of these assets will just be misunderstood by gamers. There are currently 12 pods but they are a tad…well, ‘samey.’ Now, Games like Rollcage, which we are aiming to pay our respects to, only had a handful, and I think I was completely over-blowing this trying to shove so many in previously. With the upgrade system, to keep a 90’s feel, we should only need a handful of pods. A specific number isn’t flying around, but 5 should do, providing each does have different traits (Which they do, by the way, already.)
• In-Race Pod count: Whilst 128-pod races is absolutely Ludicrous, and that is exactly what we wanted, 64 pods provides the exact same feel. If performance is hit with the above changes, we’ll drop down to 64 pods officially.
• Multiplayer will not exist in the initial version to ensure a release. This feature has taken substantial development time so far and still requires a lot more work to be reliable. I fully intend on providing this feature as what is one of these racers if you can’t take your own pals out on the long and straight? I’ll need to ensure an initial release is out to keep morale running, then focus on the next set of features.
• The price will be reviewed, as will be the release platforms. The scene has changed a lot in the last few years!

Fourth, there is a *lot* of content on this site that has been deprecated by newer browsers. I will be recompiling all of these over the next few months to ensure you can see all of our older toys and projects. There are some real fun mini-games in the One Game a Month section of the site- Including a super early version of Red Forest. I will most probably start with that one so you guys can see where this game came from.

We’re still a low budget studio. I registered the company on a tiny budget of just a few grand back in 2013 because I can generally find the resources needed to get things done. Since then across the board. Whilst we have had a fair few failures, we’ve also had plenty of success stories, and I really should speak about those more on here instead of just spitting out posts about why we aren’t done yet.

I will also blog about some of my much older projects to keep you (and myself) entertained. There are some corkers, and some embarrassments. Who doesn’t love an embarrassing story at somebody else’s expense, right?

I thought I owed it to everybody involved to write a post updating everybody on the state of play regarding Red Forest- It’s clearly still not out- but why? This will read as a sort of post-mortem, but I’ve not let the game die. Read on.

When I started Red Forest, it was a new pod racer, with no competition. People were asking for one, and I decided to cobble a prototype together. That would have been in May 2013 or so.

Truth be told, Code for Red Forest goes as far back as a 2003 prototype I made for a different game. The main pod was actually made by a fellow artist of mine, Adrian Tysoe, going on 12 years ago now. I loved that pod, and so with his permission I put it in the first build. At this point, the prototype actually contained 64-pod races and an actual Red Forest, with physics that really gripped you. I would play this for hours!

“OK, nice! This is doable!” I said. And I set off.

Before I go further, I need to explain something I’ve always kept under wraps. Money. It’s not like me to talk about personal things here, because for the most part, there’s no reason to. An ex of mine had been taking out loans- and I had been signing my name on them (Yes, this was pretty dumb and not something you’ll ever see me do again). This needed clearing, and it took a long time. This prevented me from securing funds for the game, and so I needed to build this game with the cash I had available.

Bare in mind I had £13,000 of debt, and I earned around £17,000 a year, I was pretty stuck. Development was always going to be slow.

The next thing I did not anticipate, despite my experience, is that development would slow as time went on. I got in touch with friends- fellow developers and experts, to get things moving. Alex for artwork, and Hazel for User Experience. This was going to be around Sept 2013.

It then became obvious that the original design specs I wrote for the game were nowhere near satisfactory. So, Alex and I sat down and started to go through them. At the same time, I worked on moving the game from Javascript to C#. This would result in cleaner code (as I would refactor as I went) and a document.

Except despite being very aware of feature creep, and saying we would not let it happen, the goal posts moved so quickly week-to-week that the document never stayed accurate. As any experienced developer would tell you- Stick to your design document, don’t add new features- and don’t rewrite it to fit your just-thought-up-features. At this point there was no point in the design document. At all.

Eventually this ended up in me letting the UX expert down. She does some awesome things- but we were ultimately unable to work together on Red Forest. (We did work together a little on another project, Gravity Ed, but ultimately players did not enjoy the game I had designed, so I bought it to an end early.) Most of the problem here was that I was unable to clearly provide what they needed to get their job done. It led to a lot of wasted time.

During the refactor, I wrote a mesh generation system that is incredibly powerful. It allowed for runtime creation of paths and tracks. Great! Useful for procedural path generation and track editors! Something very important happened here, something I would not realise for another 2 years.

The game was now flexible. It had procedural track generation using a prefab-like system to define individual parts that would merge together. The tracks could loop-the-loop and twist upside down. Sounds great, right?

Except it isn’t. At this point, so much is happening you can’t identify the track- There’s nothing to make you think “Oh, it’s THAT track!” where the simpler track generators had character but didn’t invert.

At the same time, we were getting feedback that the controls were too difficult. Specifically, the handling. Why? Well, I had designed the handling to be twitch-based. This meant you really felt like you were piloting those pods. This is great for hardcore gamers, but most of the players I had in front of the game just couldn’t handle it. It required too much time to get used to. So it was replaced with a bog standard “Follow the path” handling system that feels more like Wipeout/F-Zero. Very important issue number 2 happens here: The pod character is now destroyed.

Suddenly, the game, despite all of it’s technological achievements for just the one developer, has lost it’s character. It’s no longer what I envisioned.

And you can see the big problem: If the game is not what I wanted to create, then I’m going to doubt every step.

So now forward to 2016. I’m still wondering why the game has lost it’s character, and Alex is suffering from a mix between “It’s not perfect so you can’t have it!” and “Sorry dude, Life’s a bit meh at the moment.” – Remember, this project has long run out of budget, so he’s getting no cash-  I can’t complain about the situation and I feel for him. He needs to make cash, so he takes on other work. That’s OK. We both want to see this stuff finished though, so I go looking for help. Three students. That lasted about 2 weeks- I never successfully got any work done that way, and the project effectively stalled.

Since 2013, other Pod racers were announced. Good ones. With budgets. With artists. With better managed development cycles. It shows. And it’s a kick to some very sensitive body parts. (Go play them, they’re good games!)

At this point I had taken on a new full-time employment contract and was expecting the birth of my daughter Sophie. You can tell what’s coming- With a little one, there’s no time for hobby development. And that’s where we are today! For me, family comes first. Everything I do is for them, so they get my time as a priority. Second, is any current contracts I hold, and third, is this hobby.

The game still exists. It’s on Bitbucket. It’s hidden, but exists, in Steam (It was Greenlit). What do we do?

It just isn’t the game I originally envisioned anymore.

Don’t get me wrong- It’s still fun. I’m still proud of what we developed. For one developer and one artist, with no budget, it’s an epic project. Right now it sits needing two things: the UI is 90% of the way through a renovation, and the tournament is currently broken due to rule changes.

I’m very tempted to tidy it up and release it on Steam for free as-is. After all, it deserves to be out there.

Alternatively, I could open-source it. This is difficult as there are many asset-store assets still in use that we never got around to removing- but if I remove them, and turn it into a basic project, who knows- A new, up-and-coming developer might be able to take it and run, turning it into the game it deserves to be?

Or, I could make attempts to turn it into something that more closely matches what I wanted. This actually involves REMOVING features. I would remove the variations in the tracks so there’s some character again. It would still be very cheap- I may even drop it to free- because of all the features I promised, all of which I could absolutely deliver with the right artwork, I actually managed to deliver very few.

With Steam Greenlight sunsetting, I’ve not got a lot of time left to get this game switched on, but if it’s going to happen, it has to happen now.

Red Forest felt “Complete” a few times. I have great memories of taking part in a tournament just to upgrade my pod, then having to adjust my play style because I’d assigned too many power-ups to my top speed and not enough to my handling. I’d get a new pod then forget to balance my power, so I handled really well but kept getting taken out on the straights. Then, I’d perfect it and start drifting around the tracks.

Don’t get me wrong, I’m still incredibly proud of what we built. Over the years I’ve been asked many times where Red Forest is- it’s become a bit of a joke among my friends. Hopefully this post may help other developers avoid the same pitfalls we did.

First, do what you can with your budget. We did this with no budget and had no choice! If you have the option of a budget, use it. Do not be afraid to spend money to make your game what you envision.

Second, for the love of god, get over feature creep. And then get over it again, because it’ll still be happening when you think you’re over it.

Third, stop doubting yourself. Do market research and listen to that, not your own doubts. Red Forest gets a lot of positive attention. Gravity Ed did not- so I killed Gravity Ed and worked on Red Forest. Some of the research for Red Forest did change the game a little from what I originally wanted, but that can be managed. (In my case, I could have let the player select the two handling types.)

As I sign off, I’d like to thank you all. Thanks for the support. Thanks to the few fans (there were 4,000 players on Android a little while ago. Specific thank you to the reviewer who thinks I have “nice balls”). Thank you to those who helped along the way (Alex, Hazel, ‘The Latvians’, anybody else I can’t recall right now!). Thanks to those who provided feedback.

Mostly, thanks to my Wife Nicola, who has put up with everything since meeting me. You poor, poor thing you.

It’s about time I wrote an update for everybody involved. Recently, we got greenlit. It was amazing!

I haven’t been fantastic at keeping everybody updated, so here it is- this is the first proper

Project Update!

Red Forest is going to be my first desktop game in four years. It’s a much much bigger game than my previous desktop game, Mash ’em Marbles. I’ve probably learned more since starting it than I did in the decade of PC development before it. This was no Super Mario clone, or a Match 3, or a minigame prototype. It’s also not an application. It’s a full on desktop game.

It’s not gone to plan so far. Life always gets in the way, and it has again recently- Four moves in two years, and I just found out I’m going to be a father. Along the way we’ve dismantled and rebuilt the project twice, and we’re still not done.

Getting greenlit caused me to re analyse the game, and audience, and reconsider if it was worth completing. The answer is, of course, yes- it needs to be finished. But not the same “finished” that it would have been without Steam.

As a result of everything, I’ve got some help on the artwork- two new team members who will help out when they can, providing pod meshes and 2D art. I’ll introduce these guys shortly.

Here’s the state of play regarding the Steam version:

• It’s now ported to Unity 5, with my custom Unity 4 shaders being upgraded to Unity 5.
• We have some new artists modeling new pods, so we can remove asset store bought pods and have unique designs, as you deserve. We’re aiming for 20 pods by December but that’s quite optimistic. I’ll be happy with half that initially.
• Track generation is now stable (previous versions have been notorious for spawning impossible tracks) but remains in heavy development.
• UI system is being updated for a third time. Daikon Forge became unstable, and NGUI too slow to use. We’re moving over to the new Unity UI system. This is quite a large job!
• Multiplayer is being tested with the new Unity networking system. The game was unstable with the old networking system, though admittedly this is likely to be because it was our first implementation. We want this to be as best as possible.
• We’re considering dropping the number of pods from 128 on track to 64 (in Ludicrous mode) simply because above 64 or so, you don’t really notice there are that many. This allows the game’s AI to perform almost double the calculations, bringing back the character in the AI that I did not notice had started to disappear.

Broken Promises

I made a lot of promises about game content. As time went on, it became obvious that I can’t do everything I promised. I’ve mentioned that in previous posts too. I do feel awful for that, but it’s important we get to a release state. I’ll do everything within my power to make this game something the players want. I may not be able to hit every point promised on the Greenlight page, but I’ll be transparent about that, and I’ll be listening to everybody as we go along. That brings me to the next point:

Early Access

I’m discussing an early-access release, using the funds to complete features that haven’t made it in yet. I won’t take a single penny of steam income until I’m happy with what was promised is delivered. All early access funds will be spent on artwork and features to bring the game forward.

Up until now, the game has been low budget. That means I’ve just saved and spent my own cash on what was required. For a self published game, that’s fine, but it shows, and I do not consider it good enough for Steam. Early Access will allow me to fund some serious visual updates.

In short

In short, we’re still working on it, it’s a much bigger job than I thought, there’s lots left to do, but we’re doing it!

..Oh, Here’s a quick screenshot.

Unity 5, Nov 2015

FLOW (Flexible Lightweight Ogre Wrapper) was a powerful, easy to use 3D engine for BlitzMax, one of only a handful available at the time, and certainly the most powerful. It focused on 3D and Physics, tying Newton Game Dynamics with, you guessed it, the OGRE rendering engine.

FLOWED was a scene layout editor with some crazy features.

We began writing an Ogre wrapper in 2005 for LokBlox but it wasn’t until 2007 we settled on a system that worked. It was the third iteration of FLOW.

I could go on for hours about FLOW, I loved it, it’s a project close to my heart. But FLOW needed more than just a renderer. So we build FlowED. The best way I could describe FlowED is a Three-Man-Team, early version of Unity. It gave you the ability to lay your scenes out, modify materials, test physics in real time, and it had an awesome ability to automatically plug into any game running that was written with it, allowing you to modify that game. I had planned to include scripting, but it never made it into the final build.

Sadly these projects ultimately failed because BlitzMax had a total userbase of around 3000 at the time, so we had failed to select a market we could thrive in. We decided to release Flow for free.

Flow is still available (unsupported) from http://www.flow3d.org/

You can see FlowED’s mod capabilities in this video of MazeMonkeys:

MazeMonkeys was a game I started with a couple of friends back in 2008.

It was a simple FPS. You’re a robot, rolling around, shooting other robots. When destroyed, you fall to your components, which can fly all over the place as you explode. It’s a simple but awesome looking effect. Levels had simple puzzles that you had to solve in order to progress. I’ll confess though, shooting at and blowing other robots up was just so much fun that’s mostly what we did in game.

If you had FlowED (a 3D, Unity-like editor we wrote to extend Ogre) installed, the game allowed you to edit/mod it in realtime using FlowED.

It was written in BlitzMax and C++ with Ogre3D as it’s rendering engine. The game never quite made it to completion as life took over and we moved on, but it’s a project I’m fond of to this day!

These guys were having a dance until one got grumpy and blew the other up with a grenade.

Yes, that’s right! We got Greenlit! Players want the game on Steam!

Stay tuned for more news- We’ve not got much time to update this site right now because we’re busy going nuts with paperwork, getting a bigger team, and planning everything! Once we’re done, I’ll create a new post outlining the plan.

…Well how amazing is that!?

On January 23, 2015, an amazing thing happened. Tens of thousands of developers joined forces for 48 hours and produced a huge number of games for Global Game Jam 2015. It was easily the best weekend I’ve had in a long, long time and I recommend anybody who loves to design or develop in any way to take part.

When I arrived at Stafford University, we were quickly grouped with 6 other talented people and then lead to the keynote presentation.

The annual event always revolves around a given theme, and this year was no different. The chosen theme for 2015 was “What do we do now?”

Immediately thousands of ideas involving zombies were thrown around- my first thought was a zombie car, so somewhat more imaginative than an apocalypse game, but still not good enough. We bounced back ideas for a good hour or so until I mentioned that whenever I cook the kitchen ends up on fire. This led fellow team mate Dave (also Team Lead I may add- a role he took so naturally nobody noticed it happen.) to think up our game idea:

Before It Burns.

‘The thought may have crossed your mind.. “If my house was on fire what would I save?” Well now you can find out! Because we’ve simulated it!’

More information on the game itself can be found here– I won’t talk about the game itself too much here- the important thing was we had a full team, and an amazing idea. Time to make a game!

At this point, 8pm on Friday, I am usually starting to get a bit snoozy. This was an understatement this time, because I’d been over-excitedly coding a network library for the preceding week and had slept a total of around 8 hours during that period. That was nothing, though, because we had 45 hours left to go and I’d heard nobody sleeps at these things.

Dave- who had been to the event for the previous four years- had already organised everybody into roles before I’d managed to organise my own thoughts, and away we began.

The next 9 hours went really well for me- I managed to stay focused, and get a heck of a lot done. I coded the inventory system and some simple UI bits. The gameplay was working. Next to me, Dave was making some odd sphere-like beings shoot scary rays across rooms but I was too focused on my own code to pay attention. What was he working on? I must remember to check it out.

Everybody knows that if you use computers, you must take a break. Dave and I bought our quad-copters for just those occasions! We captured footage of a few of the rooms in use and uploaded them to youtube. We also had a few accidents and my quad was damaged, but it was worth it in the end!

At 4am, we break. we hit an invisible wall so hard it knocked our coding teeth out. Most of the team had flaked away for sleep- who can blame them? As a developer there are two things you can do here- 1) Continue to try to code- and regret it the next day, and 2) Get sleep. I correctly chose sleep, so off I went for a nap.

Oddly,  I was awake again by 7, felt great, so I took a bus to the local city centre and grabbed breakfast before heading back and beginning work.

I’ve not mentioned the artists yet, but they were all hard at work behind us spitting out nearing 100 assets, something that was quite amazing to see from aspiring artists/designers. They took breaks too- by drawing questionable things on our drawing board. It felt like the offices at Matmi where freedom is given and really odd things appear on whiteboards.

The second day though, was quite quiet. We all had our tasks and got on with them. There’s not a lot for me to talk about. I sat down and got the UI’s in and a menu system running. Dave was hacking away at his yellow ball things. I remembered to check what he was coding at this point- He hits play and suddenly flames fill the room. It was a fire-spread algorithm! This system is the heart of the game. When the flames came to light the project suddenly felt alive, like real progress was being made, and it was.

That evening, I took a break to work on the audio.  I didn’t expect it, but I hit on the perfect track almost immediately, and had people in the room asking me to turn it up. Now, I’m out of practice. I’ve not done any professional sound design since 2010, and my confidence in my abilities there are far from great, so this was an amazing reception. Two tracks and about two/three hours later and the music is complete.

We continue right into Sunday morning. At 2am, with almost 19 hours without sleep, I behind to hallucinate. I’m not kidding. First, I imagined I was in a hallway with lots of diagonal tables. Then, my brain whisked me back to a hall in primary school, then I thought I was in a train station and Dave was a strange black woman. I am NOT kidding, this happens if you don’t sleep.

It became obvious that I was experiencing micro-sleeps where you uncontrollably sleep for a few seconds, but your eyes may be open.

Dave and I continue to dribble into our keyboards coding various bits and pieces (and creating mundane object “prefabs”) until about 6am Sunday, when we finally get around to doing a Git Merge. (For those who don’t know, that’s where we take our work and slam it together until it becomes one bit piece of work.)

We reach 8am. I’m feeling great, but the team lead has had to rest.  I take charge of coding for the following few hours and things start to really come together. Until, that is, I go absolutely insane.

I’ve not slept for 29 hours at this point.

Dave wakes up, somehow sharp as a knife, and starts preparing for the final build. He needs me to fix a few issues, which I do.

To explain just how out of it I am at this point, I’ll explain one of the things I was asked to do:

“Can you fix the look up/look down thing?” – which needed 3 seconds of work to change two numbers. What I did, however, was open my software, zoom out to the top of the map, point the camera down, and then look confused. I literally had no clue what I was doing at this point, everything was going over my head. I needed sleep. Badly. Sleep never came, though.

We were a little late submitting the game because my final quick fix completely broke something very important, and we had to revert it. We got there eventually, and submitted the game.

After submission, we saw videos of all games submitted at Stafford University. There were some really good ones, but we felt ours was right up with the best. I’m proud of the team and their achievements.

I don’t remember a lot about Sunday to be honest. After going to sleep, it was like a dream. I felt like I’d had far, far too much to drink the night before!

Will I be partaking in 2016? Absolutely, YES.

Today I’m going to talk a little bit about how it *is* possible to produce low cost games. Red Forest has cost less than £500 so far!

Not all of the information within comes from Red Forest; A lot of this information comes from data I’ve gathered by watching those who do find success; Many success stories come from low budget games. I also cannot claim to say I am entirely successful yet. I’ve successfully pulled off several points within this article, and others are points I know to follow but have not yet had the chance to do so; Points that others who have found success have actioned.

Are you new to the scene? Are you looking at creating your first game but don’t want to run through your savings? Or are you just a financially challenged  developer?

All of these things- and many more- will mean you won’t want to spend money, and cut back where possible. Many will experience resistance from the scene when trying to make progress on a low cost game, so here are some points to argue against common misconceptions with regards to low cost/ zero cost development:

1)  Your game doesn’t have to suck.

This is simply not true. Some of the best games today had low cost. Many come out of game jams (look up Thomas was Alone, which unexpectedly launched Mike Bithell to Indie-Fame.)

if you have a vision, thrive on it, build on it. It doesn’t matter if it takes a while to do so, just get on and do it.

Red Forest started as a fun prototype, but it never sucked, even when we created textures in MSPaint (Yep, i did that.) – and from the moment we implemented decent keyboard controls, it grabbed attention. Get your gameplay right.

Another important thing: If you get this far and the game just doesn’t feel good: Consider dropping it. Don’t be afraid to try, try and try again; Your game doesn’t have to suck, likewise, not every game is a great game. Kill it early and move onto something better.

To demonstrate this, I’ll briefly mention Gravity Ed, which I spent a year or so developing. People liked it, but it never crossed the line from good idea to good game. After gaining feedback, it was decided to end development and pick something better.

2) You CAN be a respected developer.

It is true that other developers will be cautious to get involved with you until you have proven yourself, and this is a key part of gaining respect. How do you start? Network! Go out and meet local developers. Many such groups exist and i’ve met many great developers at these meet-ups. I honestly felt overwhelmed by the community until I started networking, and once I started I wondered why I hadn’t done so earlier. You’ll realise the community is much smaller than it seems; My friends know my other friends by pure chance; not necessarily through me. They’re all great devs/artists/musicians/whatever-they’re-skilled-in.

Get a prototype built, prove the gameplay works. Once you start networking and showing off these prototypes, you’ll gain confidence in yourself (if you lacked it in the first place) and will start to find getting attention a little easier as more people join in. From there…..

3) You CAN find people to work with!

Well, it may be difficult to get people in on your idea, but once you’ve got your head around point 1- and have faith in what you are doing, and point 2- and have people playing your prototypes, you will have met people who are much more willing to help as they have seen your project and know that it’s worth something. At this point, people who are really in to your project may even offer to help!

Red Forest has so far cost less than £500 to develop due to the amount of people willing to help. There’s no way I could just turn up on a forum and post a thread with a subject such as “Hey! Who wants to help me make a pod racer. I can’t pay but” – Nope. These will be mostly ignored or ridiculed. People on the internet have been burnt badly over the past and as a result a lot of these people have become jaded. You’ll need to try harder. You’ve seen post 2? Go and network and meet the people who can help you first hand.

I’ve got two people helping with music on Red Forest, and two designers giving their input. Mad.Array jumped on board early on just from the prototype and has helped shape the game as it is now, but I’ve not got the funds to pay these people much, and I’ve made these people aware of that early on; face to face. If they can see your product, play it, interact with it, they’re going to be much easier to get on board. Respect others and don’t push your luck.

4) You CAN do some basic marketing on low budget, (and you don’t need to pay for media coverage.)

No doubt you’ve met some lovely people from the media during your networking- They’re all over the place, and they’re typically *Really nice People* – Games media are not The Sun. They’re not out to get you, they need their stories as much as you need visibility- so, speak to them. Send an email to your favourite contact, ask some magazines to review/preview your game.

An important thing about the media that was not immediately obvious- and is being exploited by low-coverage publications- You DON’T need to pay the media to cover your game; you are providing them with content that ultimately keeps them their jobs. If they want you to pay, they aren’t going to get you any visibility; they’re just gathering money.

One thing we’re finding really difficult with Red Forest- Marketing on a low budget. It is absolutely possible.

• Create a twitter account for your product;
• Create a website for the product and link it to twitter;
• Post updates daily- these will feed through to twitter;
• Retweet product updates from your personal accounts;
• Join Thunderclap and SPREAD THAT AROUND LIKE CRAZY;
• Join IndieDB and list your product and updates;
• TALK ABOUT YOUR PRODUCT. Share details, tutorials, show how you did a specific feature;
• Get the media talking about it. An RT from a friendly media contact is a godsend!
• Use cross-promo based advertising if possible and if relevant.

5) You CAN succeed.

If you apply everything above- along with anything you learn along the way- you’ll massively increase your chances of success. However, you may not get there on your first go, or even your second. A very important thing in Indie development is: Do not give up. It’s your dream, so keep fighting for it.

Don’t give up, keep coding, and succeed. It’s not easy, but it’s fun and you should give your project all of the effort it deserves. Most importantly, if you do sadly fail, learn from your mistakes, then turn around and give it your all. You’ll only be even better at it!

Good luck, fellow developers! Keep doing what you do best.

Things have been quiet for a little while here at Sturdy Games- and I thought it was about time we updated everyone!

Development of Red Forest is going very well. Things have not been perfect, however, as we realise that with just the two of us and the time we have available to develop, the game as planned was going to be delayed until 2015 or even 2016.

Simply put, we have attempted to put too much into it given the constraints life has thrown at us.

So what does this mean? You’re probably getting a bit of a negative feeling from all this- well, not really. The game is going to be released shortly, but it doesn’t have everything we envisioned for it- it lacks some of the extra features: the tracks don’t quite have the variation they could have, there aren’t as many pods as we anticipated.

HOWEVER:

The core engine did get that long required rewrite. The features we planned for are entirely possible, and some are actually implemented in a simple form but are not exposed to the user yet.

Ludicrous mode still exists,
Survival mode still exists,
Tournament still exists,
Multiplayer: This needs to be in, but so far it is unusable. It’ll go in- but after release, after extensive testing and after settling on a final solution.

There will be only a handful of ships on release- but we will add to these after release in an update.

Track-wise, the game can produce unlimited tracks, but the level select currently allows around 3,000. On release, it will be around 15,000, and we may think up a new method of level selection if that isn’t enough! 😉

There will be five pickups on release- again, these will be added to after release:
Laser, Missile, Shield and the Mad Array

The Mad Array is a satellite driven attack, producing up to 4 laser beams to shoot down and destroy opponents in front of you. It will be dropped very, very rarely due to the damage it causes. As an example in a standard race, if you are 5th, and you get this, it could knock out all four pods in front of you. In Survival mode, the damage is reduced, but it’ll still take out a pod or two if their shields are reduced.

So yes, the game is nearing a state where we will release it, and although it doesn’t have everything we had hoped for it, it’ll have everything it needs to begin with- and just because it’s released doesn’t mean we’re going to be done with it.

…But We still want to give you more!

Unity3D is an amazing tool; It makes development a dream. It introduces coding to novices without limiting their capabilities. It removes the headaches from coding the core engine, 3D renderer, sound system and all of the components required for a good, stable, usable 3D engine by having them already there ready for you to use.

However, Unity is not perfect.

Whilst Unity provides all the basics, and has an integrated scripting system that is actually less scripting than you might think- and more true programming- some of it’s ease of use features contain surprising bottlenecks.

During the massive upgrades required to bring the old Red Forest prototype to where it is now, a very surprising issue was discovered. Here are two surprising bottlenecks in Unity:

1) Accessing the transform member.
2) Accessing the rigidBody member.

OK so strictly speaking, these are the same- they are accessing what Unity have called Accessors. You would think these are just predefined members pointing to the objects transform and rigidBody, however, my theory suggests that:

  RigidBody rb=rigidbody;

is the same as

  RigidBody rb=GetComponent<Rigidbody>();

[update: Actually Unity themselves have said that the exact code execuded is:

  RigidBody rb=UnityEngine.Component.get_rigidBody();

which is exactly the same.]

I’ve done significant tests- now, take a look at the following:

  Transform cachedTransform;
   Vector3 velocity;
  Rigidbody cachedRigidbody;
  void Start() {
    cachedTransform=transform;
    cachedRigidbody=rigidbody;
  }
  void Update() {
    velocity=cachedRigidbody.velocity; //This is ~ 18 times faster than...
    velocity=rigidbody.velocity; //this.....
  }

Those two should in theory be the same- however the top line is 18x faster.

Here’s the test class. Simply create a GameObject and attach a Rigidbody to it- then attach this script, and run.

Start us an IEnumerator to allow a few seconds to pass before the tests begin- just in case there’s any startup lag.

using UnityEngine;
using System.Collections;

public class AccessorTester : MonoBehaviour {

  // Use this for initialization
  IEnumerator Start () {
    yield return new WaitForSeconds (1); //remove startup lag.

    Transform cachedTransform = transform;
    Rigidbody rb = rigidbody;

    float endTime=0;
    float startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Transform.");
    Debug.Log ("Start Time: " + startTime);
    Transform temp = transform;

    for (int x=0;x<5000000;x++) {
      temp=transform;
    }

    endTime=Time.realtimeSinceStartup;

    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 accesses.");

    float uncachedTime = endTime - startTime;

    startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Cached Transform.");
    Debug.Log ("Start Time: " + startTime);

    for (int x=0;x<5000000;x++) {
      temp=cachedTransform;
    }

    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 cached accesses.");
    float cachedTime = endTime - startTime;

    Debug.Log ("cached is " + uncachedTime / cachedTime + " x faster.");

    Debug.Log ("Reading RigidBody.");
    Debug.Log ("Start Time: " + startTime);
    Rigidbody temp2=rigidbody;

    for (int x=0;x<5000000;x++) {
      temp2=rigidbody;
    }

    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 accesses.");
    
    uncachedTime = endTime - startTime;
    
    startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Cached RigidBody.");
    Debug.Log ("Start Time: " + startTime);

    for (int x=0;x<5000000;x++) {
      temp2=rb;
    }
    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 cached accesses.");
    cachedTime = endTime - startTime;
    
    Debug.Log ("cached is " + uncachedTime / cachedTime + " x faster.");

  }
  
}

On my machine, running this code shows that accessing existing Unity accessors is around 18 times slower than using a cachedRigidbody. This was the difference between 128 ships running at 5fps, and 128 ships at 60fps in Red Forest.

So: Think about it- If you’re using a Unity ease-of-use accessor- consider switching to caching.

If you are starting a new project- or have the time to convert- consider extending MonoBehaviour and doing something like this:

First- the new ‘MonoBehaviour’:

//CoreBehaviour.cs

using UnityEngine;
using System.Collections;

public class CoreBehaviour : MonoBehaviour {

  [HideInInspector]
  public new Rigidbody rigidbody;
  [HideInInspector]
  public new Transform transform;
  [HideInInspector]
  public new Camera camera;

  //etc
  public virtual void Awake() {
    transform = gameObject.transform;
    if (gameObject.rigidbody) rigidbody = gameObject.rigidbody; //Overrides the slow rigidbody reference! (Thanks to Fabien Benoit-Koch for the tip)
    if (gameObject.camera) camera = gameObject.camera;
    Debug.Log ("Caching complete.");
  }

}
  
  

Then an example script that extends from it. Note that Awake() is now a public override.

//CachedBehaviour.cs

using UnityEngine;
using System.Collections;

public class CachedBehaviour : CoreBehaviour{    

  public override void Awake () //Awake needs to override.
  { 
    base.Awake(); //does the caching.
    Debug.Log ("Awake called!");
  }
    
  void Update ()
  {
    //Now you can use transform / rigidbody as normal and still gain your speed boost!
  }
}

Personally I like to separate the caching from the Awake function- so I do not use Awake() in my scripts, instead, I do the caching in the Awake() method of CoreBehaviour and have that call Init(), a virtual method which I use in all of my scripts. This is preferred as it feels cleaner, however if you already have a large project the method I have just shown is going to save you a bit of time!
You need to ensure you call base.Awake() otherwise no caching will occur and you’ll get a load of null references.

How’s that for a nice performance boost and minimal interference!

Unity have posted an update about Unity 5 explaining that they are in fact removing these accessors: Unity 5 API Changes and automatic script updating