Warning! Memory trip ahead! This is just me reminiscing on the development of Beyond Beyaan.
I also wanted the ship construction to be empire-wide, to reduce micromanagement. But then I realized, what if two systems are cut off from each other in middle, how do they contribute to the production? So I scrapped the fuel range. I also added production for empire-wide as shown:
Note that you determine how much each increment will contribute to the production. If you select 5, then each increment will add 5 BC to the production. This was very unwieldly and I ultimately scrapped that system. I then thought it'd be a neat idea to have nebulaes act as "friction" and your fleets will need to find the quickest path.
I then decided to follow MoO 1's slider system for planets. I also decided on stacked ships, just like MoO 1. And an identical transport system as well.
I started work on the combat screen, and other stuff, when I had the brillant idea of using scripts for equipment on ships, but I believed at the time that it won't work too well with stacked ships. So I scrapped the idea of stacked ships:
Later, I decided to make scripting even more flexible, and realized that this new system supports stacked ships, but the damage was already done. The UI is now designed around single ships. However, the combat process was pretty close to what I wanted it to look like (similar to MoO 1)
This new system required an overhaul of basically the entire data structure of ships and such. Deciding to take it even further, I made it possible to customize starting ships, planets, systems, etc. However, this consumed a lot of time with very little tangible benefits, making it hard to stay motivated to work on the game.
Then I finally decided that nebula as it was didn't look good, so I removed it and realized that what's the point of grid-based movement? It'd be a very rare thing to intercept someone in space, and there's nothing exciting in the empty spaces. So I scrapped that system and replaced it with star to star movement.
I then decided that I want the game to be even more moddable, so I changed how resources work. This was another overhaul, as well as my decision to change from sliders to regional developments.
So, looking back over all of those design changes and overhauls (I think the current overhaul of the data system to the final system will be 6th or 7th overhaul), I realized something. If I knew what I really wanted, and had the understandings that I do now, at the time when I started on this project, the game would probably be done by now. But that's the only regret. I don't regret all the learning and experiences that I've had with the process. When I made my first game, an asteroids clone, it took me 9 months to finally finish it. However, it was a very buggy game. Then a few years later, I decided to make the game again, to make a better version, and it took me a month to make an similar game but without the bugs. Then again a few years later I decided to remake the game as an way to learn C# and Gorgon engine. It took a month again, but I was able to add a LOT of new features such as varying types of asteroids, upgrades, etc.
So basically what I'm saying is that when I'm done with Beyond Beyaan, if I were to make another 4X game, it'd be a lot faster and less messy, because of the experiences that I've had with Beyond Beyaan. So here's finally the protip: If you're developing a game, know what you want in the game, and set limits on features based on your skill and experience.
Another problem with Beyond Beyaan is feature creep. Too often I'd go "Oh, that's an awesome idea, let's add that!". It's like building a house, then deciding that you didn't like a wall's position, so you destroy it and build a new wall in a new place. It will never be perfect, so you gotta decide on what you want, and what you are willing to put up with in terms of cut features.
The reason for this lengthy post is that I just started work on overhauling the code for handling the new final data files. The changes basically broke everything in the game, from the UI to the ships to the technology. I can't even compile it. I won't commit my changes to google source control until it's able to be compiled. It's like knocking down the whole house, and saving sections of it for re-use.
Oh the memories! :)
ReplyDeleteBut please, continue to work on Beyond Beyaan. You inspire me to continue the work on my own 4X game.
I too redesigned my game a couple times. At first I was developing it in C++ with almost pure OpenGL. It was going well at first but implementing whole GUI (labels, buttons, dropdown menus, text boxes with UTF-8 support, containers) took it's toll. Than I switched to C# and Windows forms. After two, almost three years it is a time to do another thorough code redesign.
The reasons are multiple, I learned new stuff, GUI code has to be reworked if not rewritten (turned to proper MVC pattern), but what is more important to this topic is that I've decided to write the design document for the whole game. I wrote such document for space combat feature and I'm pleased with the result. Also it will help me to finally settle on certain design details.
Thing is when writing even a three page long document, you are forced to a lot more thinking and changing design is a lot cheaper than in code. Another trick I'm going to use is state why the feature exists, for each feature. It may serve as feature creep protection but the real benefit is better definition of the feature and better defined features are easier to analyse, model and integrate into the big picture.
Brent, this is a very insightful post. It sounds like you wish you had thought everything through up front, compiled it all into a set-in-stone design document, and then just implemented that. But really, without actually making the mistakes, could you have thought of everything up front? I personally doubt it.
ReplyDeleteI feel that an evolutionary process like the one you described leads to the best games. The process shows you the strengths and weaknesses of each system so you can focus in on the parts that are most fun. Do you think it would have made the process easier if you had approached it like that from the beginning? Instead of writing all the code in one project, write separate little prototypes for each system. Then you can test what works for each piece before putting it all together. From the perspective you have now, do you think a process like that would have been more efficient or led to a better game?
I loved this part:
ReplyDelete"realized that this new system supports stacked ships, but the damage was already done"
:)
As you seem to regret that decision, and you are rebuilding the whole thing, couldn't you change it back?
Thanks for your comments, guys!
ReplyDeleteAs for splitting the project into parts, that won't help really because sometimes a part would work very well, then only later discover that it's not fun or necessary and it's removed from the game. You need to have the whole picture to see if parts are working well together or not. A car tire might be fully functional, but it have no use on a bicycle for example.
TBSS: Actually, the plan is to support both stacked and single ship systems :) Right now the plan is to focus on getting the game completed, so just single-ship system for now. Then when the game's done, I want to add another dataset (or mod) that replicates everything that MoO 1 has, including stacked ships, no starlanes, one planet per system (different UI), etc. When that's done, it means everything that I need for the "ReMoO" project is implemented in BB, just need to have it work with the MoO data files. Then maybe, 10 years from now, I'll add "ReMoO 2", having the game work with MoO 2 data files :) Yes, I plan on maintaining this game for a long long time, it's my way of relaxing :)
Thanks for the post
ReplyDelete