By starting from scratch, I meant on the gameplay part. The art style, music, and all that is definitely something we’ll be keeping with Planet Panic. The gameplay needs lots of work. It is definitely going to be wacky. What we have planned is a lot more over the top than released so far.
So, the API is the code that allows things to interface with it. Basically, we have: games can be started, loaded on a screen, rendered on a screen, played (with input), heard (sound effects), and it all works in the game itself. You can make a Lua based (Lua is a scripting language) arcade game and play it in the actual game. There’s still work to be done, but the huge core parts are finished.
Once the API is done, then we can start coding the 2D Lua games. There’s other types of Arcade games as well that aren’t 2D and that framework is also done. But, of course, the actual games need to be made still. We have to make gameplay code, gameplay design, 2D art, sound effects, and music for all the games. Then, we have to test all that and tweak it and iterate (over and over) until the games are at a stage we can release them at.
I don’t really find it fair to compare us to ARK. Our game is completely different, our team is completely different. We aren’t going to have any similar results with this game. I’ve followed a lot of Early Access games myself and they all have vastly different goals. Our goal with Early Access is to get feedback and to let people play the game while it’s being made. We have the scope of the game already set in stone (pretty much most of the scope is advertised on our Indiegogo). We are just choosing what feature should come before other features at this stage.
We have internal goals and internal deadlines and meetings every week, we’re not just tossing things together left and right. There’s a method to the madness.
For example, Halloween was a test of features we’re going to be using in the future constantly, such as: the dialogue system, the minigame system, the plaza event system, the cooking system (the cauldron is actually cooking with one ingredient), the metal detector/fishing system (forgotten remains), and re-theming the plaza (for seasonal events). So, while it may seem like it was a limited time event, pretty much all the features created are going to be used for future planned features. We used Halloween to benefit our end goals.
There’s a couple issues with doing things in large chunks like that for video games, in my honest opinion.
Firstly, things don’t always require the entire team and thus putting everyone on “X Project” will end up with lots of wasted time. Our artists usually finish before our programmers and if they’re just sitting there waiting for the programmers, then they’re just wasting their time. The reverse could happen where the programmers are waiting for artists to finish up, as well.
Secondly, bugs gotta be fixed and jumping around to solve bugs is necessary. A lot of times bugs take longer than new features and bug fixes will push back development of new features naturally (there’s only so much time in a day).
Thirdly, developer burnout. Burn out is a real thing and if you’re constantly working on a single project, you’ll end up with lack-luster effort put forth towards the project. And then you end up with a bad project.
And lastly, we’re running an Early Access game. We need to maintain a healthy player base. The game is being sold as-is and we want to invite new customers to a game that updates regularly (with fixes and features they enjoy).