Posted April 7, 2020
by crabrock

Fleet classification was mostly solved, i.e. you knew how to get the exact classification you wanted most of the time. Some things are impossible, i.e. getting a battleship and 5000 fighters to classify as anything other than "Armada," "Battlegroup," or "Enforcer" (depending on how many other cap ships you added). Sometimes seeing fleet classifications was useful, but usually it was more the tonnage and ship numbers that was more useful, since fleet class could be obfuscated by adding small-tonnage ships, etc. There were some changes to make fleet classification more robust, but these were mostly confusing, useless, never seen, or all three.

What was frustrating was having several different fleets that you wanted to keep together, but they'd be classified as different things. Or having different fleets with the same classification serve totally different roles depending on the designs within.

I created a new system that allows the player to specify their own fleet classifications, if desired. Everybody inherits the default, old-school classification system rules, but they can be removed, edited, or rearranged.



In the new system, you create a Classification which is filled with several "rules." A fleet will check each classification group, and if it passes all of the rules, will gain that classification. If it does not meet the requirements, it will move to the next, and so on. If it reaches the end of the list and does not find a satisfactory definition, it'll just be called "Fleet."

You can test the classification rules directly on the fleet classification page.



You can rearrange the order, putting more specialized roles up top, and catch-all roles down toward the bottom.



Each classification can have multiple qualifying or disqualifying rules.



Hope people have fun coming up with new fleet classifications.

Check them out here.

Posted March 28, 2020
by crabrock

Research has always been one of the most fun parts of the game, but also one of the most unintuitive and frustrating ones as well. The fun aspects of research are the incremental increases in technology - several dozen different types - that all have immediate, far-reaching consequences in the game. There are no useless technologies; every type of blueprint is useful at some time or another. However, there are usually too many to keep up as a single player, so the only way to have the best stuff all the time is to work in groups. Because of the research system design, every blueprint is unique, relying some on skill, and some on luck.

The frustrating parts of research are understanding exactly what is luck based and what is skill based. The first iteration of the research system had you input a formula: slider bars for several different things such as "physics, chemics, and medical." Some of these seemed pretty obvious: jack up medical for hospitals, max out "drives" for ship drives, and put "processing" somewhere in the middle? Because there was some randomness baked in, not even the closest formulae to the "truth" were guaranteed to get you a print that was useful. This ended up angering people, as in later stages of the game the research projects can take weeks to finish. The second iteration of the research design involved picking a project you wanted researched, and then adding scientists to a lab. Now instead of choosing the sliders, the scientists had different levels of each of the 10 attributes, and their stats were the formula. So a scientist high in medical should be added to a hospital project, and so on. However, understanding exactly what made a scientist good at one project wasn't clear. Plus, you still have the problem of choosing a budget and a lab, both factors contributing to the randomness of the print. Getting good scientists was pretty much luck of the draw, and there were a lot of cheesy ways to rush good scientists by making new colonies and dumping all your colonists there to drive up land mass and tech development percentage.

RetroSpace attempts to keep some of the fun aspects (iterative improvement, random uniqueness, team-based sharing) but remove some of the more frustrating aspects. In the new system, you still have random scientists who will appear at your colonies and can be hired. However, their system of formula-based stats have been replaced with fields that directly and predictably influence the quality of the blueprint.

Ingenuity - The overall Quality Level (QL) of the blueprint. The basis for all the calculations.
Competitiveness - Bonus to "Power" of the blueprint. This is the raw damage of weapons, or the number of workers in a mine.
Organization - Bonus to "Effectiveness" of the blueprint. This is the level of a research lab, or the ratio of guns to mass for ship hulls.
Most of the time the usefulness of a print is just the power*effectiveness, and there isn't much difference between the two, i.e. Power of 2 and effectiveness of 3 is the same as power of 3 and effectiveness of 2 (both 6). In the future, I will be trying to separate these two aspects out further to provide case-based benefits to researchers giving bonuses to each.
Resourcefulness - Decrease the credits the blueprint costs.
Fabrication - Decreases resource requirements of the blueprint.
Punctuality - Determines how quickly a project finishes.
Exploration - Gives a boost to chance to find hybrid blueprints.
Creativity - Adds to a random stat on project completion.
Mentorship - Increases the amount of skill upgrades the other members of the group get after project completion.
Aptitude - Increases the amount of skill upgrades the scientist gets after project completion.

In the second iteration of research, labs could accommodate many workers, dozens in the late game. However, each successive scientist mattered less and less (their stats only counted for half the previous scientist), making projects with more scientists above 5-7 worthless. I removed this ambiguity by creating science groups that are limited to 5 members. Each member's stats are fully used for the project. When adding or removing scientists from the group, the bonuses are calculated and displayed so that you know exactly that each scientist is bringing to the table.

In addition to the numerical stats, scientists have an educational specialty and an educational level (Undergrad, Masters, Doctoral). These levels influence their starting stats (50, 65, 80, respectively). In addition, educational specialties provide bonuses (and sometimes negative effects!) to different types of prints. You don't send a weapons specialist in to design satellite, for example. This means that not every scientist will be the best for every project, so there is not one "super team" that can be used for everything. Scientists will have to be mixed and matched for different projects.

To make all of this fun, and not a chore, I've spent a lot of time working on the UI to make science, groups, and research as easy as possible.

First, scientists are easily sortable by every category:



Unwanted stats/information can be hidden or moved to a separate line, and even more detailed information / history can be found through a separate popup.



Scientists can be mass selected and dealt with easily:



Mobile optimizations make it easier to navigate the large amounts of data presented on a smaller screen:



New scientists can be controlled from this page and set to three different recruitment strategies:



Science groups try to pack a lot of information into a small space so that you don't have to navigate so many screens to get everything done:



Things to note are: The research queue. You can queue up many different projects and the group will automatically begin researching the next project, even if you are offline. The lab that a group is working in must be in the same colony as the project leader. Other than that, scientists can telecommute from other colonies. Labs can be upgraded mid-project for a slight penalty in completion speed. On the group overview, you can easily see warnings, errors, and what each group is currently working on. Hovering over the errors / icons gives you more information.

After the project finishes, you will be informed of the print, the upgrades, and how many projects the group has left in their research queue.



Some tweaks to the system are still needed to get everything properly balanced, but I believe a lot of these changes will make gameplay more fun by increasing the amount of control a player has over their research, while still keeping a little bit of the randomness and surprise in getting unique blueprints to share with other players.

Posted August 23, 2018
by crabrock

Ships have always been built by people on colonies... just random people you know. You could recruit x number of people (who really knows what percentage it was, 40%?) of your people to work in your shipyards. I guess they just dropped everything they were doing and went to work for a few days. There are a few problems with this design:

1. Payment is a bit confusing. Exactly how much money you'll lose per tick, exactly how many ticks your project will cross, are not immediately clear, so you either just guess or have to do extra work.

2. People try to break ship projects up into sub-tick batches. If your construction project finishes before the economy runs, you don't have to pay those workers at all. This results in a lot of "oh i'll wait til next tick to build," etc. which isn't really fun and often involves lots of luck in timing (if you check the time til next tick and it's 24 minutes, wooo!).

3. Ship construction ability is based on colony size. Doesn't matter if your colony is dedicated to ship building, you still won't be able to build as much as a larger colony that is all farms. This doesn't make a lot of sense, and really hurts forward base construction.

My solution to this is the creation of a new Government Institution called the shipyard. It works much like other institutions, but instead of adding miners, it adds shipyard workers. The obvious benefit to this is that higher tech shipyards mean faster ship building. Another thing to keep upgrading! It also means you can slap down a major shipyard colony with much less work than before, and now your shipyard employees don't drain all your income if you accidentally miss the tick. They're just normal employees, and you designate how many of them you want working on your ship project. Ticks don't matter anymore and if you want to build faster, build more shipyards.

In addition to this major change, the entire ship building screen as been rewritten from scratch. Now the list of ships is displayed, and you can scroll through them easily (without a page refresh). You can also easily max out your workers and will have a clear idea of when your ships will be ready. I believe this will make shipbuilding more straight forward, more strategy based, and more fun.

Posted August 3, 2018
by crabrock

The blueprints page has been a constant source of frustration for players since the beginning. It represents a few challenges in terms of gameplay and coding.

First, the amount of data that it needs to retrieve is pretty massive. The old blueprints script was a bit clunky at doing this, and if players had too many blueprints, the page would hang. This was combated in a few ways. The worst was probably setting ini_set ("max_execution_time", "360"); at the top, which is what it looks like, a six-minute time limit. Any situation where a player has to wait up to 6 minutes to see their blueprints is just not going to work.

Later, the blueprints page was split up, so that a player had to select "type" and then "subtype" of print. This kept the pages much smaller than just displaying all one one type. However, it did increase the amount of page loads, and when blueprint lists got long even for one type, we're back at the same problem.

The next solution was to add the ability for players to "archive" prints. Most players kept prints around for two reasons. 1. If you wanted to build something later on, due to lack of resources/funds, you needed to have it. 2. it increases the science score of your empire (the more of your prints people own, the higher your score). So people weren't deleting their lists and keeping them lean. Plus if you did, and somebody sent you a tech disclosure, you were back at square one with all your hard work undone. So archiving prints was a good solution to both of these problems.

However, these additions lead to their own form of clunky interface (buttons for each, checkboxes for each, textboxes for sell value, etc). and each one was loaded with all of this formatting.

The new blueprints page is lean, it loads with nothing. Requests to load a blueprint subtype are handled via AJAX, so the amount of data being transmitted is much less than transmitting all the formatting data for each print, so the load time for the same amount of prints using the new method is much, much faster. The formatting is handled via a JavaScript function, so the bottleneck becomes the player's computer, not the server's ability to parse a MB of formatting data. Switching between types only loads the essential data, no formatting, and so going back and forth between prints is a breeze, and there's no additional overhead of loading the menus, etc. Players can display current, archived, or all blueprints, and because all the data is already stored on the player's computer, this happens instantly.

The multiple checkboxes have been replaced by a single checkbox, and the tasks to do with all checked prints has been streamlined. All of the buttons now use javascript to do quick tasks (i.e. archive, send, sell) instead of sending you to a new page, so the pages do not have to load all the blueprints again, cutting down on total server traffic. You can now send multiple blueprints in one message, and to several different players.

Overall, these changes should result in a streamlined experience for players and get rid of a lot of the problems that have plagued the blueprints page for over a decade.

Future upgrades: search/sorting by specific values such as lowest cannons/price, all transports under 1500 iron, etc.