I’m still waiting on feedback from beta testers. That means I currently don’t have much to do during my commute to and from work. I can’t do sound or music work while on the bus, which means I need design or code things to do! So I’m turning my attention to a screen that I’ve wanted to change for a long time.
I’m revisiting the “join battle” screen. It’s gone through many iterations since the original game in Processing. I’ve looked for ways to allow players to select their character while also keeping the screen easy to read and use. Looking at the old iterations and remembering what didn’t work might reveal clues towards a better design for the screen. Here goes!
Funnily enough, this first iteration was pretty close to what I currently have. This was at a time when there was nothing to do besides going ahead and playing the game, so the title screen was also the “join battle” screen. That’s why the game title and mode are in big at the top. Players couldn’t select their character, and I tried to fix that problem many different ways in the following iterations.
Here, players could press left and right to show a different character in their row. While player 1 had character 1 selected, the other players couldn’t select the same one. However, it was difficult for players to understand the top row as “this is the row for player 1”, and so on.
In this iteration, players could press left and right to change their character, and then press the main button to confirm their character as well as join battle. It was pretty text-heavy, though, since players could carry victories over within the game session, and level selection was also done in the same screen. Too much text, which also ended up making the screen visually unbalanced. Changing characters didn’t look interesting. Furthermore, characters selected by other characters were simply skipped over, but in the background. The last issue was that players couldn’t see all the character options at one go!
This one was my first real attempt to make character selection visually interesting. Similar to the second one above, a player couldn’t put their cursor over a character already occupied by another player. I think the usability was OK, but it’s hard to remember from back then – it was maybe 3 years ago! Part of the issue might have been how similar the characters all looked. Now that I have 4 easily distinguishable characters, maybe this is the one to revisit.
This was a return to the first iteration, with some adjustments. I now had an outlined version of the characters, to indicate the difference between a player who had decided to join battle versus one who had not. Previously, the character was always visible, and either standing still (not in battle) or running (joined battle). Still pretty text-heavy, with the headline at the top hinting to a design concept that I had for all screens back then.
A refinement of the previous iteration, with much less text. I had moved away from hard-coded controls, so no more text referring to D-pads, (1) or X buttons. This had much better distribution of space throughout the screen. The only thing I don’t like about it is the heaviness of the text at the bottom.
And this is what is currently in the game. After going through the previous iterations of this screen, I like this one much better, actually. The balance is exactly what I want: the characters are in the vertical center of the screen, and there isn’t much text. The “Press start to continue” appears after at least 2 players have joined – again, the principle of minimizing the amount of text when first arriving at the screen.
There were a lot of thoughts going through my head during each of these iterations. I was developing the core of the game, while also focusing on the UI to make all of the screens understandable, as well as trying to create and/or maintain unity in terms of screen design. It’s good to have some time to look back on and reassess all of it. Everything considered, the current “join battle” screen isn’t bad at all in terms of visual design.
The only negative to it is that players can’t choose their character. And that’s what I really want to allow. Allowing players to choose their character, even though it’s only an aesthetic choice, is more valuable than the faster “time to battle” that comes from not having that choice. Besides, giving players some time to talk and consider their choices isn’t time wasted, in my mind.
I have reached a decision. I’ll implement a screen like in Processing 8, where players can move their cursor and select a character. Since there are only 4 characters, they will be mapped to the 4 directions.
I’ll post a screenshot when I can – it’s been super busy at home, with my wife working on her thesis and us preparing an apartment move!
Feedback from the beta has started trickling in, and I’ve started making fixes and improvements based on those.
Notably, one crash bug led me to find a duplicate implementation of how tiles are created! That has now been refactored, and tile creation is now leaner. Good find!
I’ve made some nice UX improvements due to feedback. It’s those kinds of particular things that developers simply don’t think of when developing, and it really highlights the importance of getting player feedback!
For example, one playtester said he wished he could actually play his custom level, and not just test it. I think he thought this because when you go to select the level for battle, my default levels are listed first, and then the player’s custom levels are listed. So my fix is to switch those around: the player will see her custom levels first, and then the default levels. I think that should fix this particular issue.
Besides that, work on THE MISSION has slowed down because I’m now back at my day job. I only work during my commute to and from the office, so about 40 minutes at best. But slow and steady work is certainly better than no work at all!
Again, if you’re interested in participating in the beta, get in touch by leaving me a comment or a tweet, and I’ll hook you up!
Guess what I forgot to implement in the game. Mouse support! That’s what I get for having grown up on console games and wanting to make console games.
Fortunately, it didn’t take too long to implement mouse support – just over a week. I did have to make a significant amount of refactors, because I wanted to place the mouse detection in the lowest level that made sense, and that involved moving keyboard support into the lowest level as well.
So now you can click to go through the start screen, change settings, set up controls, etc. This makes the game far more usable :) You still need keyboard or gamepads set up for controlling the characters in battle, of course.
What’s next? I’ll be sending out beta builds to interested parties, in order to get some feedback from not-me. If you are interested in trying out the beta, leave me a comment or send me a message, and we’ll go from there! :)
I’m highly excited to finally release the poster for THE MISSION! It’s by talented artist Rezan Ansari, be sure to check him out – he excellently captured the competitive and dynamic spirit of the game! Feel free to download the poster, make it the background for your portrait-oriented monitors, print it out and put it in your living room and/or bathroom, plaster it up on billboards! Share it! :)
Last weekend I met up with a friend of mine named Filip Lange-Nielsen. We’ve known each other since the first days of our masters program at university, where we went on to write our thesis together. Now he is a game designer at Io Interactive, where he works on Hitman! He kindly agreed to playtest THE MISSION, and particularly the level editor. We had a great time, and I got a lot of valuable feedback.
His general impression of the editor was very positive! He liked it and how visual it was. He quickly felt attached to the level he started making. Being able to test it right away was quite important, to see how it is when actually running through the level. Filip also said that it feels smooth to edit – that’s good! I’m really glad that it was received so well, and it makes me much more confident that players will enjoy this feature!
We also found a bunch some bugs! Since then I’ve fixed those bugs, as well as uncovered others which I’ve mostly fixed now. I’ve also made UX improvements based on that playtest, both in the editor as well as in the controls configuration screen.
I have a couple of design dilemmas though, in regards to the editor. Little bit rambly, but these are the internal discussions I must have while designing!
Dilemma 1: Auto-save?
There was some confusion around saving in the level editor. Filip was initially pretty nervous about pressing ESC – he thought he would be returned to the previous screen and his level would be lost.
So I wondered if the game should auto-save the level as you make it. That would be nice for when adding tiles individually. And it would work better with the top row! The only rule when making levels is that there must be at least 4 non-solid tiles in the very top row, as those will be player spawnpoints. If you try to save when there are less than 4 possible spawnpoints, you get a message prompting you to fix that. If the game were to save each time you add a tile, you would get that information right away.
However, when filling tiles (like the paint bucket tool), how would that work? Ignore the top row when applying the fill? Isn’t that weird? Yes, it is. So that’s not an option.
Anyway, I reassured Filip that his beautiful level would not be lost if he pressed ESC. Then he saw this menu:
The menu is a little Zelda-like (“Save and continue”, “Save and quit” choices), and to be honest, a little heavy on the options. The rule of thumb that I just made up is that 4 menu options is the maximum for ease of decision. I’d like to trim those down. Also, I noticed that the player would open the menu and save, and then open the menu again in order to close the level. So there is some space to save by getting rid of the “Save and close editor” option, and improving the communication of the rest of options.
Anyway, after talking it over with myself, I’ve decided that I will not implement auto-saving, since that opens up a bit of a can of worms. It’s also nice to keep that choice in the hands of the player. If the player tries to close the level with unsaved changes, I’ll put in a prompt asking if they would like to save before closing it. Good UX is good!
Dilemma 2: Edit/play in same screen?
I implemented a test option in the editor menu. It allows the players to try out the level, minus the scoring. So it’s to get a sense of the space and evaluate its design qualities and possible improvements. I love it!
But! But! What might be even more interesting and fun is this: allowing players to edit and test at the same time! For example, player 1 edits the level while players 2 and 3 run around in it. It would be highly interesting because it further shortens the iterative loop process. It would also be more fun because the editing itself is now playful as well! Add ground tiles on your friend to make her respawn. Then she explodes your tiles to mess with the nice corner of the level you were working on!
I’ll let this keep percolating in my head for a while. Maybe it will be for a future version of THE MISSION, after 1.0 :)
And one more screenshot just for fun! Observe the magnificent spawnpoints UI at the top of this Foundry level!
Check it out at @themissiongame!
I’m in an unusual-feeling place now where YES, THE MISSION is almost shippable!
But I can’t really ship it yet. I want to get in some last testing rounds for any sneaky bugs. E3 also just happened, so everybody will be wrapped up in all the news pouring out from there.
So I’m waiting a little bit… And in the mean time, I’m of course still working on the game. I started on the stuff I wanted to do for minor releases, as well as other things that came up:
- Added shading to vine tile, because it was flat and looked sad. Compare these before and after screenshots! It took me a year to get around to doing this, wow…
- Modified the title menu so it was less crowded. With the FORUMS item, it got to be too much. So I separated it into two menus, and there’s more room to breathe. I placed the FORUMS on the main menu (and not the options menu) because I hope it’ll be important enough to warrant that position.
- Reload/charge meter for gun. This is as fresh as can be – I just finished it up yesterday. But I’m not sold on putting it in the game. The reason I made it is because there are people who are annoyed at the slowness of the shooting. With this little UI, I was hoping to mitigate that feeling. However, I feel it really doesn’t fit with the aesthetic of the rest of the game. I don’t know how I could dress it up so it fits. So for now, it is not in the final game. Let me know if you feel it should be.
- Panning of sound effects based on the position of their source! Now, when you shoot something on the right side of the screen, your stereo speakers will produce the shot sound from the right speaker only. Experts say this increases immersion. I say it gives a nice feeling of space to the game. I had noticed this effect over a decade back in CHRONO TRIGGER, and loved it. I am happy to now have the same effect in my own game!
- Code cleaning. The kind of stuff that makes programmers happy, but has little effect on the game itself… most of the time.
What am I up to from here on out? I’m starting work on more music for the game. There are only two tracks right now: the title, and the surface battle. I had planned on finishing more tracks for future minor releases, but I have some time now! I had planted the seeds for each of the 3 remaining tracks about 6-12 months ago, so we will see what has germinated in my mind.
I changed this blog black to having a landing page of sorts, which serves as the about page for THE MISSION. The reason is that it’s easier to visit “themissiongame.com” than “cactusanctuary.itch.io/the-mission” :) So right now the info is all duplicated, but that’s OK!
Just a screenshot, check it out! And whichever way your purist tendencies fall, you can turn the CRT effect on or off :)