Ludus Empire

Reaching New Heights – Deadwood Tune-Up

Genre: Top-Down Shooter
Platform: Web
Players: Single Player
Status: Incomplete, Abandoned but Available

Team: Ludus Empire
Role: Manager/Designer
Duration: 6 weeks

Deadwood Screenshot

Team Members:
Jack Kuskoff – Manager/Designer
Jim Vincent – AI & Systems Programmer
Huxley Dowling – Player & Systems Programmer
Blake Harris – Designer

Deadwood Tune-Up is a top-down shooter in which players must spend their days scavenging for various car parts in order to repair a beat-up 4WD and escape the zombie infested town of Deadwood. But you cannot simply spend all day fetching parts, you must also search for weapons and ammo to ensure your survival against the hordes of the night, who not only want you dead, but your car as well. Can you keep them at bay and manage to survive?

You can play Deadwood Tune-Up here.



The Great Big Blog Of Things I Should Get Marks For – Vol 1

So, over the past thirteen weeks I have been part of the production of several games/games prototypes as part of my university studies. As this trimester comes to a close, I’m taking this time to create a small gallery of some of the specific work I’ve done. Primarily, this will be a place to show my 2D and 3D creations, with some audio, programming, and level design here and there. Oh, and some management stuff, if I can manage to find a decent way to showcase that. So, without further ado, let’s get to it.


Speaking Without Words, Or Anything Else Really – The Art of Ineffective Communication

So as you may recall, in my previous entry I said:

“… effective communication is about telling the player everything they need to know without them ever knowing that you’re telling them.”

Now, in the most recent game I was working on as part of Ludus Empire, Deadwood Tune-up, this is not what we did, and this is what I’m going to be talking about this time. The player didn’t know that we were telling things them for sure, because we told them practically nothing.

So first, I’m going to talk about the state our game ended up in. By the end of our time frame, our game was at a point where it worked (mostly, anyway). In this state, we had several methods that were designed to communicate the information necessary to the player. The key part of this was the voice acting.

The player had a handy helper, Billiy-bob the Mechanic, around to give them tips and advice on what they should be doing. He generally told the player things like ‘Get me some car parts’ or ‘You’d best grab some guns’, two of the core objectives of the game. Whilst to us, this was more than enough information to make it clear what to do, we forgot that we would have far more info than the general player because we made the damn thing. So this created a problem.

The big problem was Billy-bob conveyed info, but not nearly enough. Whilst it told the player exactly what needed to be done, it told them nothing of where to go, what to look for, how to pickup the stuff up, or why this stuff needed to be done. In what little ‘play testing’ (and I use that word lightly here) we managed to do, often players said something like ‘Right, so I need to get car parts, where are they?’. At that point it was pretty clear there was a problem. Obviously, this problem could have been easily fixed by changing the voice lines to say something like ‘Grab me some car parts from the Gas Station’, but alas, we had no time to make any edits at that stage.

In another method we employed, we attempted to convey the types of various buildings using icons and symbols. Whilst this is not in and of itself bad or ineffective, our execution was poor. Whilst you could generally work out what the building was related to (eg. The one with the army helmet on it is probably a military building of some king) this alone was not enough to communicate the gameplay effect of that particular type of building.

We could have better communicated this in a couple of different ways. Firstly, by making better use of the voice lines, this wouldn’t have been as much of a problem. If the mechanic gave you a name, you’d likely be able to work out which building was the one he meant based on the symbol. Alternatively, we could have used more icons to indicate the kind of items they would spawn, or we could have simply put all the definitions for everything in the instructions, but that falls back into the obnoxious text issue a bit.

An important thing to make note of here, is why did this happen? Why did our game end up in such a state and why were we so clueless as to these flaws until the very end of the project? Firstly, it happened due to a lack of time, we over-scoped and under-performed leaving us no time to invest in improving the game and making it fun. It also left us no time for play testing until the morning we had to present it, at which point it was too late to make significant changes. And that is also the reason that we didn’t see the flaws until the end. We had no one else play the game before the end, because before the end we had no game to play.

From this, we can gather some very important lessons. Firstly, PLAY TESTING IS CRITICAL, MAKE SURE THERE IS TIME. Secondly, make sure the work you’ve set out can be completed within your time frame and do everything you can to stay on schedule. Lastly, be prepare to start cutting content as soon as you begin to fall behind; it’s better to have less content that is more polished and enjoyable than more content that isn’t. Had we managed to do all these we may have ended up with a game that worked and made sense. But we didn’t. Next time though…

Speaking Without Words – The Art of Effective Communication

In any video game it is critically important that the player is always aware of what is going on and what they should, or at least can, be doing. Most video games have a huge assortment of rules, states, and information in general all which are conveyed to the player in one way or another. Some games convey these instructions and pieces of information in straight up text plastered on the screen. Others use audio, sometimes as blatantly as if it were text, and other times more subtly, guiding the player with hints and references. And of course, there are the visuals. All the bright shiny stuff designed to make you look at exactly what you’re meant to look at and to make the important stuff really goddamn obvious without you ever noticing. To further explore this, we’re going to look at everyone’s favourite hypothetical office sim: Casual Office Extreme: Learning Edition.

Imagine you are designing a game about office workers, where the objective is to make your way around the office building delivering various items. Normally, the level would be designed with all of the furniture and important items either on the floor or on top of other things that are on the floor. All of these would then be arranged such that the player could make their way between and around them, and get from all of the Point A’s to all of the Point B’s.

Now, let’s say that the artistic direction for this office is the same as any other regular office ie. none. A pretty drab combination of greys, creams, and browns. Now, once the game begins, the player needs to know what they are supposed to be doing, what they are then grabbing first, and where they are taking it to. One method of doing this would be to slap a big block of bright red text in the middle of the screen that reads “GRAB THE COFFEE CUP AND TAKE IT TO THE MAN IN THE BOSS’S OFFICE TO WIN THE GAME”. Direct and effective, sure, but not a very eloquent solution. If we were to take the non-text visual approach, it could be done by having some icons on the HUD, such as a picture of a coffee cup then an arrow pointing to a picture of the boss sitting at his desk. However, I feel the best solution for this particular situation would be through audio. Have the boss call out “Hey Bradley, could you bring me that coffee cup I left on your desk?” Clear, effective, and far less in-your-face than the text.

But then what about communicating the smaller details of the world? Looking around the office, half of the items are going to be built into the furniture as part of the scenery, and of the half the remains half of those will be glued to whatever they’re sitting on with supernatural force. It is the quarter that remains that can be moved around the world, but how do we distinguish that quarter from the rest so poor Bradley isn’t just wandering around the office pulling and tugging on everything he sees like some kind of lunatic. Again, we could make use of obnoxious text prompts, with the words “PRESS E TO PICK UP THIS PARTICULAR ITEM THAT YOU ARE CURRENTLY LOOKING AT” being plastered over the screen in bright red whenever you glance at something you can interact with. But there are other options.

We could use the audio, and have Bradley say something whenever he looks at some thing he can pickup like “That should do.” or “Is this what they want?”. Yet quite possibly the simplest solution here is a glow. A simple, faint, light blue aura around anything that he can pickup. It’s not exactly realistic to have a glowing coffee cup on every desk, but this game is called ‘Casual Office Extreme‘ for a reason. And that reason is primarily the coffee cups.

So, hopefully now you get the gist of what I’m talking about. If not, the point I’m trying to get across is that effective communication is about telling the player everything they need to know without them ever knowing that you’re telling them.  In the most recent game I was working on as part of Ludus Empire, Deadwood Tune-up, this is not what we did. But this post is far too long already, so I think I’ll write about it in the next. So until next time, dear reader.

More of Me Blabbing About How I’m Bad at Management and How I’m Trying to Be Not Bad at Management

Wow, did you read that title? What a great title. Nice and concise. Poetic, I think. Inspiring, even. I like that. Anyway, as the title suggests, this particular glob of words is going to be devoted to reasons why I am or was a terrible manager and what I’m doing or have done to address those and make myself an un-terrible manager. So without further ado, let’s get to it, shall we?

Firstly, a couple key things that I did wrong on the previous project: I was never officially appointed manager (this is a big one) and I didn’t properly implement robust management & communication structures from the beginning. So, how have I addressed these so far? The first, was pretty much addressed for me. I declared an interest in project management, and as such I was assigned to a team as project manager by the facilitators (i.e. lecturers). So it was pretty clear to everyone that was the role I was taking.

As for the management and communication structures, they are much better this time around also. Within a couple of days we had a full design and tech doc, both of which are much more details and comprehensive than those of the previous project. I will admit, however, some details on the more aesthetic side of things is still missing. I shall endeavor to rectify this within the next few days by discussing such considerations with the team. Furthermore, we have also been operating from a full Gantt chart from the point as the documentation was completed. So now, everyone knows who is doing what and when.

The communication is still somewhat lacking. We’re having meetings more often and with greater productivity, however, one team member has disappeared for the last few days and efforts to contact him have not been successful.  From the experience I have with him from the last project, he should be continuing his work effectively, yet until I manage to get in contact with him that is naught more than hopeful optimism. Otherwise, a more rigid and repeating meeting structure has been established so as to remove reliance on the continual ‘Is everyone free at X o’clock for a meeting?’ messages. This way, they know well in advance that they need to be free at this time on this day so we can make sure we’re still on track.

So that’s the main mistakes I made in the past covered. Now, insofar I’ve already noticed a few things I need to aim to improve upon. Firstly is my flexibility in terms of task completion. I’ve found I’m far too accepting of delays, so I need to be more firm with ‘this need to be done by then, no exceptions’. That’s something I’ll be doing over the remainder of the project for sure. Also, further improving communication is some I’m going to focus on. Particularly making sure teammates don’t just disappear for a while. It really is… inconvenient, to say the least.

So that’s management for me right now in a nutshell, more or less. Things are better, but far from perfect. That’s management for me in a much smaller nutshell, just for you. I’m sure I’ll be rambling on about all this again soon enough, so if you’re sitting there thinking “Dear god! How ever will he manage this?” be sure to come back and find out. Or don’t. It’s up to you really. Regardless, until next time (if there is one).

Randomised Level Design

The latest project that I have had the pleasure of working on is a top-down shooter being developed by Ludus Empire. For this particular title, I am once again in charge of level design. And once again, the type of level that must designed makes use of a concept with which I have no experience. Hooray. It seems I have a habit of getting myself into these kinds of jobs. Admittedly, this particular level is no where near as mind breaking as the one I had to make for Gravitas Magi, but still, it has its challenges.

Now, as the title suggests, this level has to be randomised. And not just once, every time the game begins. This means that my tasks requires me not only to come up with a method of generating various level pieces that will generally fall in a way that supports gameplay, but also to write the actual algorithm that creates it. For those of who have no idea what I mean, allow me to present a scenario (that may or may not be copy-pasted from a previous blog).

Imagine you are designing a game about office workers, where the objective is to make your way around the office building delivering various items. Normally, the level would be designed with all of the furniture and important items either on the floor or on top of other things that are on the floor. All of these would then be arranged such that the player could make their way between and around them, and get from all of the Point A’s to all of the Point B’s. There’s not too much to consider in this layout; the design is rational, straight forward, and generally makes sense.

Now, typically, each time the player walks into the office building all of the furniture would be exactly where it was before since office buildings generally aren’t prone to undergoing significant re-organisation on a daily basis. But imagine if it was, and every time you show up and try to walk to your office, you have to find where the hell they put it first. When this is the case, whoever is responsible for the rearranging has a hell of job.

See, this person has to take out every bit of furniture and put it back in the office in a completely different way to before. Yet they can’t just whack everything down wherever they feel like; there a few things that they have to make sure are the same. All the employee should be able to each their office, the coffee, the photocopier etc. As such, every time they go to put something down, they have to make sure they’re not blocking any thing off, or otherwise violating the rules. They’ll be working all night and drinking a lot of coffee. Their life is hard.

Say The Arranger’s boss, The Boss, want to take advantage of modern technology and replace The Arranger with a robot counterpart to save on time, salaries, and excessive coffee consumption. This means The Boss needs to come up with a way to program the robot (because they’re too stingy to hire someone else to do it) with commands that will ensure it doesn’t break any of the rules when putting the room back together. Things like, “when placing something, make sure you’re not blocking any important paths”.

My job is that of both The Arranger and The Boss; I have to come up with a way to make sure things will always be organised correctly and then I have to tell a computer how to do it. Currently, I am working based on sectors. The entire map is divided into 9 sectors. Each sector handles its own generation of obstacles. This way, it ensures that the spread of important buildings and obstacles is generally even, but still has an element of randomisation to it.

What I need to implement next, is a way of checking when an obstacle is created at its random position, if it has appeared inside another obstacle. If this is the case, I can then delete it and try again. This way, regardless of what shapes of obstacles we use, they will be able to find a place in the world with each other without overlapping. When this system is working, I can also then make use of a couple of map-wide generations, such as a couple of large zombie spawns or small campsites that can be scattered about any which way.

Insofar, I cannot say exactly how the overlap check will work, but I will have to have it done by week’s end at the absolute latest. So we’ll see how it goes. If it proves too difficult, it may need to be scrapped in favour of a simpler system of randomisation. But again, we shall see…