Month: October 2014


For the past couple of weeks, I have been working on the game Gravitas Magi, as project manager and level designer, as part of the team ‘The Segway Army’. We recently completed a prototype build (see Part 1) which was play-tested by various members of the public. Feedback was also collected from all participants to be used in refining the game further (See Part II). Now, I’m going to take the next several hundred words to ramble on about this whole process. You’re welcome. Oh, and on a side note: for those of you wondering, the title of this blog entry means “Gravity Magicians – Opinion of The People Part 2″.

So, the prototype was finished and then we moved into the play-testing phase. From this play-testing we did get useful feedback, not quite as useful as we had hoped, but useful nonetheless. The key problem with the feedback we got was due to a major bug in the game. Players could very easily fall through the floors and walls (which are kind of also floors) and whatnot. Clearly, ensuring that the game is free of all major bugs before play-testing is critical to preventing this from happening again. Yet it has happened, and because of this a large portion of the feedback was focused on this issue, rather than the gameplay itself.

However, we did manage to get some useful feedback thanks to some carefully constructed questions, so not everything is terrible. These questions directed the player’s attention to specific aspects of the game (such as gravity) or if their experience was at all confusing and why. One important thing we learned is that our game was confusing as hell, and we needed a hell of a lot more feedback and instructions so people will actually know what’s going on. We also learned that spells were as confusing as they were useless.

Furthermore, we found that a number of players felt that the action of the game was either spread out too much or not enough, as getting closer or further away from other players was difficult. Finally, we found a number of people that struggled to determine where the other players in the game were, which hampered their ability to play.

Each of these have been addressed accordingly. We are adding clear instructions to the game start, as well as button prompts to the game itself to make things clearer. We have also removed spells entirely, because the best way to solve a problem is to take that problem and remove it from existence entirely. By reducing the level size as well as adding a new ability that allows players to launch themselves into the air, we have allowed the action to shift across the map more dynamically to prevent things from becoming too compact.

Finally, reducing the level and increasing the field of view has significantly increased visibility and general playability. The addition of a ‘tagged player warning’ that alerts any given player to when the tagged player is within a certain distance of them will also not only improve the players’ ability to know where the other players are, but the overall clarity of the game as a whole.

So this is where we’re taking the game and why. It’s brief and somewhat vague, but you get the idea. Hopefully…


Gravitas Magi – A Populo Iudicatum Part I

For the past couple of weeks, I have been working on the game Gravitas Magi, as project manager and level designer, as part of the team ‘The Segway Army’. We recently completed a prototype build (see Part 1) which was play-tested by various members of the public. Feedback was also collected from all participants to be used in refining the game further (See Part II). Now, I’m going to take the next several hundred words to ramble on about this whole process. You’re welcome. Oh, and on a side note: for those of you wondering, the title of this blog entry means “Gravity Magicians – Opinion of The People Part 1”.

Anyway, first things first, development of the prototype. I’d say the most prominent thing that I’ve learned here is that management is fun. By which I mean management is goddamn difficult. The key two problems that made it so difficult were poor communication, and work delays (which is a polite way of saying ‘people not getting their shit done’). Oh, and one more thing that is one of the main causes of those two, which I’ll cover later.

Poor communication is the bane of any project. If people don’t communicate, then other people don’t know what’s going on and things don’t get done right, or on time. I myself managed to stay in touch with everyone in some for the better part of the duration of the project, so at the very least I acted as a central hub of current progress information. However, not having every member communicating with every other member slowed the process down due to people being unsure of what assets they would have available to work with and when.

Work delays is a difficult issue to analyse. Tasks were distributed to various teammates, with expected dates for completion, and when these date arrived, the tasks were not completed. In part, this is likely due to poor communication slowing the process as a whole, but some other factors were undoubtedly involved on both a management and on a more individual level. Yet, the more individual factors are, by extension, management problems as the project should have been established as a clear priority for all team members early in the project. So why wasn’t it?

We never decided on a manager.

Yes, that’s right. Technically, there was never a team decision as to who would be the official manager of this project. So how the hell am I apparently the Project Manager then? Quite simply, no one was getting anything organised or putting any plans in place, so I did. I put forward ideas for how we should proceed and everyone agreed, and from then I’ve kept on doing it. Put at no point have we all said “Yes, Jack is the manager.” Oops.

So this creates a particularly prominent issue, in that whilst I’m making all these plans, I have no authority because no one has agreed to give it to me. So, I cannot say “We’re having a Skype meeting at 5pm Saturday” or “Where’s that [asset]? You need to get that done now so we can get on with the project” without being a total dick*. It’s the difference between being the manager and being a really annoying team member that wants everything in the game made his way. And this is one of the key causes of my sub-par management which lead to poor communication and work delays.

*I know, technically managers are meant to be total dicks (from time to time), but the key difference here is that we haven’t officially said “Yes, you’re the manager so you can be a dick now and then”.

But now the most important part: How do we fix this now and in the future? First things first, always officially declare a manager at the beginning of the project. That would solve a lot of these issues. In fact that just about covers it. For future prevention, anyway. As for fixing it now for the second half of the project, a discussion needs to be had about who is officially the manager and who then has the authority to say when things happen. I don’t know why this hasn’t happened already, but insofar people have been agreeing to my various plans and tasks, and everything has been getting done eventually. So I suppose it could be worse, but it could also be better. A hell of a lot better.

The Difficulties of Designing a Three-Dimensional Space Where Every Surface is the Floor

Over the past several days, I have been working as part of the team ‘The Segway Army’ as the sole level designer for the game Gravitas Magi. Gravitas Magi (Latin for ‘Gravity Magicians’) is essentially a game of tag. In this multiplayer game the players are a group of wizards who utilise various types of spells and magic and order to out smart and out manoeuvre their opponents. The main type magic they use, as the title would suggest, controls gravity. And this is where level design gets weird.

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 (all whilst walking only on the floor). There’s not too much to consider in this layout; the design is rational, straight forward, and generally makes sense.

Now imagine this office worker is also a wizard with a blatant disregard for physics and the fundamental laws of the universe. Now this douchebag wants to get to the photocopier by walking across the ceiling. But there are no obstacles on the ceiling so things will be way too easy. So, we throw some desks up there and pretend that everything is normal. But now this jerkwad decides he’s going to run about on the walls, so we put some chairs there to get in his way (and we admit, things are getting a little odd). And even still, he finds a path that requires not nearly enough effort – falling straight down the middle of it all. So we start hanging things in the air so he at least has to try avoid a few things on the way down.

By this point, the office is just full of random objects floating around in a haphazard way that makes no sense whatsoever. Welcome to attempting to design a room where very surface is the floor. There are no limitations to where this absurd gentleman can walk, so we have to try and account for all of that (which isn’t easy).

Planning paths through three dimensional space with this kind of movement is exceptionally difficult. When placing a single object, you have to keep in mind that a player cab approach it from LITERALLY ANY DIRECTION, and then leave in much the same manner. And then one has to take into account where they are actually trying to get to (or get away from).

Because of this, rather than attempting to design a space in which players could exploit specific paths and strategies, I aimed to create more of a playground, wherein no clear strategies existed and players could attempt to create their own using whatever was available. So essentially, that’s my excuse for just taking a bunch of shapes and throwing them around in a cube until they look nice, rather than trying to draw out a proper plan.

Insofar, I cannot yet determine if this ‘playground approach’ is in any way effective as we do not yet have the level integrated with the core gameplay. Hopefully that will all come together in the near future and I can finally find out if any of my ideas work at all.

Gun Blaster Tankship Extreme III Infinity Laser – The Post Mortem

Gun Blaster Tankship Extreme III (GBTSE III), or rather its prototype, is a simple incremental dual-stick shooter that was created a team of three gentlemen over the period of a week. The objective of this project was to create an intense dual-stick shooter with endless progression and no limits, that ‘could be played for ten years’. Overall, the project was successful in meeting all scope requirements yet lacked some desirable content.

For this project, all of the scope requirements were met, and all were met within the given timeframe. This was achieved primarily due to the dedication of the various team members and their ability to work together. The level of dedication and teamwork within the team mostly comes down to each members own personality, which can be difficult to influence. Despite this, to positively influence dedication and team work in the future, praise must be given to those who are productive and those who produce high quality assets/work (not that you can technically ‘produce’ work, but you get the point), whilst rationalism and professionalism must be encouraged so even those with conflicting personalities can more easily work together.

Unfortunately, this project was lacking in detail of some features, such as weapon upgrades. The key reason that this occurred was due to the team’s skill distribution. Firstly, all members were designers, and of those three designers only one had sufficient coding knowledge and experience to program the game itself. As such, the bulk of the project work was assigned to that team member, with a second team member taking care of most of what was left, leaving the last member with nearly nothing to do. Due to the time constraints of this project, there was only so much detail that one person could program into the various features.

The most obvious solution to this problem is “get a better team”, but that’s not always an option. Sometimes you have to work with what you have. To help prevent, or at least mitigate, this issue project manage must be improved. Firstly, more effort must be devoted to properly dividing tasks and finding tasks that complement a team member’s existing skills. Also, in the event that a team member does not know how to do something, time should be made for them to learn it. And they should do that. They should take some time to learn how to do what they need to do. Pretty simple stuff, no?

On the whole, the project was a definite success. All requirements were met within the specified timeframe, and the end product was an enjoyable game. Whilst there are plenty of areas to improve, one cannot be dissatisfied with what we have accomplished.

Want to try out GBTSE III? Web build coming soon!