Group Project Devlog 11 (Postmortem)

This group project taught me a lot, in particular about how managing and directing a team like this works: how to offer helpful insight into how a style of graphics, or level layout, or piece of code fits into the puzzle that is the final product, to keep the overall vision of the game coordinated and keep the project on track. Before this project this was something I really was not interested in, but now with some experience it has prove interesting, and (though a little stressful) quite rewarding, so I think I will be looking into this sort of role in future projects like this.

I also got some much needed experience in running more sophisticated play tests, particularly in trying to capture as genuine reactions to the game as possible. It was quite difficult restraining the urge to explain the game outright to our play testers before they got their hands on it, but information I had read on the topic recently suggested doing so might not be such a good idea:

Once you have told a playtester how the game is supposed to work, you can never go back and see their natural first impression. I tell my game design students to always keep in mind that “you don’t come in the box,” meaning that when the game goes out to the public, you won’t be there to explain it to each and every player. (Fullerton, T. 2018. Pg.281) [1]

Maintaining this sort of unbiased environment when running the play test was a slightly new experience, as when running tests for earlier games I would often let small pieces of information slip, even if my intention was to give my testers an fresh impression when playing the game.

Finally, I suppose I’d be remiss to mention that I’ve learned a lot about Gdevelop as an engine: what it’s good at (rapid development of prototypes), what it’s not good at (complex physics simulations and large scale projects) and how to use it (just use the default player behavior, don’t try to reinvent it using their physics engine for god’s sake they have a weighted jump implemented already). Even if it drives me mad sometimes I can see that it’s a powerful tool for this kind of roughing out a prototype, and may even use it in the future to test interesting ideas or basic mechanics out... but not for a while. I’ve had enough of Gdevelop for a while.

In conclusion this project has been a great learning experience for a number of reasons: it’s taught me more about managing/directing projects, about running sophisticated playtests and more about Gdevelop. I really liked my group members and think they really pulled their weight on this project. Overall though it’s a little crude and might not have extensive amounts of content, I’m really happy with the prototype we produced, if only for the amount of time and care we put into the core movement, a philosophy I still stand by over shoving tons of content into a game with shallow controls. I’d like to thank my team, I’m proud of what we’ve accomplished and appreciate what I have learned. Developing Developer signing out for now.

Group Project Devlog 10 (Game Changes and Updates)

Ok. So I had practically one job to do: fix the reload message the player should display when their magazine is empty. I wanted the game to display “[R]eload” above the player when they ran out of bullets (putting square brackets around a letter is an old convention to suggest the player press that button), and while in last week’s tutorial and all yesterday I have tried to get it to work to no avail. I did not understand why: the events looked like they should have worked, I showed them to our programmer and he agreed that it looked good. Only once our programmer messed around with it for a while did he figure out the problem. Apparently in Gdevelop, square brackets are used for style tags, and so putting random square brackets into a string means it wont render on screen. This is the most Gdevelop problem I am yet to encounter in Gdevelop. A full day of work, only to find out my code was fine, I just hadn’t accounted for another Gdevelop quirk. 

Anyway it works now, and with that our game has made all of the suggested changes from the playtest, from here I’m largely in charge of collecting footage for and editing together a video documenting our game’s performance as well as a summary of the game’s premise and design.

Group Project Devlog 9 (Playtesting)

So after we ran the playtest we got a lot of really helpful feedback. Our level designer did us the colossal favor of recording it all in the relevant documents. The general feedback we got was that our concept was interesting and engaging, but our execution was sloppy in places (which is fair). Things like the physics feeling slippery at points, the player being able to slide off the screen, lack of polish in areas like prompting the player to reload when out of bullets and making sure the player re spawns with 0 velocity (instead of how much they died with, leading to them flying off stage).

These are all fairly easy fixes, for now I’ve been given the task of making the game prompt the player to press the [R] button to reload when empty, but I’ll get into that next week, for now I’m going into crunch time for about 3 other assignments over the weekend, I should be back by around Tuesday next week to make those changes though.

Group Project Devlog 8 (Reflection on Management)

I’ve finished up those level layouts our programmer needed and sent them through, and for now (until our playtest this weekend) that’s me up to date on work. I must say it has been very interesting working in a more managerial position this project. I feel a little bit guilty, I’ve ended up delegating a lot of things and the majority of my work so far (bar some programming) has boiled down to writing up timelines and Gantt charts and offering advice on the overall creative direction of the project - which I know is important, but answering questions and giving advice is definitely a lot easier than then going and doing that work. I think I’m going to try to do some of the writing up of the projects summary and maybe edit the video demonstration of our game to balance my workload out a bit compared to everyone else’s. Overall my group has been very accommodating and hard working and I am very happy with our progress. We have a playtest this weekend and I’m looking forward to it, it’ll mean we get to tweak parts of the game that are already implemented for one, rather than having to create things from scratch as we have been doing these last weeks. Plus it’ll be interesting to see what people think of our game.

Group Project Devlog 7 (Programming)

I’ve handed the code from the original Kickback (the first project I made during those early rapid development weeks). I’ve tried to make it as readable as possible with comments and consistent naming conventions but I’ve told him to ask if he can’t figure out what something does.

We’ve already made several refinements to the jump physics, chief among them being: we don’t need to use Godot's ‘physics’ behavior and can stick with the standard ‘platformer’ behavior because the platformer behavior has a weighted jump already built in. Let me restate that. The default behaviour that godot gives platforming characters, already has a weighted jump mechanic, i.e. pressing down lightly on the jump key produces a short jump and holding down produces a higher jump, i.e. the thing I spent literally a week trying to implement in Gdevelop’s physics engine when I first made this project and ultimately ending up with a more complicated, less effective implementation than the default. 

It’s fine. I’m fine. This was a valuable learning experience: thoroughly familiarize one’s self with one’s tools before launching into an overly complicated work around.

The player moves a lot more smoothly now, and we can edit their physics properties far more easily to boot. All that remains from here is for me to assist in the programming of some level layouts.

Group Project Devlog 6 (Art)

Our artist and I discussed our art style for the game and settled on something simple but effective. It’s a pretty cartoonist art style reminiscent of old flash games: the player is a stick figure, the guns and environments are clearly designed (if a bit crude). Given the tools and time we have available it seems like a practical compromise between making it clear to the player what they’re looking at, and having a standard of art that does not take too much time to produce in case we end up needing more assets.

Group Project Devlog 5 (Level Design pt. 2)

After brainstorming for a while and work shopping the levels we already have, myself and our level designer have come up with a ‘formula’ of sorts to follow when developing levels that makes them interesting and enjoyable without ballooning our scope too much.

1. Introduce a mechanic: In the early levels particularly this means just showing the player how the jump works for example, or that the recoil from their guns can bounce them around. Give the players a level that is fairly safe and simple to teach them the mechanic.

2. Build on the mechanic: Again, early on, this is largely about testing the player’s skill with their basic move-set, so we give them jumps at differing distances, heights and so on to get them familiar with the movement and how to use to to move different distances.

3. Finally, test mastery of that mechanic: This can either be by making a really tough challenge that demands extreme mastery over the mechanic, or by combining it with other mechanics that have themselves gone through the same cycle of introduction and development.

It’s really cool to be working on a project collaboratively like this. While I may be contributing some insight and opinions about the general philosophy I think we’d do well to follow in our design, our designer is putting in the effort to realize that and I’m very grateful. Plus, it’s really interesting to see how he interprets and philosophy, I feel he’s doing really well building upon mechanics in a way that feels satisfying and intuitive, and creates a natural feeling of progression.

Group Project Devlog 4 (Level Design pt.1)

This week I discussed the level design of our game heavily with our level designer. We are both of the opinion that our level design cannot be too expansive: levels must be relatively simple, and we cannot have to many of them. He has begun drawing up some plans for levels that fit these criteria, and we have resolved to discuss the examples he produces.

Group Project Devlog 3 (Pitch Submission)

I’ve finished up the Gant Chart that outlines what our (ideal) timeline looks like. We do have two weeks to playtest at the end of the project under ideal circumstances, this is good because either we’ll get to use it all and there won’t be a problem, or, if the project starts to run behind schedule, we have some time we can eat into. Our ‘pitch’ document contains both the gant chart and a variety of other useful information about the project, such as our group name, members, what resources we plan to use and so on. I’ll put the link to the document in our drive here, it’s basically a more advanced version of an elevator pitch:

https://docs.google.com/document/d/1JXg8cOsdTjGQbCIJQjXqRFZVbV8LKnxk4qp6j-BaLAM/edit?usp=sharing

Group Project Devlog 2 (Management)

I’ve sort of become the defacto project manager. Given that the game was my concept originally I suppose it makes sense - it has been an interesting role to fulfill. I certainly saw myself serving a role more as a programmer or something for this project but so far I’ve made very little game content besides the base game, I’ve mostly been drawing up Gant charts and timelines and checking in on everyone to make sure we’re progressing at a decent rate.

I’ve really liked checking in with the level designer in particular, talking to them about how we’re introducing mechanics, building on them, and then bringing them together with new mechanics. The programmer and I have been getting the jump and shoot physics into shape, as well as getting a few systems that will help us program future content into the game (a simple way to create new gun types as objects for example: all we need to put in is a list of values for stats like knockback and reload time and a sprite). The graphic designer has come up with some clever workarounds to animate each gun: namely having the arm and gun be their own sprite, and then layer them on top of the player and rotate them relative to the cursor position instead of having to animate each direction the player might aim.

I’ve never been massively interested in project management but to be honest this hasn’t been all that bad, so I’m interested to see how I go with this role as time progresses.

Group Project Devlog 1 (Brainstorming)

We’ve settled on some of the major ideas for the game. We want to have a fixed camera (Meatboy and Celeste style) that only tracks the player if the level is greater than the screen width, which will not often be the case. This keeps the level design compact and simple, which will help our scope not balloon too much. We still plan on making interesting, challenging levels, but given our time constraints we have to be smart with how we spend our time.

The level layout of the game will be 5ish levels (perhaps up to 7, depending on how long development takes) across 3 worlds, which gives us enough variety without taking too long to develop.

Group Project Start

We formed groups recently, and had to pick one of our collective previous projects to build on for our group one, and we’re going with my first concept: i.e. Kickback! I already have the majority of the early stuff (pitch, etc.) in this blog from my earlier posts, so I’ll just highlight any major changes in the next few posts.

Run Rabbit, Run Devlog 10 (Postmortem)

This project was not a complete success, but of all the games I have made it is certainly the most polished. I am particularly proud of the way I taught the player how to play the game, giving them scenarios where they could safely learn a mechanic before having to apply that knowledge in a difficult situation. The custom assets were a nice way to dip my toe into visual design with this final project, and they went down well I think, making the context of the game clear, and subtly hinting to the player what they should avoid, and what they should investigate. There are plenty of features I did not end up adding due to time constraints which isn’t ideal, but I think that overall this project served as the culmination of what I learned from all my earlier work, and was the most polished, well-balanced game I have made so far, and of that at the very least I am proud. Going forward I think having been able to test and successfully implement visual and tutorial design here will serve me well in the up-coming group project. In conclusion: not a total success, but a decent capstone to this series of rapid game development. Looking forward to the group project.

Run Rabbit, Run Devlog 9 (Re-Balancing)

I don’t have a lot of time left this week thanks to other commitments so I’m going to have to prioritise some features over others.

First off, most importantly, The RNG has been re-blananced. Now the carrots and rocks are more common, but the benefits and detriments they offer respectively have been lessened. This makes a run far less make-or-break depending on RNG, as before if a player did not find a carrot at the right time they were at a significant disadvantage, and at a significant advantage vice versa. Now the player can afford to miss a few more carrots, or hit a few more rocks, and on the flip side, it is harder to get so far forward that the run is unloseable.

The second major problem to deal with was the speed of the character, as they got far too fast without some form of speed cap, and objects would appear so quickly they could not be dodged. This was fairly simple, I simply put a hard limit on the player’s max speed and tested, tweaking it and testing until I was satisfied.

The game is far more consistent in difficulty now and while there are many systems I would have liked to have added on top of the game, such as more powerups and obstacles, I no longer have time.

Run Rabbit, Run Devlog 8 (Playtest)

This playtest went really well! The players thought my premise was interesting, and liked the custom art I’d made to bring it to life. Pretty much everything I put in worked as intended (not necessarily to the degree I would have liked - there are parts that still need improvement to work more effectively - but in general things worked as intended).

In particular, all those ‘teaching moments’ I had set up worked really well, most players found the control scheme intuitive (I bound up and down to both arrows and W and S to satisfy people used to either control scheme) and those that didn’t figured it out quickly after they lost their first run. The players gathered quickly that they were being chased and that the dogs were bad and that they had to avoid them, citing the fact that they were gaining on them slowly and ‘had red eyes’ so it looks like my visual design payed off which is good. The players also figured out that the carrots gave them a speed boost early on thank to there being one toward the start of runs.

All players said they though the progress bar was a very nice touch, as it gave them a sense of progression on each run as they made it further, and helped make it clear what their goal was.

There were two fairly consistent criticisms however: past a certain point, oncoming obstacles are moving too fast to dodge, and that the random generation either makes the game too easy or too hard and struggles to strike a middle ground. The ‘saving grace’ carrot would work in theory but because the player is often moving too fast to grab it, or (if they’re moving slow enough) the game can become predictable. The solution should be making the game cap off speed at a reasonable point, and also giving the random generation some balancing tweaks. The ‘saving grace’ carrot is a good idea, and lead to some legitimately tense moments where the player was about to get caught and survived because of a last-minute speed boost, and I like having something like that in there for the balancing and suspense reasons i discussed in the earlier post, but it definitely needs to be less predictable.

Other than that, the feedback was all fairly positive - “it’s have a good base, you just need to broaden the amount of content”: more power ups, more obstacles to complement said power ups, etc. One particularly good idea was to give the player the ability to jump using a powerup and giving them walls of rocks they have to jump using said powerup. I like this because its a neat relationship between two new pieces of content and also kind of works thematically given the player’s a rabbit.

Run Rabbit, Run Devlog 7 (Progress Bar)

This one will be quick. I just put in a rudimentary progress bar on the bottom of the screen that shows the player’s progress and a goal line at the end. This accomplishes two things, for one, it makes the player’s goal really clear without the need for text or a tutorial (which I like), and second of all, it helps give the player a sense of progress even when they fail.

Presenting your players with the opportunity to learn difficult skills is a challenge, but it is a hollow one unless you provide ample opportunity for them to master and display that skill. And remember, people do not master skills after five minutes of a tutorial. Learning a new skill often takes time and trials. Rewarding the player for sticking with it will make the process enjoyable. (Fullerton, T. 2018. Pg 350) [1]

Before the progress bar was present, it was incredibly discouraging to die halfway through the level with no idea how far one had made it through. With the progress bar, even if the player dies, they still get to see how far they made it, and this helps them stay motivated and feel like they’re progressing as they make it further through the level.  It reminds me a lot of a similar system in Cuphead where the player is shown how far they made it through a boss fight after dying, and showing the player that, even if they didn’t win, they did make it further, really helps motivate the player to keep trying, so I think something like that works well here.

Run Rabbit, Run Devlog 6 (Random Generation pt. 2)

I’ve set up the random generation fairly simply for now: every second the game generates two numbers between 0 and 1000, if if the first is greater than 900 a rock generates, if the second is greater, a carrot generates. There are two caveats to this system designed to balance it further. 1) Every second an object goes without being generated, the value the random number needs to be greater than is decreased by 25. For example, if four seconds pass and a carrot has not been generated, the value the random number needs to be greater than will have been lowered by 25 four times, down to 700. This makes it less likely for the player to go ages without seeing an obstacle or power up. 2) If the dogs get close enough to the player, what I call a  ‘saving grace carrot’ will generate. I found that the above algorithm, though it was more balanced than rng that maintained a consistent probability of generating an object, was still a bit unfair, the player would still often end up in situations where they simply weren’t given enough carrots to make it to the end of the race. So, I made it so that if they are about to be caught, they get one last chance to evade capture. This both balances the game, and also has the potential to produce some really great moments of tension and release where the player gets very close to being caught, but barely manages to escape. The one down side is that it can become a little bit predictable, and if player figure out that the mechanic exists it can be easily abused. I plan on making changes to these systems, but for now, as proof of concepts for use in the playtest I think they will be sufficient.