Indie Game Development (Main Page)
I declare that the material contained in this assessment is the result of my own work and that due acknowledgement has been given in the bibliography and references to ALL published and unpublished sources. I confirm that I have reviewed the guidance on academic integrity at Academic Malpractice | MyCumbria to ensure that I understand the requirements.
For the first time on this course, this project is team focused. We'll be working as a team to produce a prototype of a game. For this project I'll be teamed up with Adam, Jac and Alex, making a game based around the theme of "An animal with a job". The idea that Jac came up with was a Snake Scientist and we really like the idea. So we'll be refining this idea further and using this going forward. Another thing that's different with this is that the entire project is going to be very business focused. It's not going to be like other projects where the final product was the main focus. We'll be doing some research on indie game development along with some research on what can make a game profitable. This research will influence how our final game turns out, with some additions or cuts being made as a result. At the end of the project, we'll be individually pitching our game to a "Publisher", which should simulate how an indie game would potentially release.
This Blog will be dedicated to the whole development of the game Snake Scientist, in addition to the research of the business side of indie game development. Because of this there are two pages to follow. One for each side of the project. There will also be a final post mortem of the project on this page. Which will be a complete look back on how I thought the project went.
Development Of Snake Scientist
https://20999935fdablog.blogspot.com/p/indie-game-development-indie-game.html
This page is dedicated to the development of the game. Everything from the creation of the snake player to level design. This also includes production management and how the team has utilised it throughout the project.
Business Development
https://20999935fdablog.blogspot.com/p/indie-game-development.html
This page will be dedicated towards research on the business side of indie game development. Including topics such as target audience and game benchmarking. There will also be some research based on our game to see if it's financially viable or not.
Snakientist Post Mortem (04/12/24)
For the first time on the course this project was all about the business side of the game's industry; on top of that it was team based which again was different from normal. So, this project has been completely different from anything prior. As usual I'll be reflecting on this project, seeing what worked and what really didn't work.
The Concept
The past few projects we've had have been fairly open and unrestrictive with the theme. Previously we've had themes such as "Escape the Space" and "New Clear Test Site". These have been really fun to work with since there's so much I could do for them. But this theme was a bit different with "Animal Job Role". Again there is quite a bit that can be done for this but initial ideas were a bit restrictive. At least it felt that way. And this isn't a bad thing, having that restriction made the inception phase quite a lot of fun. I had a couple of ideas for this, one was a Grave Robbing Spider, but with the random idea generation we did it gave a level of restriction. I ended up getting a Hacker Crab and I had no idea how I would execute it. Thankfully Jac got Snake Scientist and this project was able to come true. And we could have done so much for this there was quite a few ideas we had that didn't end up making it into the final game.
Art Style Analysis
Our art style takes modern rendering techniques and uses them to make the game look retro, while also look modern. It's a weird style but in game it really works. It's a similar method to what I used for my Bloodreign project, except everything isn't being rendered into pixel art. Instead the pixelating would happen in Unity which made everything look far more consistent. And with the blood textures Adam made, we were able to make everything look horrific. The style also helped make the snake look significantly better. When the game was rendering in HD the snake looks off. Since it's made of sprites stacked on top of each other the rotation looked really weird. However, once the entire game is downscaled everything looked so much better. Even the snake looked much better when rotating in pixel art. On thing I would have change is with some of the sprites. I feel like I should have used a orthographic camera for some of them so they didn't look too 3D. But they still looked good in game.
Technical Issues
Overall the major technical issues I had were with the snake. I ended up going through multiple iterations to try and get it to work with minimal success. The first major issue was with the original 3D snake. No matter what I tried it wasn't going to work I tried several different iterations but nothing came of them. The closest I got was with this one, and it's only the best out of them because it moves. It was never going to work which is why we ended up scrapping this and moving to a top down 2D snake.
The first of the 2D snakes mostly worked. It was able to interact with physics and it moved around mostly fine as well. However, this one had a problem with it grouping together when the player isn't moving. And for the kind of game this is something like that was never going to work. I've kept this one in my achieve because it works it's just not what this game in particular needed.
The second iteration looked and played like I wanted it too. The movement looked really good and everything looked like it was working just fine. Until the issue with adding colliders came about. There isn't really a good way to give a line renderer collision and this snake used a line renderer to make the tail. So this is another snake that wasn't going to work.
While the previous snakes didn't work the way I wanted them too they both gave me some stepping stone into making this version. Essentially I took what worked from both and blended them together. And it works really well. It feels really really good to control and on top of that is can actually interact with physics and colliders. This was exactly what we needed for this game.
Creative And Technical Learnings.
I've learned quite a bit from this project. Mainly from the code side of the project. And start, I've learned not to do something I've been doing for years. I'm really bad with deleting something when it isn't what I want. I'm done this quite a bit with code where'll delete a script and start again from scratch. With this project I told my self I wouldn't do that and it's really helped out. If I deleted the old snake prototypes I probably wouldn't have ended up with the final snake. The only reason the final snake exists is because I didn't delete the old snakes. If I had I wouldn't have ended up with it.
I've also learned hot to properly use an array in code. I've used them before mainly with the Bloodreign arena but not quite to this extent. With me constantly using them for the different snake prototypes I now have a good amount of knowledge on them. In addition that arrays, I've also learned how to iterate through an array using for loops. Again these are incredibly useful to use and I'll keep them in mind for future projects.
While I've already talked about the art style it really is something I've learned quite a bit of. I've never worked on a top down game, and I don't think the rest of the team has ever worked on one either. So this was uncharted territory for all of us and I think we've done a good job in this aspect. There are defiantly some parts I would change but for the most part it was nice and consistent.
Production Management And How Well We Worked As A Team
In terms of production management we used quite a bit. With things like the production schedule and the Trello board. But one thing I never mentioned was with the OneDrive folded. I created a shared folder so all of us could upload various assets that we needed to share. I was really helpful and it meant that we didn't need to pass around a USB stick to transfer stuff. However the Trello board was something that we rarely used. We would do our weekly meetings and do what we said we would. And for the most part this worked out just fine, with us staying on schedule for quite a while. It was only towards the end where we near enough abandoned the Trello since we had the pitch to worry about. But at the beginning of the project it really did help.
For how we worked as a team I feel like it went quite well. As I mentioned before we had our little meeting every week. In them meetings we would discuss what we did over the past month along with what we'll each be doing over the next week. We would also ask the others on there thoughts on something, for example I asked them all about the change to 2D when my snakes weren't working. I was pretty much just like a scrum meeting we just did it every week and not every day. And again all of this started to break down towards the end when we were preparing for the final pitch. We still collaborated and assisted each other, but it wasn't like when the project first started.
How Bizdev Influenced The Creation Of The Game
Researching on the business side of games did have an influence on the creation of the game. This was mainly with looking into our market research and noticing trends that would work for our game. Originally our game was planned to be 3D and that create a whole other problem. That 3D snake took 2 weeks of non stop trial and error before we scrapped the idea. If this was a real indie game studio, it wouldn't have made any business sense to keep trying to get this working. I knew that making a top down snake would have been easier so we ended up changing our target market to accommodate for this. The plan was to simply change the perspective of the game and keep the semi realistic style, but when we saw that most of the games we looked into were pixel art we changed to that. Not only was it faster to develop but it also looked more in line with the other games we looked at.
As well, we also planned to incorporate high scores into our game at the end of each level. This would have been a good way to increase the total play time while minimising the amount of work that is necessary to increase the play time at the end this wasn't incorporated into our demo since we had more features that too priority. Mainly with the enemies. On top of that we also planned for each level to be 15 minutes max to have that quick pick up and play gameplay. This is another thing we took from our marker research since quite a few level based games typically have a set time limit to each level.
Also setting a deadline for the creation of the prototype really did help, since we had something to work towards. This is something my previous projects we're missing since they didn't have any set targets. This time we knew when we were on track and when we weren't.
What Could Have Been Improved And What Would Change If We Started Over
To start off with what I would improve, we should have focused more on the creation of the puzzle elements. Right now the only puzzle elements we have is a basic button and a box, that's it. We should have focused more of creating more puzzle mechanics instead of the art style. We had some idea's for puzzle mechanics that we could have implemented we just didn't have the time to add them to the game. Additionally we should have refined the art style a bit. There were some parts of the game that look out of place or just out right weird. Take the doors and the button as an example, they don't look like they fit in with the rest of the game. It's the same for the stairs, these shouldn't have been sprites like the rest of the game. If we simply added the 3D model into the scene they would have looked much better. I think the issue we had with the art style is that we relied to much on the pixelating hiding the problems. For the most part it did help, like with the snake, but for some parts it didn't help. Finally we should have implemented
If we were to start over I would have said to make the game 2D from the start. I spent over 2 weeks trying to get the 3D snake to work with it not even coming together in the end. With that two week we could have done so much, like include features such as high scores and even more puzzle elements. And something I had a problem with was doing too much. I ended up making models and sprites when that wasn't even my job. This isn't the fault of the other team members it's my own fault. I'm used to needed to do everything on my own since that's what I've been doing for a while now. I should have focused more on the code and let the others do what there best at. We would have ended up with a better game if I didn't spend too much time on these.
Final Thoughts On Bizdev
Looking through everything about Bizdev I've come to realise just how much it influenced the creation of Snakientist. With previous projects I never considered this at all; I feel like I've learned how to plan out a project better now as opposed to last time. Even a college environment it really helped to restrict what we could and couldn't do. With Bloodreign I made what ever I wanted, with out considering if it was a good decision or not. But in this project I needed to consider what was necessary and what wasn't. We ended up with a higher quality and cohesive end product because of this.
It was also really insightful to learn what an indie game may potentially need to to in order to be successful. From different funding methods to planning out how long a project should last for. While I already know quite a bit of this I didn't know just how important things like this could be. I now understand why time restraints are really important. When a studios burn rate is £10,000 a month to stay open it makes sense why time means everything in indie game development.
Conclusion And Final Outcome
Overall the final game has really turned out well. Functionally much better than other games I've worked on. My code is normally really bad and unoptimized, but with this it plays just fine with out any major bugs. I mentioned this at the end of the Bloodreign project we're I said I'll try and be less crazy with my ideas and think about scope. Normally this would be a problem for me, however I wasn't alone for this project. I was part of a team and we all we're able to give our input into the game and effectively scaling down the scope. If I ever came up with a crazy idea there were other people to tell me that we didn't have time to add it. And the end product is much better because it was a team effort.
To conclude with this project I need to say that I like the change. Working as a team as opposed to on my own is so much better. Not only because it's easier but because the end product is also much higher quality. This project was a team effort and something I wouldn't have been able to put together my self in this amount of time. So thank you to Jac, Alex and Adam for being an amazing team. We've really made something that we can be happy with.