introduction:
My game demo has a design focus on the graphical limitations of the game boy advance, so the game should look like a Gameboy advance game although, it does not it does not play like it’s on the game boy advance due to the advanced keyboard and mouse controls. I had to use many different techniques in construct 3 to design the enemies and other mechanics in my game. The theme for my game is medieval fantasy, which suits the adventure style of my game, similar to the likes of many other top down adventure games.
player experience:
When someone plays my game I want them to feel like they are free to explore the open word in my game, considering it is a demo as well I wanted my game to feel as open world as I possibly could to invoke a feeling of adventure and freedom, as you would feel when playing games like: Skyrim or the legend of Zelda. I guess as well I want the player to feel powerful in my game as well, but still use the mechanics of blocking and attacking, otherwise they would die in my game.
evaluation: feedback
Strengths:
I found in my feedback that people really enjoyed the graphics in my game. Due to the graphics of my game is the design focus of my project it’s clear that I have tried my best to replicate graphical art styles of the game boy advance, and with the graphics being a highlighted strength from the feedback, proves that I have developed my art skills because in my last project people thought the graphics were a weakness in my project.
Another thing people enjoyed in my game was the mechanics, people found the combat and movement quite fun in my game, granted some thought it was hard to use, but they stated that they have rarely used mouse and keyboard to play video games, so that is justified. People might have found the gameplay in my game fun because of the way the player attacks the enemies, with their conjure abilities, (which suits the name and theme of my game), people could have found it fun because not a lot of games control like my game so I guess they liked it because it’s a new idea for top down adventure games, (mechanics wise).
Weaknesses:
From my feedback I found that some people said that there was no walking animations or that the animations for walking were bugged. The animations were not bugged but, in that version of the game if you tried to walk diagonally the player would have no animations because you don’t walk diagonally in my game, so there shouldn’t be any animations for the diagonally movement, but I fixed this issues, in the end.
Another issue people had with my game is that you don’t lose any gems when you die, I initially wanted to keep this feature so the game would become easier the more the player dies, but I found that if you died a lot you would just have too many gems, I also fixed this feature and the fix would be presented in the improvements part of the blog.
Improvements:
The diagonal movement fix: I fixed this issue people had with my game by making a bit of code that makes the animations play when the player are holding down the keys that usually would make the walk diagonally, I also had to make all the movement directions in my game to be in a specific group to fix this feature in my game.
The Gem issue: I fixed this issue by making the player lose 50% of the gems they picked up when they die, so the code was quite simple because you just have to divide the amount of gems by 2 in the code for the gems. Having the amount of gems be halved on death still lets the player keep some but, also doesn’t make the game too easy to store a lot of gems up.
graphics evaluation:
What went well:
I think the graphics in my game work very well. I believe this because of the way my design focus is the limitations of the Gameboy advances graphics, and also the feedback I have gotten from the play testing of my game. When design the graphics in my game I had to keep in mind the size of the screen and the pixel size of the graphics/assets, which in the end does make my game look more like a Gameboy advance game in my opinion. Also I think the animations in my game look really good as well, especially the player movement animations, which work quite well with the combat in my game.
What went wrong:
Sometimes due to the screen size of my game, some texture are changed/ warped in game, due to the size of the screen in pixels. I thought this would be an issues but it’s really just an issue for the smaller textures in my game, like the gems or projectiles the bow enemies shoot. Another thing that didn’t go to plan with the graphics was that sometimes the player would appear a bit jittery or blurry due to the fact that it was pinned to another object so I could have it separate from the movement of the player.
normal sprite:
in game:
What I did to fix the issues:
I fixed the issues with the screen size by making everything a bit larger in my game, which turned out looking a lot better than expected, and fits the screen size a lot more, with most assets being 32 x 32, especially the player and enemies. But a few little things only look a bit strange now but, you could argue that it looks better because the screen of the game boy advances was not perfect either, and having the same screen size as the game boy advance makes the size of things more accurate to how they would on a game boy advance screen. I also fixed how the player seemed blurry and jittery sometimes by setting the angle constantly to 0 degrees, which fixed this issue quickly.
audio evaluation:
What went well:
I think the sound in my game does a good job at telling the player something has happened/happening without showing it on screen. I am also happy that I didn’t struggle to much on actually planning the audio either for my game, because my design focus for this project was the graphical limitations of the Gameboy advance not the audio limitations so, I would rather focus more on graphics then audio due to my design focus, so it is good that I didn’t find myself having any issues.
What went wrong:
I guess I could have made some of the sound effects myself, because in the last project I did use folly audio techniques to make the sound effects in that project, which did turn out sounding pretty good but I guess they were also quite challenging to make, then edit them after the process of recording them. So in this project I just sourced them of zapsplat.com, then after that edited the sound effects (to my liking) in audacity, which is not the best way of putting sound into my project but, again sound wasn’t the design focus of this project so I didn’t want to put too much work into making the sound.
Improvements:
The only real improvement I could make is maybe next time just don’t source all of your sound effects, because sometimes if you make your own sound effects then they usually turn out better because when you make your own thing you usually know what you want to make and comes out exactly how you wanted it (if you put enough effort into it). So to improve my sound in short, just don’t source all the audio sound effects.
Evaluating the project as a whole:
What I have learned from this project:
Throughout this project I have improved my construct skills heavily, to the point were I could probably design anything I want on construct, which is really good for the future when I can use construct again for new projects. Things like the stick goblin (an enemy in my game) was quite hard to code because of the line of sight function in the code and also the animation frames of the stick goblin as well. Coding all of these mechanics will help me in the future to design other things in my game that has the line of sight feature or even the move too feature, because these features in construct are usually quite hard to use.
What I found difficult about this project:
The main thing I found hard in this project was the coding, I found the coding hard in this project because of the main enemy in my game: the stick goblin. Due to the code of the line of sight and move to player, it was really hard to give the stick goblin animation frames when the stick goblin is chasing you in game. This was because of I had to make an entirely new detection system for which way the goblin was facing, I did this by pining a large object to him that was pined to the direction he was facing, then when the stick goblin turned in game the large object would touch another object in that direction which changed the stick goblins animation frames. This taken me a while to figure out and I had to ask for some help from a class mate as well, but in the end it worked out to be a really good feature of my game.
what will I do differently next time:
In my next project I would like to work on the audio side of game making a lot more, because in past projects I have not worked on sound that heavily, and I have mostly just sourced all of my sounds in my games that I have made for my projects. I guess in my last project I put the most effort into audio because of the way I used folly audio techniques to make some of the sounds in my game: like crushing a mouldy pepper for a blood splattering sound effect, so I’d like to make more sounds like that in my next project.
Jack's game design blog 