Month: November 2014

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…

Gravitas Magi – Finale

Over the past several weeks I have been involved in the development of the game Gravitas Magi, as you may already know. For those of you interested in exactly what I am responsible for, allow me to give you a list:

Project Management:

  • Maintaining team communication
  • Task distribution
  • Maintaining team scheduling (Gantt Chart)
    • Ensuring tasks were progressing/being completed within reasonable time frames
    • Rescheduling/removing various tasks when not on schedule
  • Design Document (with others)
  • Creation of the questionnaire (with others)

Level Design:

  • Creation of level prototype
  • Creation of level exterior
  • Creation of all obstacles within the level
  • Arrangement of level obstacles/power-ups/player spawns/King of the Hill Zones
  • Tweaking of the level to better support play

All of this, particularly the project management, has helped me move towards my professional goals greatly. Through this project I have learned a significant amount about project management. The primary piece of knowledge that I’ve gained is that robust and effective management and communication systems need to be implemented as soon as possible, because as the project progresses it becomes increasingly difficult to implement and transition to these alternate structures. So next time I’m managing a project I will definitely make sure that I get everything set up and functional from the get go.

As for level design, I feel this project was less helpful. Given that I was faced with the challenge of creating a room where every surface is the floor (see my similarly named post for a more in depth description). Whilst this is certainly a challenge that forced me to try and produce creative solutions, I feel that I did not posses enough skill with level design going into the project to get the full benefit of trying to tackle such a problem. Yet I did learn one very important thing. Gravity’s a bitch.

The project as a whole ran well enough. All of the content we wanted to implement was implemented, although some was lacking polish. The lack of polish was mainly due time restraints. As one of our programmers fell ill we had to reschedule that which we intended to implement and as such, polish time was nigh completely lost. For future projects more robust risk management should be put into place to ensure that the impact of such an event is better minimised. Also, more effective rescheduling and workload redistribution should be implemented to make better use of the time and resources available.

On the whole however, everything came together rather nicely. Some members of the team are considering refining and polishing the game further to then publish the game of Steam Greenlight and subsequently release the game for free on Steam (hopefully). So if there is any more news on that front, I’ll be sure to make an update. But otherwise, this marks the end of Gravitas Magi.