harrisonfletcherqut

[harrisonfletcherqut]

Week 12 & 13 - Final Update / Post-Mortem

This will likely be a large post as it covers two weeks that comprised of a lot of work though I’ll try and summarize as best I can.

Update 3

After the initial playtests Tom and I got to work on an update that would finally fix the swing mechanic, the pathfinding and address some other issues brought up by playtesting.

Tom got to work on the swing mechanic, and finally figured out the issue on why it sucked. Turns out that the swing hitbox was always spawning in the same location on the player. By that I mean that the box “center” point was at the top left which meant that when it was spawning at the players 0, 0 position it only worked if they were facing diagonally downwards. I went in and changed the swingbox points and finally it worked correctly. Well, it was still a little janky but far better than before. I decided to also the size and increase the time before the swing hit is deleted.

Tom also implemented a pathfinding system using GDevelops built in pathfinding behaviour. Unfortunately this pathfinding is extremely resource heavy on the engine and sends the game into a 5fps seizure at random points. Eventually I figured out I could improve the performance by a substantial amount by implementing a function that stopped pathfinding from working every frame, and instead only activated it every second. This was definitely playable but had occasional frame skips and lag spikes. Enemies would also behave slightly odd in the time between seconds. We decided that a smooth non-lagging experience was better than a game with pathfinding that performs badly so eventually we gave up on implementing it when we couldn’t get the performance fixed.

Based on the playtest findings I implemented a few fixes like the enemies bouncing off of the player when they hit to keep them from bunching up at the same poisition as the player. For some reason if a player stayed still they would only get hit once, and after that they weren’t able to be hit again by the same enemy until either they or the enemy moved. I also decided to give the enemies collision with each other so they wouldn’t move.

I forgot to mention in the last post that we implemented a basic score system. 20 points are given for killing a basic enemy and as far as this update was concerned, that was still the only way to increase points.

More Playtests and Update 4

I believe there was only one playtest between Update 3 and Update 4, though it didn’t have too much extra to offer that we hadn’t already heard from the original playtests. One thing I’m glad about with these playtests is that everyone seems to be happy with the game overall and find it fun. I’m also glad people have enjoyed the pixel art style. Other than that a major problem being brought up in playtests was still that you could cheese the game in many areas of the map and not have enemies reach you. I do believe that this was helped a lot in this update with the introduction of enemy 3.

Enemy 3 has the most complex behaviour out of all enemies. They’ll only follow the player up until a certain range, when the player is in that range, the enemy will hurl an empty can at the player at a high speed. Originally I decided that a well lined up swing would destroy the can but this was changed in the final update to something more fun. Enemy 3 also has a health of 30 compared to the health of 3 that the basic enemy has. After we playtested with the new enemy in place a complaint was that it wasn’t satisfying to defeat the enemy, and that they were expecting more. Though the third enemy does grant a large increase in points (200) I agreed that it was pretty unsatisfying to finally defeat him. Overall this enemy took far less time to implement than I actually expected, and despite the complaint about the reward for taking him down I’m glad it turned out well.

Another major addition in this update were powerups.

Tom implemented a simple system to spawn a powerup after a certain amount of time and also give the player an increased fire rate on their Dingle Fling ability for a certain amount of time. This was a good start but two more powerups needed to be implemented, and they also needed to have a system in place where they would spawn randomly around the map.

After literal hours of trying, I could not get a randomized time for the powerups to work, instead I had to come up with an alternate system for spawning powerups which I think ended up working well.

The system works by randomising a number between one and three every time a powerup needs to spawn. This number will determine which lane the powerup will be spawning in. The powerup is then given a random position inside that lane, and stays for a limited amount of time. I mentioned in an earlier post that a big problem with using GDevelop is the lack of good documentation and tutorials compared to what you’d find with something like Unity, Unreal or Godot. I searched for along time trying to find an answer to how to randomise time, but nothing helped.

Another big addition in this update was the difficulty system by Tom. He implemented a system where every 30 seconds each spawn point would spawn an additional enemy up to a total increase of 4. This system worked really well and I didn't feel the need to tweak it in the slightest.

After this update, the game was finally in a really good state and was generally well received by the final playtests.

Update 5 (Final)

While Tanaporn and Ahmed were busy with the report I decided to whip up a fifth and final update. This update was far smaller but had some nice final additions. I decided to quickly address the complaint about the reward after defeating the final enemy and implemented a powerup drop on his defeat. I also created one of the most fun abilities in the game which was the ability to whack enemy 3′s can right back at him. This would do 10 damage each, and was a fun but challenging way to quickly disperse of the enemy. I went and found some additional sound effects for whacking the can and picking up the fire rate powerup as well as some other additional sounds. I was going to implement a footstep sound for the player but I found this was really distracting.

There were still a few final bugs and changes that didn’t get addressed such as a complaint the shopping cart warning sound played too late. Overall I’m really happy with what we got done.

The Video

The only thing left I had to do was a video / trailer for the game. I decided to put my VFX diploma at work and get artsy with it. The idea was making it in the style of an old VHS tape advertisement with retro pop up cards explaining the game’s features. Since the game was so simple it really didn’t need to be a long video so I aimed for a nice 60 seconds. I really like how it turned out and I’m glad I was able to have fun with this.

https://www.youtube.com/watch?v=JdREbGeLk0k

IN CONCLUSION

I really enjoyed this assignment. At first I wasn’t a fan of GDevelop but I do appreciate it as a really simple engine anyone can easily make games with. My team members were a million times better than my last assessment so I also really appreciate that and I’m proud of what we got done.

[harrisonfletcherqut]

Week 11 - Playtesting and Development Progress 2

Supermarket Slugger now resembles an actual game, so that’s nice.

Tumblr has a hilariously low maximum file size for gifs so I had to absolutely butcher the quality here to be able to upload it. For some reason its also slightly sped up. This also doesn’t show off as much of the game as I wanted to.

The game has improved a lot over its initial version, and I’m pretty proud of how its shaping up. I spent a lot of time cranking out this big update before we were supposed to playtest. Also, I forgot to mention in the last post that we have a new group member, Tanaporn, who as well as Ahmed is less interested in the development side and prefers to mainly do the playtesting. This has worked fine for me since doing both full development work and playtesting would be a huge undertaking.

Gameplay & Design

The biggest change here is the layout of the level. Tom suggested to make it more non-symmetrical and after some thought and some testing I agreed. There’s an extra spawn for the first type of enemy up in the top left, which was definitely needed with the larger level size. Obviously there are lot more props, (which I’ll get more in to in the art section) that the player needs to navigate around. Mostly this update was about realising the original vision and trying to fix everything was broken (still plenty of broken stuff though). Most of the major work between the last post and now was done by me with some tweaks and bug crushing by Tom.

i did create a sprite for a double firerate powerup however did not get that implemented at all.

Art / Visuals

There are now about 40 unique assets in the game ranging from environment props to player and enemy sprites. Personally I’m most proud of the fridges I think I did the light reflection and items behind the glass pretty well. I’ve enjoyed making pixel art and I’ve gotten a lot better over the course of this unit. I do still wish I could update the player and enemy sprites but I’m now confident I won’t have time to. To be honest though, I’ve gotten used to the old sprites and they seem like less of a problem to me now. I’ve also split certain sprites slightly at the top and removed collision so that the player could move through them for a little more realism.

Sound

This update also brought sound to the game. I tasked Ahmed with finding sound effects and music for the game and I implemented the ones I liked best into GDevelop.

Bugs, Issues & Things That Need Implementing

I haven’t really run into any new bugs and issues but still have plenty of major existing ones that I’ll list out.

Swing - still broken.

Enemy pathfinding - still sucks.

Powerups - still nonexistent

Difficulty is still very static and has no gradual increase

PLAYTESTING

We don’t have as much playtests as we probably should at this point, but they have included some useful feedback. Mostly it was the major stuff that we already knew were issues, but the script/survey that was written up by Tanaporn had some interesting questions that led to some good insight.

The main problem seems to be the playtesters eventually finding out they could find certain areas where enemies just wouldn’t reach them because of the non-existent pathfinding.

One thing I also didn’t take into account with the new update was the fact that we weren’t supposed to tell them how to play the game, so my lack of any tutorial was a bit of a problem. Luckily the controls are incredibly simple and they were able to figure it out without much difficulty.

There are a few other tweaks and changes that will be easier address in a coming update.

Future Goals

Other than finishing up the game, there’s more playtesting to do, a document report, and finally a video (which I’ll be doing).

The main development goals going forward are the pathfinding, the swing mechanic, and the third enemy. I also still need to implement a new game over screen with a tutorial.

[harrisonfletcherqut]

Week 10 - Assignment 3 Development Progress

Supermarket Slugger is wheeling its way into a very playable state. I’ll break this post down into a few sections to show where the game is at.

Art / Visuals

I’ll talk art first since it’s what has been worked on the most so far. This week I’ve been hard at work making assets for the game, mostly environmental props. The layout isn’t finalised but here is how the new environment is looking so far:

Obviously, the map is much bigger, but there are the same amount of enemy spawns and overall, the environment is a similar layout to what was in the first version, just larger and far better looking. I don’t have a comprehensive list of all assets and props planned but I do have plenty of potential ideas. Here’s a few:

Butcher / meat section

Slurpee machine

A shorter fridge with the door on the top. I have no idea what that’s actually called.

Plants and floor signs

Signs for naming different sections of the map, hanging from the ceiling (this would need some kind of slight parallax effect to look natural)

A display for Dingles’ Chips, where all the cans are sold out.

So far I have an entry gate but I’m planning on an exit gate as well and will have these open up when enemies walk through them.

A shopping cart section.

In the development post for the first version of the game I talked about the issue with using characters with a different view angle than the environment. As can be seen in the image I’ve decided that the new environment won’t have props with half the traditional angle and half a bird’s eye view. I do want to update the player and enemies with better sprites that fit the environment but that is a big undertaking and will likely take the same amount of time as all the environment props.

Gameplay & Design

So far, I haven’t gone too deep into extra ideas and have mostly focused on fixing what was already in the game and implementing features that I had already planned but missed last time. There are also little tweaks to gameplay here and there that I would just implement as I thought of them since they were easy. For example, I made it that the shopping cart enemy can actually kill the normal enemies when they plow through the level. Going from first thought to implementing it took about a minute or two and simple changes like that all together go a long way to making the game play better.

There is one feature that was not planned for the original game that I now feel will be a necessary addition – a third enemy. So far only two enemies exist, and one of them is only seen on screen for a maximum of three or four seconds. To me it became somewhat boring to play with only one main enemy and I feel after a minute or so of game time the player should be surprised with a boss type enemy to throw down with. I’ve decided that this should be a larger enemy that throws bits and pieces of garbage and empty boxes and cans at you.

In my opinion the most important thing right now (apart from the swing mechanic) is the new environment. The old environment gets boring FAST and I wanted to ensure the new level was large enough to not get bored of so quickly. To go along with the new environment, I’ve zoomed in the camera to move with the player and stop at the map boundaries. In the original game I had no idea how to implement this since I had everything on different layers and introducing a moving camera broke everything. I found out that I was implementing this completely wrong and that everything in the environment should be on the same layer, just with different Z-orders to move them behind and in front of each other. Already I think this has made a huge difference in gameplay feel. It also brings anew challenge in that the player can’t see everything on the map at once, and is more inclined to move around the map.

Bugs and Issues

One issue that still hasn’t been fixed is the pathfinding for enemies. The reason enemies get stuck on objects frequently is because there’s nothing telling them to navigate around, only a collision detection to stop them from walking through an object. Something I didn’t actually notice until recently was the pathfinding behaviour tools in GDevelop. Tom is looking into this soon and will implement it if it works. For the previously mentioned swing mechanic, the only things I’ve done to try and fix this was simply doubling the size of the swing hitbox and making it more forgiving when facing multiple enemies. So far, the system is actually identical to the system that fires chips out of the can. A large invisible square is spawned on the left click and moves forward for about a second until a timer runs out and deletes it. Originally the box would delete when in contact with an enemy, but this became a problem when facing multiple enemies, as the box could only take out one at a time. Changing these simple elements made the swing mechanic far more responsive but unfortunately, it’s still too difficult to use in game effectively. I don’t actually know what the problem is with this, as in my head it SHOULD be working perfectly. Sometimes the mechanic works well, other times it fails completely and gets the player killed. Tom had a look at this but also could not figure out the problem. Once again this is a major entry on the priorities list.

There was also an unintentional “feature” of the original game where you could shoot and swing at the same time essentially making you an unstoppable killing machine to anything in front of you. I wasn’t even aware of this until Tom played the game, and I likely never would have attempted it which does show the value of playtests and the things they can reveal. Tom went ahead and fixed this issue and cleaned up the spaghetti platter that was my event system.

Goals for Next Week

The update I plan to have finished by next week is big and is a major improvement over the original game. So far, I think I’m on track to finish it before playtesting starts. About half of the environment props still need to be made, and many more features need to be implemented.

Thoughts On the Textbook and Influence

The most influential element the textbook (Game Design Workshop by Tracy Fullerton) has had on the game is where I’ve been implementing risk vs reward mechanics. Mostly this has been with where powerups will spawn. There will be three locations for powerup spawns. The first of these being randomly around the map in the line of sight of the shopping carts. Secondly, the self serve section will have a powerup spawn regularly. This section is a small enclosed area with an enemy spawn inside of it, so its a dangerous risk to go, as the player will be able to get swarmed on both sides with no escape. Thirdly I’ve also decided that either the shopping carts or the un-made third enemy will drop a powerup on death. If the player wants to avoid these enemies, they can, but they’re risking losing out on a powerful reward and a significant increase in score points.

Another section of the textbook I’m taking a lot of inspiration from is the section on fun and accessibility (chapter 11). I’ve tried to keep controls as simple as possible, without adding any unnecessary complications. Another goal is that any player can very quickly pick up the game and understand it and have fun without needing to play for any significant amount of time. Though we haven’t had any official “blind” playtests yet I’ve tested it with a few friends who enjoyed it and found the game fun with just the right amount of challenge. If what we have so far is already fun then I’m confident the final product will turn out well in that regard.

References:

Fullerton, T. (2019) Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

[harrisonfletcherqut]

Week 9 - Group Formation and Assignment 3 Team Discussion

This is a far shorter post than usual, but Assignment 3 is looking to be a big undertaking. I’ve formed a group with a friend (Ahmed) and some random guy who posted about needing a group (Tom). I had a bad experience with my group project from another unit last semester where some hip-hop dancing 17-year-old youth pastor decided to lead the project off a cliff with terrible ideas, so I was determined to be the main decision maker of this group. Because obviously, my ideas are perfect always. We actually did have someone else before Tom, but they left since they were stuck on doing their own idea for the assignment which I understood. With my impeccable people skills I was able to convince everyone to run with my game idea (Supermarket Slugger). So far, my group is already infinitely better than last time, and I have no doubt we’ll be able to put something really cool together. However, as I mentioned there is quite a lot to do. So far we’ve figured that Tom and I will do most of the work in GDevelop while Ahmed will do most of the playtesting, then we’ll all do the final report equally.

[harrisonfletcherqut]

Week 8 – Dustblood Post-Mortem, Assignment 2 Final Design

Dustblood

Last week’s predictions on me not getting this thing done turned out to be… completely correct. Dustblood did not even come close to a playable prototype. I did some more work in Photoshop and got a layout of a track done but that was essentially it.

Though you can’t see in this photo, I designed the track to be modular so I could edit it and make new ones if I had the time (I wouldn’t). I also shaved the potential enemy cars down to three since I started to realise I had almost no time to get anything substantial done. The plan was to have the track looking like a thunderdome right out of some cheesy sci-fi action movie from the 80s-90s, with bones, bodies and garbage thrown across the level.

As far as gameplay mechanics go the plan was to give the player a standard machine gun ability used by clicking the left mouse and a second ability that was gained by picking up powerups (Mario Kart style). The second ability would be used with the right click and the mouse would also be used to aim. Some weapons I thought of were a multi rocket launcher, a cluster bomb that is dropped behind the vehicle instead of shot out from any direction, a lock on laser gun with one powerful shot, and finally an ability that would drop flames from the tires and create deadly walls of fire for any enemies behind the player. Unfortunately these ideas are mostly all I have, since nothing substantial got done in GDevelop. I have warmed up to the idea quite a lot though, and might attempt this over the holiday break.

Assignment 2 Final Design

In other news, I finished assignment 2, and I’m really happy with how it turned out.

This covers mostly everything about the game, and I feel like any designer would be able to pretty easily make a game based on this. Once again, the “gameplay” image is kind of misleading since it was composed in Photoshop and has additional features presented that were never in the original game. I kept with the aesthetic of the first page, but had to tone down the worn look since it started to interfere with the smaller, more extensive paragraphs. Overall, I’m happy with what I got done for this assignment and I think it turned out really well.

[harrisonfletcherqut]

Week 7 - Dustblood Development, Assignment 2 Progress

Dustblood

So I’ve taken a bit of a step back from the output from last week. This week I’ve had to focus a lot more on other assignments for both this unit and others, so I’ve essentially given myself no time to do this. I’m not sure how much I will get done but it’s unlikely I will have a significant amount of progress by the next post-mortem. Though I haven’t done much I will share what I have so far on my perfectly legal copy of Photoshop. Once again I prefer to start by making basic visuals since spending time making basic shapes move around hurts my brain and eyes.

Here’s a little car. It has guns. That wasn’t cool enough though, so I also added a skull. Now it looks like something someone with a Fast and Furious tattoo and a Facebook profile picture with them holding up a fish would dream of when they fall asleep.

Here’s another car. This one is less cool, and also not finished. I want to put a mounted turret on the back and possibly change the colour.

Anyways, that’s kind of all I have so far. All my other assignments have been creeping up on me and I just haven’t dedicated as much time to this as I’d like to.

Speaking of assignments…

Assignment 2 Progress

For the second assessment piece of IGB220 we’re taking one of these short game concepts and making a ‘one-page’ pitch. This essentially just givse the basics of what the game is and how it works. There is also a second part to this, a ‘one-sheet’, that goes into detail about the game mechanics so that any designer could easily work off of it. We’ll then be using these to make a game with a group later on in the semester. I decided to go with the only game that I have actually finished so far, Supermarket Slugger.

So far, I have the ‘one sheet’ done. I decided to go all artistic with it and pretended like it was a page ripped out of some old magazine that was found in a gutter.

I decided to switch out any mention of Pringles with a fake company called Dingles which I think was the right decision since it just sounds absolutely hilarious. The guy “battering up” on the right side was a pain to draw since I’m new at pixel art and this was far larger than any 16x16 or 32x32 sprite and required a lot more detail. The in game images on the left are also somewhat fake since I just composed scenes that looked like gameplay in Photoshop and used those (there is no score system in the game but it’s shown in the image). I enjoyed making this since it had a lot of room for me to have fun with it and do something whacky.

I do like using Photoshop quite a bit and I’m glad that the Diploma that I learnt it in isn’t going to waste. The image uses a few different blending techniques to get that ‘old’ feel such as the grunge paper texture and film grain blended over the top of the layers. I also purposely faded out the image a bit so it looked like it’s been sitting in the sun a little too long. The colour palette was also purposefully chosen to feel like something you’d see on a soda can from the 90s.

The more game design focused “one-page” is going to keep this aesthetic despite being far more detailed.

[harrisonfletcherqut]

Week 6 - Supermarket Slugger Post-Mortem and Dustblood Pitch

Supermarket Slugger is done. Sort of. I did try and get some playtesting done but despite me posting a link to the game on the class discord I did not get any feedback for the game. In the absence of other people’s playtesting notes I’ll just talk about my problems with it and what I think should be revised if I spend any more time on this thing.

The biggest problem by far is the broken swing mechanic. The game is called Supermarket SLUGGER but so far you still cannot actually slug anyone with the Pringles can. I spent quite a bit of time trying to figure this out to no avail. There were probably a million ways to go about doing something like this, but I just couldn’t figure it out. Essentially the game is only playable as a Pringle themed shooter. Enemies still get stuck on walls but since the map is so small it’s only noticeable if you stay still in an area, since there are certain areas where all enemies will get stuck and not reach the player. As I mentioned in the previous post, I was inspired by the risk/reward section in Chapter 5 of the textbook Game Design Workshop by Tracy Fullerton. I tried to implement this with powerups, where they would only spawn in the way of shopping carts that came speeding through the level. Unfortunately, I never got powerups working so that system didn’t come to fruition. Obviously, the game is very bare-bones, and there are plenty of things that can be added such as powerups and more enemy types. Some kind of gradual increase in difficulty would also be up on the list of essential updates. Overall, I think the concept is good and though the ‘final’ product is very basic I have a lot of ideas to expand on it. I learnt a lot about Gdevelop with this project and I’m warming up to the engine quite a lot.

Anyways, here’s my pitch for the third and final mini game - an apocalyptic racer that I decided to give the most generic name I could think of…

The Elevator Pitch

Title: DUSTBLOOD

Pitch: A combat racing game set in an apocalyptic desert where if your opponents gain the lead on you, blow them up.

Controls:

W, S – Accelerate, Decelerate

A, D – Turn Left, Turn Right

Space – Nitro boost

Left Mouse – Ability 1

Right Mouse – Ability 2

3 Selling Points:

Challenging competitive racing

Violent explosions and destruction

More violent explosions and destruction (there will be a lot)  

General Gameplay Notes:

No detailed mock-up image this time but here are a few gameplay ideas have so far:

4 enemy AI drivers. Each with a unique vehicle and weapon. They’ll also each have unique behavior like the Pac-Man ghosts (a link to some info on this is posted in the references section below). So far I’ve decided that one car will be aggressive and focus only on blowing you up, one will focus only on winning the race and will be harder to overtake, one will do both of these things to lesser degrees and the last car will simply just suck at everything and will most likely come last in every game unless the player is especially bad.

The camera is top down but will follow and rotate with the car instead of seeing the entire map at once.

The track will be broken up into ‘lanes’ that can be switched to instead of one big road.

Audience / Demographics

This project would be aimed at a similar demographic to Supermarket Slugger, where though it may be violent, the pixel art style makes it a far cry from any kind of graphic violence you’d see in a real commercial game. Obviously, this project would be aimed at fans of racing games, though since I myself am not much of a racing game fan I would want to keep it simple and interesting enough to appeal to people like me. An age range for this project would probably be for around 10 and up. There won’t be any gore, but I’m hoping to have some nice-looking destruction sprites.

References:

Fullerton, T. (2019) Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

Pittman, J. The Pac-Man Dossier. Gamasutra. Available at: https://www.gamasutra.com/view/feature/3938/the_pacman_dossier.php?print=1

[harrisonfletcherqut]

Week 4 - Supermarket Slugger (development)

I told someone about my game idea and now I feel I should clarify something. No, this game is not about throwing or being a slug. Slug can ALSO mean hit something. Hard. For example, using a pringles can as a baseball bat to brutalize hungry shoppers in a supermarket. With that out of the way, here’s the progress I’ve made so far:

Once again, I started development with my game on the most important aspect of game design – art.

That was a joke, but yes I did start with the art again. Doing some initial art first gives me a better idea of what I’m doing. It’s not incredibly fun playing with basic shapes and really, fun is the ultimate factor on how engaged I am with development. Things go slow when I’m bored and I get distracted easily. Anyways, all assets in the game are done by me on a totally legitimate copy of Photoshop. It’s basic, but this is mostly all I have so far:

There are only four basic assets for the environment right now, that being the shelves, tiled floor, walls, and some shadows for the doors and shelves. The tiles were originally grey but it made the shelves and player character kind of hard to see so I slapped a green tint on it and called it a day. I do plan on adding more detail but its low on the priorities list as I have very little time left for this. The map is in desperate need of some random background elements like a few items left on shelves or scattered around the floor. Anyways, it’s hard for me to describe how annoying it was to create the player character’s sprites, but I’ll give it my best shot:

It sucked.

In more detail though, “top-down” pixel art is usually drawn at an angle as not to lose detail. It’s near impossible to discern what items, buildings, or characters are when you’re viewing it from directly above. Here’s an example of the usual angle of top down pixel art games:

(Stardew Valley, 2016)

The reason I decided to make the player character purely top down was because I didn’t want to draw a bunch of different angles / poses for all animations. Just simply turning the character in full 360 degrees with the mouse seemed a lot easier. Unfortunately I ran into a lot of trouble just trying to make the character look convincing in its sprites. It was pretty much impossible trying to make a flat, top down character with convincing depth, scale and curve in the arms all in a working area of around 20 by 28 pixels. I did take some reference images to help out:

(I took a lot more but these are the least awkward ones)

The reference images helped somewhat but not as much as I had hoped. Once again there’s only so much you can do when you’re starved for pixels. As well as all that, the top-down player character didn’t really match the angled environment at all. I had to alter all the art to half their original vertical size as to try and make everything fit together more aesthetically. There was only so much that could be done however, and though I don’t think it looks too bad, I would definitely do it the traditional way given more time. Here’s the basic gameplay so far in a super low quality GIF:

As you can see the two main enemies are in place and working. Just getting collision to work with the basic enemy type was incredibly time consuming, and for a long while they were just sliding right through the shelves. The only real problem with them now is that they really love sticking to walls and shelves if they’re in between the player and them. I don’t have much time left but high on the final features priority list would be something to move them around obstacles. The weaponized shopping trolleys were easy, they just spawn every so often with a fast force, and if they hit the player its an instant kill. So far the carts on the side are fairly useless as there’s no real incentive for the player to move away from the middle of the map. This is where I wanted the power-ups to come into play as a risk vs reward system. The risk being standing around in an area where you can get run over by a shopping trolley, and the reward being a big bonus for your attack. Not a priority but would go a long way to making the game feel more realized.

Normal enemies take three pringle chips to kill which after playing around for a while I felt was the most balanced amount. The biggest problem so far is that one of the two main attacks, the can whack, doesn’t actually work at all. The animation plays, but every time I’ve tried to have it deal damage it has broken the game. This is definitely the top priority going forward since the entire game is named after whacking people with the can. There are a few other extras I want to implement if I have time such as a damage indicator on both the enemies and the player. I already have versions of the sprites with a red tint to indicate the damage but for whatever reason I haven’t been able to find a way to properly implement this yet. I would also like to change the camera so that its slightly zoomed in and moves around with the player inside the boundary of the map. I feel like this would make the game look better and bring a slight extra challenge when you can’t see the entire map at all times. I did attempt this earlier in development but something went wrong with the layer system and broke the camera. Also worth fixing is the awful HUD in the top left.

I think that’s it? Again most main features are implemented apart from the can whack attack. After that its just making the game look better visually and implementing extra features.

[harrisonfletcherqut]

WEEK 3 - Supermarket Slugger (Pitch)

For the second game in the IGB220 unit, we’re making an ‘asteroids’ game. Though there is a template for a small asteroids game available, I likely won’t be using it. I would get bored just doing a carbon copy of asteroids, so the plan is to do something that is at least very different aesthetically. That means swapping out the whole ‘space’ thing for something else. For some reason I seem to decide on an idea depending on how proud I am of the title I came up with and not actually what the idea is. So yes, I have another idea for a game, and yes, I am very proud of the fitting title. Anyways, here’s the pitch for Supermarket Slugger.

The Elevator Pitch

Title: Supermarket Slugger

Pitch:

Asteroids but instead of being a spaceship in space shooting frozen rocks you’re a guy with the last can of Pringles at an empty supermarket. Survive.

Controls:

WASD – Movement, obviously.

Left Mouse – THE CAN WHACK: Whack incoming shoppers with your pringles can. Batter up.

Right Mouse – THE PRINGLE FLING: Fling pringle chips at terminal velocity towards your enemies.

3 Selling Points:

·         Endless action (woah)

·         Weaponised shopping trollies (woah x2)

·         Pringles? Idk why that would excite you but if it does you’re welcome

Mockup:

Arrows indicate enemy spawn points, boxes are supermarket shelves

General Gameplay notes:

·         16-bit pixel art. Again.

·         UI elements: Time, Health.

·         Powerup to double the amount of Pringles thrown like ninja stars.

·         A heavy enemy that flies by the screen in a shopping cart and can run you over

·         Theoretically this shouldn’t be all that different than asteroids gameplay wise.

·         Might have to rename Pringle to something slightly less heavily copywritten. Perhaps Dingles.

Contact Info

Email: HarrisonFletcher@outlook.com

Student Number: 10690433

[harrisonfletcherqut]

WEEK 2 - VICE VERTICAL (POST-MORTEM)

I’m very proud of the title Vice Vertical by the way.

So yeah this could have gone a little better. For whatever reason I thought I had three weeks to do this when in reality I had two. I got to class and it turned out I had to have something playable by midnight which was a bit of a problem since I had essentially nothing. The previous night I had drawn some pixel art to use as the sprites for the game and composed a concept mock-up image in Photoshop to get a basic idea of what I wanted the game to look like but that was it.

Yes I stole a Contra sprite.

Anyways, this concept was missing quite a few things, mainly the background and a building that didn’t look like it was under construction. Since I had a pretty clear vision in my head of what the game should like I found it near impossible to find free sprites and art that matched that. So, I figured it might actually be quicker to draw the assets myself. Plus its fun.

Here’s all the sprites used in the final product that I had made myself:

Pictured below is the palm tree I used (not made by me). I had nowhere near enough time to make my own and this one was pretty close to what I wanted. The color of the original didn’t fit the aesthetic all that well however so I had to recolor it.

The only other assets I didn’t make myself were the explosion and the clouds used for the background.

Thoughts On GDevelop

I think I forgot to give some context about the game engine in my last post. The engine we’re using is called GDevelop. Basically it’s a free game engine catering to people that want to make games but don’t know how to code. Instead of code it has this whole drag and drop condition/event system that is far easier to understand than traditional programming. The problem with this is that you can never really make anything all that complex. The engine is incredibly limited, and your game ideas have to be veeeeeerry basic. It also doesn’t help that there’s not a whole lot of tutorials out there since its a largely unknown engine. Despite that though, I don’t mind it. For these basic games its totally acceptable.

Design Changes

Anyways, there were some design changes that were made when I finally got into real development. The biggest one being that instead of just having an elevator shaft on the left side, the right would have one too. This gave the game a slight bump in gameplay flexibility since you’re not just locked to jumping on one side. Also it made the falling elevator mechanic more forgiving since instead of having to wait for it to pass you can just run to the other side and jump there.

What Didn’t Get In

Since my brain had a bit of a special moment and I ended up only giving myself a day to finish this, there were quite a few things that didn’t get in:

The actual main character. I didn’t have enough time to draw a running character animation so instead of a super buff action star guy, you play a red rectangle.

Combat. This was a big one. I didn’t have enough time to get combat done so that entire aspect is missing from the game. No enemies exist apart from the falling elevators.

Sliding. The mechanic of sliding under tables or through the legs of bad guys also didn’t make it in. I was actually close to figuring this out but when I started testing it it just started breaking the entire game so it just wasn’t finished. The only table asset I made was reduced to just being a background element with no collision.

UI elements. No UI elements exist so its hard to tell what floor you’re actually on.

The background. Originally I wanted a very detailed background that would start as a sunset over city buildings and eventually become night the higher you got. This didn’t happen.

Being endless. The game is not actually technically endless. I wanted the floors to be randomly generated and infinite, instead, I just premade a bunch of floors and set every single element in the scene apart from the player and the explosion to fall down at a certain speed. This still gave the illusion that the player and the explosion were moving up. Honestly this worked fine for just the simple level the game ended up being.

Under the Hood

Here’s the full event system for the entire game:

I think it does show GDevelop’s strength in that this one page is literally all I needed to make the game I ended up with. The big group of text near the bottom is a list of the objects being given a permanent force downwards at a certain speed. As stated before this is just everything but the player and the explosions.

Also worth showing are the elevators:

None of this is ever seen by the player but the elevators are just suspended above the tower. When the game starts the elevators fall at a speed faster than anything else in the game, so they’ll appear as if they are just falling naturally.

The Final Product & Feedback

So here it is. All I got. For what is essentially two days work I don’t think its all that bad. It’s missing 75% of the planned features but yknow... could be worse.

Originally I posted the game without really testing it which was a mistake since it turned out to be incredibly hard. The feedback I got stated the difficulty as the main criticism though there were also some useful gameplay ideas such as adding holes in the floor to jump through. I wasn’t really doing anything at the time so I quickly went back into photoshop, made a ladder, then went into GDevelop and added in the ladder holes on a few platforms. This went a long way to making the game easier. Another suggestion was reducing the size of the explosions since in the original version they were taking up almost half the screen. Quickly fixing these two issues I re-uploaded a much easier (and more fun) version of the game which is seen in the potato-quality GIF above.

Conclusions

Overall I’m satisfied with what I got done in such a short time. I learnt a lot about GDevelop along the way and I’m excited to move on to the next project. A project which I will (hopefully) give myself a lot more time for.

I really like the idea of Vice Vertical and I would definitely like to complete the game at some point when I have free time. Making this was fun, and that's the most important thing to me.

[harrisonfletcherqut]

WEEK 1 - VICE VERTICAL

Do you like explosions? Ripped action heroes? 80s aesthetics? Japanese office buildings? Awesome. Go watch Die Hard.

If you like all of that but in the form of a video game however, here’s my elevator pitch for Vice Vertical.

The Elevator Pitch (with actual elevators)

Title: VICE VERTICAL

Main Pitch: An endless runner where you’re a generic 80′s action hero making your way up a Miami skyscraper with a perpetual explosion behind you. On your way, avoid falling elevators and white-suited drug runners looking to turn you into a fine red paste.

Mockup and Gameplay

Here’s a very difficult to see mockup I did on some graph paper outlining roughly what the game would look like and some key features and details.

The entire game is just going left to right jumping up to the floor above in order to escape the rising explosion. The movement system I worked out would be:

A / D - Left and right movement

S - Slide (used for sliding under obstacles, used with A or D)

Space - Jump (obviously)

Mouse - Aiming

Left Mouse Click - Fire ridiculously oversized machine gun

General gameplay notes:

The game follows a 16bit retro art-style.

The only UI elements would be the health bar, current floor number and time (maybe).

The player is 16x32, and each floor would be slightly more than double that size.

Normal enemies are also 16x32, and will remain stationary instead of moving around the floors.

Every so often an elevator will rise from the explosion, the doors will open, and a shirtless buff guy will fire a minigun at you. This ‘nemesis’ will follow you up until you shoot him enough to crash the elevator back down. The player can never fully kill him, and he shows up at completely random times.

The background is an important part of the game. Showing the outside makes the aesthetic more present and he parallax effect for all the elements in the background would give a sense of scope. After a certain amount of time, the player would pass all the buildings and only see clouds until literally reaching outer space. 

3 Selling Points

Explosions

Fast paced, challenging run and gun gameplay

Retro Miami aesthetic 

Contact Info

Email: HarrisonFletcher@outlook.com

Student Number: 10690433

[harrisonfletcherqut]

Obligatory About Me Post

Intro

This is an about me post about me, Harrison Fletcher - student at the Queensland University of Technology in Australia. For the IGB220 class, a Tumblr is required to catalog all the stuff we make (or half-make). So here it is, being all required and such.

Aims and Objectives for this Unit

For this class all I’m looking to achieve is a further understanding of game design and how to concept, design, and finish a game in a strict time-frame. I’m not all that great at sticking to a project, whatever it may be, and actually finishing it. So hopefully the due dates of a University class will help with that.

Interests in Games and Other Fun Stuff

I like Star Trek, Joss Whedon shows from 1997 to 2004, and unsurprisingly, I love video games. So much so that I actually want to be one of those poor chaps that sits at a computer for 12 hours a day and makes them.

I have a Diploma of Screen & Media (Visual Effects & Animation) collecting dust that I did after High School. Originally I wanted to be a filmmaker and decided to do that Diploma and use it as a bridge to get into a film course at University. While doing the CGI work in the Diploma I discovered I had a genuine love of 3D modelling and designing digital environments so yeah, short story short I realized that despite my love of film I didn’t actually want to work in that industry, I wanted to make video games. So, here I am.

Personally I’d love to make games in most kinds of genres but I have a particular love for role playing games. I have a big ol’ folder of ideas and detailed documents for various types of games so hopefully one day I’ll get to yknow... make some of them.

Anyways, here are my two favorite games:

MASS EFFECT (2007)

When the credits rolled on my first playthrough of Mass Effect and that slightly out of place alt-rock song started playing it hit me somewhere deep. Possibly the spleen. I’d never played any game like it, and I doubt any game in the future will hit me quite like that again. This is the game that made me realize video games could be more than just push forward, jump and punch that brick for a performance altering mushroom.

AGE OF EMPIRES 2 (1999)

Age of Empires 2 is one of those games that is just kind of perfect in every way. My dad got this for free with his work laptop in 2007. I don’t know what kind of workplace would encourage not doing your spreadsheets but I’m glad they didn’t because 13 years later I’ve put thousands of hours into this game and have yet to be tired of it. I played it so much as a kid that when I wasn’t allowed to, I’d play a match against myself on the floor with pieces of paper with drawn soldiers and buildings.

While I’m at it here’s my top 5 favorite films:

Spider-Man 2 (2004)

Blade Runner (1982)

The Princess Bride (1987)

Blade Runner 2049 (2017)

A Knight’s Tale (2001)

In Conclusion I Guess

Yeah I don’t really know how to end this post so here’s some totally radicool tracks I’ve been listening to the past week:

Cocteau Twins - Cherry-coloured Funk

Splashh - All I Wanna Do

Wolf Parade - I’ll Believe In Anything

Clap Your Hands Say Yeah - In This Home On Ice

Red House Painters - Wop-A-Din-Din

[harrisonfletcherqut]

initializing...

whatup whatup