Oh, this is an amazing game. I'm impressed with your time management in running this project. Even though you didn't do everything yourself, using existing resources to create a quality work like your game is not easy at all. Your work has opened my mind about the limitations of solo projects.
I think it would be very useful if you made a Devlog video showing your management process and decisions about which elements to polish. I think developers would find it helpful.
The game is fun!
Hey! Glad I was able to be an eye-opener!
I don't do devlog videos but generally I base my execution on rapid prototyping and fast iterations, and I was very fortunate to have playtesters during this jam. They helped catch areas where I found people got stuck at or confused by, and made me prioritize UX a lot more than I otherwise would have.
I will consider writing a longer devlog, but as a start, if one is using Unity, what has helped me a lot on the technical side of things is enabling Fast Enter Play Mode which allows one to instantly test gameplay, and using Hot Reload which is a plugin that allows for instant compilation during Play Mode. Combined, these keep my iteration speeds at its max, allowing me to focus on develop and iterate constantly and debug any issues on the spot. Being able to change values on the fly and see the results instantly accelerates my decision making skills a lot!
Once that is done, the bottleneck is less on the software, and more on how fast your brain can think and how fast your fingers can translate those ideas into code - mainly a lot of it is execution and maybe experience too.
When it comes to the jam, there is a lot of task prioritization involved - I focused on creating an MVP (Minimum Viable Product) where my key priority is to make the bare minimum of what works - for Last Fuse, this was the building system in v0.1 - which does not even include combat - this is so that I can at least deliver what I believe to be a working prototype of what I want to showcase and get a feel. The benefit is also being able to have a working prototype for people to play and get early feedback which is super crucial for UX
Additionally, although I had a lot of ideas at the beginning, I made sure to design them in a way that I could cut them if needed (5 endings down to 3, removing meta upgrades, so that in the event of a lack of time, I would still have a solid MVP). This meant I would regularly prepare versions that incrementally improve the game from the early playable prototype. At each stage, this allows playtesters to give me feedback well before time was up, and it is through that playtesting session that equipped me with information on what to prioritize in the remaining days.
Once I'm able to scale up, I work in the order of first getting the mechanic to work without bugs. In the context of the combat system, it's making sure the enemies shoot the right thing, increase heat correctly as the core mechanic, and being able to die properly. That's the minimum. Then comes balancing, which was a challenge in itself as I wanted the game to be challenging, but not too hard because not everybody here is familiar with the strategy genre. I didn't do the best job, but I tried to balance it according to a wider spectrum of audience to have the lowest barrier of entry.
And finally after that comes polish - adding muzzle flashes, bullet VFX, explosions, randomizing spawn points and pushing the presentation, using Slerp() instead of LookRotation() for turrets, etc. However, that's not to say I leave polish to the last thing all the time - sometimes I add polish during development which accelerates it because from the start I wanted a quality end product. And once I get the game-feel down, it starts to paint a clearer picture of the over-arching vision and further enforces what needs to be worked on.
This is getting to become a wall of text and I wasn't expecting to write this much haha. This brief devlog, I wrote goes a bit into how I slowly scaled up from an MVP and the order of which I developed the various systems - in what I believed to be decreasing priority. Even the end product had things I needed to cut as I lacked the time to make it work, so I will be working on the game post-jam to further improve it and address the feedback that I have gotten from the players who have left their thoughts here! :)
Thank you very much for this information. I can tell that you have a lot of experience and capability.
For us, we find it difficult to draw a clear line between what is MVP-0 and what isn't. For example, people in the Art team feel they need to create visually appealing images to call it MVP-0, while 3D artists often say there must be meshes and animations that communicate with players to qualify as MVP-0. Working as a team makes it challenging because each person has a different idea about what constitutes MVP-0.
Ahh, I don't know if I can answer that for you as team dynamics can be challenging and it really differs from team to team, and I agree that each person has different priorities, and if there is a lack of "alignment" it can be conflicting to determine what MVP-0 actually is!
This is obviously only my personal opinion and there will be people who think differently from me:
If your game is a game that relies on visuals, such as a visual novel, an atmospheric game, or in rare cases, the art is the hook (very rare, I only count top 1% of games like Cuphead and Bodycam into this category - they sell because they've made something nobody has seen before, this doesn't apply to just any game that looks pretty), then it may be okay to have MVP-0 require visually appealing visuals. As you can see, this depends on your genre.
The other case I may consider is when your game relies on animations to convey the gameplay and genre. I can't think of examples, but maybe some animation-driven game would fall into this case.
However, if your primary hook is gameplay (in the case of genres like roguelites, city builder, and possibly majority of games), then what you really want to do is test if people even like your idea - the art is there to support and sell the game. Yes, the art can help attract new players, but whether the game has retention or makes the player feel value for their time spent, hinges on gameplay and possibly its unique selling point. If the MVP has great art but ultimately fails to convey its genre or hook, then its purpose is debatable. That's not to say leave art all the way at the end or to ignore it, art has a role, but but you have to ask yourself what is the purpose of making your MVP. Is it to make a pretty thing sell your concept? If so, then you might want to consider making a vertical slice, instead of an MVP.
In the context of games in the genres above, I think the MVP is to let players play it and gather feedback on if the concept is viable, which is the "V" in "MVP".
Note that what is considered the MVP depends on a lot of factors - concept, so what I said here may not be applicable - I don't know your context, so it can be a case by case basis.
I always write way more than I expect haha, so the summary is: What are you trying to validate?
"Is this game fun?" -> if trying to validate fun, and you find that it's fun even with a bunch of placeholder white squares, you know your concept is a banger! In fact, not having polished art makes this easier because you're judging it "objectively" without being distracted by visuals.
