Hi everyone. We’ve got something a little different planned for today’s blog. Over the last few days followers on our Twitter account have been asking questions about Laughing Jackal. While there’s not going to be enough space for me to answer them all, I thought I’d answer the ones about how we do things in today’s blog and then return to some of the others in a later blog. So, on to the questions:
First up is @Ajescent who asked us: “What's the process behind getting a game from concept to actualisation?”
We tend to have a very open system for proposing games here at Laughing Jackal and anyone is free to propose a game. In fact, at one point or another, every member of the team has had a concept which has been made into a released game. Some of the ideas come from creating a game that meets specific criteria, as was the case with OMG-Z, Orbit and Hungry Giraffe, which were all proposed around the same time after we were asked to come up with ideas for minis which could be played with one button (or one finger), but other times it’s more freeform.
The game proposal itself usually consists of one or two A4 sides describing the concept for the game. This will cover the concepts of art style, basic game controls, game content and a loose schedule. Everyone in the office then gets the chance to review the document. Any weak areas are given more attention and if needed extra details are added. A game idea is selected and then put on the schedule and development starts.
Because of the very tight timelines that we work to here at LJ, once an idea/concept has been selected, relevant team members are assigned to start work on the project. The team will meet and do their best to foresee any issues that could arise. Also during this time those little extra ideas will be spoken about and woven in to design. There’s always a wish list of items. :)
As most of our work is for minis, the development team will be very small. Generally the games are created by a team of: - programmer x 1; artist x 1; designer/QA x 1. Test builds are generated very early on in the development cycle and some imagination is needed to see how the final product will look and feel.
We will constantly run the builds, checking for all manner of problems - which could be anything from spelling mistakes, to hangs or
The length of time this all takes depends on the scale of the game, but at the end of this process we should be left with a fun game which is in a fit state to be released to the world (even if it has changed quite a bit since it was first proposed!)
*Phew* that was a bit longer than I expected! Anyway, on to our second and final question for this week :)
This one comes from another of our Twitter followers, @Jeremy_LaMont, who asks: “As a developer, how do you balance what you THINK people want with what they
One of the great things about social media is that it puts you a lot closer to your fan base, meaning we get quite a bit of feedback on how people see our games, both through our own accounts and on the various forums we frequent. While we always take note of what people are saying, we’ve found through our own experiences that something which seems like a good idea on paper doesn’t always work that well in practise, especially when it has to interact meaningfully with the rest of the game.
That’s why testing is the key not just in terms of time (although that also helps) but by trying to get as many eyes on the game as possible. We’ve got an open system here and, aside from the test team, anyone else is free to take a look at the game. After all we’re all gamers here. :)
When we find part of the game which is either no fun at all, or just not as fun as it could be, we then sit down to work out why that is and try to think of a way of making thing better while not breaking the rest of the game. Sometimes it’s a simple balancing issue [well I say simple: this can require a fair amount of iteration to get right :)] and sometimes this can require a deeper change to the gameplay mechanics.
That’s not to say feedback from you all is not listened too: in fact it’s a great way of recalibrating our sense of what works and what doesn’t. The unpatched version of Ace Armstrong vs. the Alien Scumbags was a great example of user feedback at it’s most helpful, as we found after we released it that the overwhelming majority of people found it far too hard and there were also a few issues people were having with the speed you had to hammer the fire button. So, after hearing all that, we took another look at the game and implemented a few fixes, as follows:
To solve the button hammering we added autofire. Aside from that we left the hard version of the game untouched but in the normal and easy difficulties we shrunk the profile of the ship slightly and reduced the number of hits certain enemy types could survive, meaning that while the tricky level design was maintained, the player now had a fighting chance on the lower difficulty levels. Not only that, but the response to Ace Armstrong was certainly taken into account when designing our future games. We like to think we’ve gotten better at hitting the sweet spot between too easy and too hard nowadays. ;)
Wow, this has proven to be rather a long blog! My Cubixx HD score hasn’t changed since last week’s blog. Remember you’ve only got until the 26th to beat my score! I’ll be back next week with more from Laughing Jackal, but until then feel free to leave any questions you want me to cover in part two of this Q&A in the comments underneath, or on the Twitter account. You can also join us on our Facebook, Twitter, Youtube and Google+ pages.
Bye!
Share this post
