Dev Log
Prototyping Something New
After the demise of my previous project I've taken some time off from active game development. I've been doing a little soul searching, a little research and as much learning as I can squeeze into an already packed schedule.
Feeling like I had an idea worth exploring, I've spent the last few weeks working to prototype a new game idea. It's an idea that I've had bouncing around for a few years and is heavily inspired by one of the first online games I ever played. And no. This new game will not have multiplayer - I've learned that lesson (I hope).
With my last project I was nearly a year into it and still didn't have a real working prototype - I had built prototypes of systems but that was it. So this time around I was determined to do things differently. I wanted something that I could prototype in a few weeks, maybe a couple months at most (real life can get in the way).
So... Where is it at now?
In a about ten days, I was able to code the "procedural" generation of the world. It's not perfect, but it works. And that's all a prototype needs.
A few days later I had the player's navigation working along with some ugly but functional and relevant UI.
The project was checking lots of boxes and doing so quickly.
The game will be a "space" game. You know planets, stars, laser beams and plenty of spaceships flying around.
So the next chunk I wanted to implement was shipbuilding. I want the player to customize their ship and design it around their desired play style. A few days later while sticking to primitive shapes (programmer art) I had the basic code functioning. Even spent some time working on visual feedback...
That was a few hours work that didn't move the prototype forward. Oops.
I'm pretty happy with the results. It's simple and not as smooth and polished as it needs to be, but it works. Again it's everything the prototype needs (and just a few bits more).
With the ship building complete I had two major features that were going to need work. The game is going to be based on trading and combat (shocking I know). So I needed an inventory and shop system.
Nothing much to see with the shop system and it's probably the part of the prototype that I'm the least happy with. But! It works. I need to revisit it, to make it "feel" good as it will likely be a central part of many player's experiences. That will come later in the production.
As much as I dreamt of making a "violence free" game with my last project, I can't imagine this game without some lasers, a healthy dose of explosions and maybe a few space pirates. Which means the last piece to build was a combat system.
The combat will be very stylized. You're won't be piloting your ship dodging asteroids or incoming missiles. Rather you'll be creating a strategy to counter a single opposing ship. You'll be able to pause the game, think, plan, act and then watch it unfold. And yes, the system is pretty heavily inspired by a popular rogue-like minus the parts that I didn't like and hopefully with at least a few new ideas.
Even for a prototype, the beginnings were pretty rough.
Once the code was functional I wanted maybe even needed to make this part of the game "feel" good. If I can't make this feel good, then I may need to re-evaluate the design?
I spent a few hours on the UI, a bit on the visuals and a few more on some basic AI. The results? They aren't horrible.
Clearly, there is more work to be done.
So is this my new game?
Maybe it is. Maybe it's not. But I'm getting close to committing.
When to Shelve a Game Project?
I write this post to help me process as well as to share the journey of the last few months as I have realized I need to put my current project on the shelf and take up a new and simpler project. This is not an easy thing to do. Even as I write this I can hear the doubt whispering in my ear...
Like so many of us, I too had a dream of what my next project could look like. I had learned so much from my first published game and I was excited to start my second project making use of all that experience and knowledge. My coding was better. My design was better. Even my art had improved significantly.
I was ready and excited to not make the same mistakes that I made on my first project. And so, no surprise, I proceeded to make a whole new set of mistakes...
I approached the design of "Game #2" much smarter this time around. Rather than just jump in and work on the next thing that came to mind. I laid out the design in layers with discrete chunks that could be prototyped. With each completed prototype I became more excited and more hopeful. I was making it happen!
In early 2018 I started to put the prototypes together. I started to build the game world and began the process of weaving together my creations along with a few third-party tools (that's a whole other post). I was creating art assets and the world was starting to looked "not bad."
And then it happened...
What "it" is exactly I'm not sure. It wasn't a singular event. It was more of a dawning or realization. I think most simply put, it was the realization that this project was simply too big and too complicated. If I look back on the development process this was no surprise. I knew it was ambitious. I had been fooled by the success of each prototype. Each step forward gave me hope. But when all the prototypes came together I could see that what I had was, frankly, a mess.
The spaghetti code that haunts Fracture the Flag and led to so many bugs had been replaced by chunks of code that individually were reasonably well put together, but when connected made for a not so tasty pasta dish. I could see the writing on the wall and I was headed towards another bug riddled project.
Added to that was the knowledge that I'd broken a cardinal rule of game development, especially indie development. I had over scoped the game. I knew it from the beginning but had run headfirst into that all too common trap somehow believing it would be different this time. I had a plan. It was going to work.
Fuck.
How'd this happen?
Pretty simple really. I'm an idiot and I ignored my own advice let alone every blog post, article or book I've ever read about designing a game.
I know better than to design a large game. I have discussions multiple times a month with students (I'm a teacher) about the scope of games and what a single person or a small team can accomplish. I preach simplicity and then I ignored my own advice.
What a dumb ass.
Beyond dreaming too big, it was super easy to get lulled into a false sense of confidence by the Unity Asset Store. I learned long ago that most of what is published there is not as good as advertised and especially to stay away from assets that will be in the final build (as opposed to editor extensions).
A slick inventory system saved me weeks of work...
I picked up an exceptionally well-designed (truly!) behavior tree asset to be able to program my AI...
Other assets allowed me to quickly sculpt terrain and procedurally add scenery...
To be clear the assets I was using are in fact very good and they did save me time. That is until I needed to tweak them or until my vision didn't match the traditional vision of the asset developer. To stand out as an indie or even have a few people notice a game there needs to be something special about it. It needs to be different. You need to twist the boundaries of a genre or at least employ a new mechanic. So rolling someone else's tool that is based on past games and established mechanics is not be the best plan and frankly I'm not sure it even qualifies as an "okay" plan.
This all helped to create a fiction that I, a solo hobby developer, could greatly expand the scope of my project. Each of the assets could potentially save hundreds or even thousands of hours, but that masks the hundreds of hours required to use those tools to create content.That's no one's fault except my own.
My stupid, overreaching, dumb ass self.
Aside from my stupidity, part of the realization that I needed to shelve the game came from my day job's seemly unending ramping up of demands. This is usually my easy time of year, but instead I've found that I'm busier than ever before. The chunks of time where I used to be able to stream my game progress are gone. The easy afternoon where I could find 3-4 hours to code, model assets, or just dream about game design have turned into 15 minutes of down time between meetings. Ugh.
I'm not planning on quitting my day job to go full time indie developer. Given my current game based income, that it would be a particularly bad idea. However, a career change is needed and it needs to happen sooner rather that later. In the next 12-18 months I will likely be looking for something new. I would love to publish one more game before that shift occurs. Not because I think I'll produce the next Stardew Valley, but because maybe I could sell 10,000 copies and maybe that could justify taking a couple years to build a third game and then a fourth...
Limitations Lead to Creativity
It's so easy to get carried away with game design. After all you can make anything that you can imagine. You are LITERALLY writing the rules of the world you are creating. With this comes the danger of not having limitations. One good idea leads to another and another. Take a second to breathe and your scope is stupid big.
Don't believe the lies. It's not the first time this has happened... And yes, it happens to everyone.
Screenshot - Fracture the Flag
When I was creating Fracture the Flag I had this vision for dealing with player territory. I was going to split the map in to distinct chunks that the players would fight to control. I spent a few days working on several different solutions, but nothing was working or even getting close to working... That was the genesis of the flag mechainc. Why limit the shape of territory? Why presume to know a good way to break up the map into chunks? My limited skill set forced me to be creative and I came up with a simpler and far better solution. My constraints had led me to a creative solution that became the namesake of the game.
By over scoping my game design I have applied almost no constraints. As a result I haven't really forced myself to think creatively. This has put me on a path where I doomed myself to struggle with weaving all the different systems and mechanics together focusing on the question "can I do it?" rather than "how should I do it?"
As a solo developer I won't be successful by copying or mimicking other designs. If I have a chance to be successful, it will only be possible if the game is fun and not if it's complex. The two are not mutually exclusive, but complexity has been know to stifle fun on more than a couple occasions.
I think this might be the best and most important reason for needing to set aside the game. The game design has become it's own burden. It's weighing me down. It's slowing me down. It's stopping the creative flow.
Sometimes the band-aid just needs to be ripped off.
If you are sitting there saying that I just need to stick with it, I just need to keep going, or others have done it so you can too! Maybe you're right? But this business is tough. Working hard, having a good idea, and executing the design well are not enough to find success.
If you haven't watched this, then you should.
Sure, there are examples of indies working for years slaving away and then making it big. But for every success story I bet there are ten, a hundred maybe a thousand stories of indies working for years and hearing crickets when they release their work. Go dig into the new releases on Steam if you don't believe me.
Admitting I've gone the wrong direction and restarting is painful and hard to process but it is a far better option than stubbornly staying on the same path. Even if that means a year's work is going to be shelved. That's better than putting in another 1-2 year's worth of work and having a only a steaming pile shit to show for it. Still, as I write this I have a hard time truly saying "it's done," because there was so much good stuff in the game
The Hardest Question
What's next? I love making games. I really do.
I've allowed myself to pause the development of "Game #2" for the last several weeks. I had hoped that I could redesign the game to have something that I could still release. I saw several hurdles in the development process, so if I could design around those then maybe the months of work would still result in a game? While I haven't totally given up on this, the simplified design looks too much like what is already out there. Do we really need another resource management game? It's a popular genre, but isn't it already a bit too crowded? There are systems that I have I built that could probably be reused. If I was more creative I could probably split Game #2 into 3 or 4 smaller games all based on a single mechanic or system.
During this "pause" I've been playing with a prototype that I've worked with off and on for the last couple of years. It's an idea that I've had and I chip away at from time to time. In a few weeks of (very) part time work, I've managed to cobble together a nearly working prototype. This prototype is just the first layer of the design, but it's taken me more than a year to get that far with "Game #2." From that alone, I know I'm far better off pursuing this new idea.
I also quite liked the results of my Ludum Dare entry. It's not unique, but it was fun to play. It potentially allows for players to create and share levels - always a good thing! (I wrote a script that converts a png file into a playable level.) It was a top down shooter that tried to use light and lighting in new ways. So while the top down shooter genre maybe not be as crowded as the platformer genre I still wouldn't call it an under served genre.
I feel the danger in wandering through the desert for too long searching for the perfect idea. I can waste just as much time looking for the perfect project as I could trying to keep a bad project moving forwarad. So where to next?
I'm still working on that.
State of the Game - Episode 3
This week I released the third episode of the "State of the Game" devlog. The focus of the past month's work has been to add new art assets and start to build up the world. All with the continued goal of producing a playable Alpha Build.
Check out the latest developments in this months video development log. I show off many new art assets plus new NPC jobs such as farming, mining, logging and a few more.
Got thoughts or comments on the development of the game? Join the conversation on discord. Visit discord.onewheelstudio.com or click the button below.
Older Posts
-
April 2024
- Apr 10, 2024 Ready for Steam Next Fest? - Polishing a Steam Page Apr 10, 2024
- Apr 1, 2024 Splitting Vertices - Hard Edges for Low Poly Procedural Generation Apr 1, 2024
-
November 2023
- Nov 18, 2023 Minute 5 to Minute 10 - Completing the Game Loop Nov 18, 2023
-
September 2023
- Sep 13, 2023 Visual Debugging with Gizmos Sep 13, 2023
-
July 2023
- Jul 4, 2023 Easy Mode - Unity's New Input System Jul 4, 2023
-
May 2023
- May 19, 2023 Level Builder - From Pixels to Playable Level May 19, 2023
-
April 2023
- Apr 11, 2023 Input Action in the Inspector - New Input System Apr 11, 2023
-
February 2023
- Feb 26, 2023 Tutorial Hell - Why You're There. How to Get Out. Feb 26, 2023
-
December 2022
- Dec 31, 2022 Upgrade System (Stats Part 2) Dec 31, 2022
-
November 2022
- Nov 10, 2022 Stats in Unity - The Way I Do it Nov 10, 2022
- Nov 5, 2022 State of UI in Unity - UI Toolkit Nov 5, 2022
-
August 2022
- Aug 17, 2022 Knowing When A Coroutine Finishes Aug 17, 2022
-
April 2022
- Apr 23, 2022 Unity Input Event Handlers - Or Adding Juice the Easy Way Apr 23, 2022
-
March 2022
- Mar 15, 2022 *Quitting a Job I Love Mar 15, 2022
-
February 2022
- Feb 8, 2022 Split Screen: New Input System & Cinemachine Feb 8, 2022
-
January 2022
- Jan 24, 2022 (Better) Object Pooling Jan 24, 2022
- Jan 19, 2022 Designing a New Game - My Process Jan 19, 2022
- Jan 16, 2022 Strategy Game Camera: Unity's New Input System Jan 16, 2022
-
December 2021
- Dec 16, 2021 Raycasting - It's mighty useful Dec 16, 2021
-
November 2021
- Nov 22, 2021 Cinemachine. If you’re not. You should. Nov 22, 2021
-
August 2021
- Aug 3, 2021 C# Extension Methods Aug 3, 2021
-
June 2021
- Jun 27, 2021 Changing Action Maps with Unity's "New" Input System Jun 27, 2021
-
May 2021
- May 28, 2021 Unity's New Input System May 28, 2021
- May 8, 2021 Bolt vs. C# - Thoughts with a dash of rant May 8, 2021
-
March 2021
- Mar 10, 2021 Coroutines - Unity & C# Mar 10, 2021
-
January 2021
- Jan 14, 2021 Where's My Lunch? - January Devlog Update Jan 14, 2021
-
December 2020
- Dec 27, 2020 C# Generics and Unity Dec 27, 2020
- Dec 7, 2020 Steam Workshop with Unity and Facepunch Steamworks Dec 7, 2020
-
November 2020
- Nov 27, 2020 Simple Level Save and Load System (Unity Editor) Nov 27, 2020
- Nov 9, 2020 Command Pattern - Encapsulation, Undo and Redo Nov 9, 2020
-
October 2020
- Oct 28, 2020 GJTS - Adding Steamworks API and Uploading Oct 28, 2020
- Oct 9, 2020 Game Jam... Now What? Oct 9, 2020
-
August 2020
- Aug 16, 2020 Strategy Pattern - Composition over Inheritance Aug 16, 2020
-
July 2020
- Jul 24, 2020 Observer Pattern - C# Events Jul 24, 2020
- Jul 15, 2020 Object Pooling Jul 15, 2020
- Jul 3, 2020 Cheat Codes with Unity and C# Jul 3, 2020
-
June 2020
- Jun 16, 2020 The State Pattern Jun 16, 2020
-
August 2019
- Aug 12, 2019 Easy UI Styles for Unity Aug 12, 2019
-
July 2019
- Jul 3, 2019 9th Grade Math to the Rescue Jul 3, 2019
-
June 2019
- Jun 12, 2019 Introducing My Next Game (Video DevLog) Jun 12, 2019
-
May 2019
- May 29, 2019 Programming Challenges May 29, 2019
-
March 2019
- Mar 2, 2019 Something New - Asking "What Can I Learn?" Mar 2, 2019
-
November 2018
- Nov 30, 2018 A Growing Channel and a New Tutorial Series Nov 30, 2018
-
October 2018
- Oct 11, 2018 Procedural Spaceship Generator Oct 11, 2018
-
July 2018
- Jul 11, 2018 Implementing SFX in Unity Jul 11, 2018
-
May 2018
- May 31, 2018 Prototyping Something New May 31, 2018
-
April 2018
- Apr 17, 2018 When to Shelve a Game Project? Apr 17, 2018
-
February 2018
- Feb 9, 2018 State of the Game - Episode 3 Feb 9, 2018
-
December 2017
- Dec 16, 2017 State of the Game - Episode 2 Dec 16, 2017
-
November 2017
- Nov 7, 2017 The Bump From A "Viral" Post Nov 7, 2017
-
October 2017
- Oct 30, 2017 NPC Job System Oct 30, 2017
-
September 2017
- Sep 1, 2017 Resources and Resource Systems Sep 1, 2017
-
August 2017
- Aug 3, 2017 State of the Game - Episode 1 Aug 3, 2017
-
June 2017
- Jun 20, 2017 Resources: Processing, Consumption and Inventory Jun 20, 2017
- Jun 15, 2017 Energy is Everything Jun 15, 2017
-
May 2017
- May 16, 2017 Graphing Script - It's not exciting, but it needed to be made May 16, 2017
- May 2, 2017 Tutorials: Low Poly Snow Shader May 2, 2017
-
April 2017
- Apr 28, 2017 Low Poly Snow Shader Apr 28, 2017
- Apr 21, 2017 Environmental Simulation Part 2 Apr 21, 2017
- Apr 11, 2017 Environmental Simulation Part 1 Apr 11, 2017
-
March 2017
- Mar 24, 2017 Building a Farming Game Loop and Troubles with Ground Water Mar 24, 2017
-
February 2017
- Feb 25, 2017 The Inevitable : FTF PostMortem Feb 25, 2017
-
December 2016
- Dec 7, 2016 Leaving Early Access Dec 7, 2016
-
November 2016
- Nov 28, 2016 Low Poly Renders Nov 28, 2016
- Nov 1, 2016 FTF: Testing New Features Nov 1, 2016
-
October 2016
- Oct 27, 2016 Watchtowers - Predictive Targeting Oct 27, 2016
- Oct 21, 2016 Click to Color Oct 21, 2016
- Oct 19, 2016 Unity Object Swapper Oct 19, 2016
-
September 2016
- Sep 18, 2016 Testing Single Player Combat Sep 18, 2016
-
May 2016
- May 25, 2016 Release Date and First Video Review May 25, 2016
-
March 2016
- Mar 26, 2016 Getting Greenlit on Steam Mar 26, 2016