Beta test

Or should I say a month of playtesting. A good number of bugs are identified and fixed and publishing a pipeline (to beta test at least) is established. Also, the game UI finally looks like a game UI.

At least that was the state of the game in May. This is going to be a long post, game development is going faster than blogging. So let's begin. Here is the trailer! And information about how to join beta:

It took me a number of attempts to make this video and it shows. I have decent experience in chopping and compressing a video but this was my time composing one out of multiple pieces. The audio was the easiest part, I wrote the text, tried a few recording programs, a few microphones, and read the text the best combination. In principle that is. I had run through multiple drafts of the text because the speech is not a blog post. You have to use simpler sentence structure, watch your breath and rephrase hard to pronounce words. But at least it was quick and easy to iterate. I settled on recording one paragraph (2-3 sentences) multiple times at the time and stitching the best takes in one audio file afterward. Getting video footage was a mess. The game is not integrated with Google Play Games so I couldn't use their screen recording feature, which is otherwise very ergonomic and makes good quality footage. So I had to look for other programs and make do with a barely passable one. Composing a video out of multiple ones was an even bigger mess. I was unable to find a good no-fuss program for it so I had to stretch the capabilities of a tool I worked with before. It again took multiple tries to get desired clips out of recordings because the tool doesn't like making cuts at arbitrary frames and appending multiple such hack job video files often resulted in the glitchy final video. It was the FLV encoder that saved me from non-keyframe cuts hell. And now, now the game is changed so much that I should make another trailer... I dread about it but I'm prepared with better software now and all I really need, besided courage, is to find the time to make the footage.

Ok, so the trailer got uploaded, the link posted here and people came, and then what happened? I'll get to that, after elaborating one little detail. Getting a beta test invite link requires basically having an app published, which means, filling in more forms, figuring out app signing, getting comfortable with the release treadmill, and then wait for a few days to get the app reviewed. The upside of the process is that Google will do some basic app tests for you and the results could be useful for improving the app. Automated tests do have trouble with navigating game map because they don't do touch gestures but they will do everything possible on regular UI widgets and report all sorts of accessibility issues. Also, Google will try running your app on older devices if you declared it should be compatible with them. This test has found (crashed) a few places where the game was using functions unavailable in the old versions of Android.

Ok, so people came, and what happened? When you present a program to the general public, keep in mind that most feedback will not be aligned with your plans for the project and that requests for additions of a similar kind will not be uncommon. Don't get overwhelmed by it, keep calm and try to compromise.

I've limited promoting the game so I got about 10 beta testers. Most of the requests were for more role-playing features. Ones that come to mind are flag emblems, named fleets, and AI personalities. But the most requested change was to make a black background. Since the game kind of already had that in the form of the night mode theme, I made the night mode the default.

At least that was the first step. The second step was to make properly set up application's theme, for both night and day mode and both portrait and landscape orientation. This took the most of the May, mostly for learning which leavers to pull to get the desired effect. But there were also trials and errors in making and setting button and panel background images. Android, especially older OS versions, has very limited support for stretchable images, both in terms of capabilities and documentation. I managed to get things working under imposed constraints but it's not foolproof there are still some quirks remaining I cannot find a solution for.

Other smaller improvements done during the month:

• Fleets can be redirected in flight. Immediate destination (first waypoint) still can't be changed, the rest of the path can be. The idea is that once you send a fleet it is committed to that destination but everything beyond the first destination is a future order and therefore prone to change. 
• Star type and star trait are listed in the star/colony info panel.
• Speed boost technological is effective only between own colonies. The idea is to help speed up ship deployment but to still have an advance warning when being attacked.
• The game now tracks how many qubits you got from each source instead of one total number. This makes it possible to change rank-based rewards in the future and consolidates data for rewards like beating previous survival record.
• Players are first ranked by whether they survived until the end of the game or not and then by score (within alive and eliminated groups). I entertained the idea of having it possible for an eliminated high scoring player to rank above an alive but low scoring one but this would defeat the point of making a big alliance to take out dominating player and just make alive players postpone concluding a finished game until they outscore eliminated players.
• Computer players now gather at least 3 combat ships before attacking. It's a quick and dirty patch for preventing bots from sending ships one at a time in the early game and just losing them without incurring any damage to an enemy with slightly higher defense tech.
• Research points each player gains is not affected by combat outcomes (such as losing a colony). The amount shown in the research screen is guaranteed and technology advancement happens after combat.
• Survival threat ships spawn at random locations outside the map. Quick and dirty partial unstub of this part of the game until I come around implementing it properly.
• Save file can be exported so if the game is crashing in certain situations, you can help by sending me your save.
• Infrastructure for upgrading save files when the game updates, since now there are players other than me.
• Optional ads at the end of the normal game to increased qubit reward.
  

Bug fixes:

• Fleet orders are properly saved.
• Computer player logic starts properly in survival mode.
• Computer player war declaration trigger properly calculates ally strengths so it doesn't change its mind about relation with the strongest player every turn.
• Computer player doesn't crash when sending troop ships.
  
• Colonization news when the whole map is colonized happens only once per game (was repeating itself every turn).
• Attempting colonization on the already colonized world doesn't prematurely end turn processing anymore.
• Selecting an object on the map doesn't change orders given to a previously selected one. Before, selecting an uncolonized star you don't want to colonize would remove colonization order from a previously selected star, and the same happened for stimulation and factory prioritization on own colonized stars.
  
• Star name uniqueness is guaranteed.
• Technologies can advance by multiple levels if there are enough research points.
  

June

 

Most of June was spent improving rendering performance. Yup, even a game as simple as this can have FPS issues. Occasionally at least. Just drawing the map was pretty fast but any map transformation (panning and zooming) would create a lot of short-lived objects, resulting in a performance drop on older phones. Improving the performance was tricky. An initial approach was supposed to be simple, just delegate translation (result of panning) and scale (zoom factor) numbers to the drawing API. But this also scales things you don't want it to: line thickness and text size. For such cases, I still had to make "manual" transformations but I've tried to minimize the work that happens there.

 

Another big thing, simply due to the amount of ground to cover, this month was more info in the game. You can long tap on almost any UI element in the game and get clarification on it. This is akin to right-click in Master of Orion 2 and Master of Magic.

Other smaller improvements done during the month:

• Limited player length to 2 to 100. 
• Changed starting conditions, each player starts with a fully developed colony and one cruiser to start scouting with.
• Perform negotiations with other players by long taping their names on galaxy map info sheets.
• Increased research benefits to x1.2 per level and changed research cost. The first few levels have handpicked costs and later levels grow by factor x1.5.

Bug fixes:

• Diplomatic contacts are checked when the game is created.
• Prevented homeworld placement overlap that was causing players staring eliminated on a crowded map.
  

July

As of yet, July doesn't come with big works like the previous two months so I seized the opportunity to tie up some loose ends and add improve gameplay. One thing I wanted to do for a long time was to add cheats to speed up testing new features. Like being able to see the whole map when working on graphics or jumping straight to survival mode when working on it. Until now I was modifying code to achieve that but that was always running the risk of inadvertently slipping into an official build. And if nothing else, remembering the place I need to hack to get a certain cheat got old pretty fast. Formalizing cheats into app feature neatly solves those problems and it's easy to limit it only to development builds.

Cheats for ending the normal game greatly helped to test the survival mode, which I wanted to align with the design document. Now the replicators don't send their probes before turn 100, if you manage to end the normal mode before it, and their escalation progression counts from that moment rather than from whenever the survival mode was started. This is mostly to prevent players from building up the economy before entering survival mode but also to not overwhelm players who start the mode early. Another major survival mode change is how replicators move, now their fleets attack a colony that is nearest to their spawn location and then moves toward the center of the map, taking time destroying colonies along the way. Once they reach the center, they stay there, I'll have to come up with something more interesting. Also, replicators now have more varied ship types in the fleet and their tech progression is slower.

Survival mode UI was also improved. Contact list now sorts players by population since the score makes no sense in this mode. Population count is also a good indicator of how long a player can withstand a replicator threat. A moment when a player is eliminated is tracked by the game and game over screen for the survival mode ranks the player in order the managed to stay alive.

Other smaller improvements done during the month:

• Ground defense troop growth speed is tied to the number of factories. Previous constant growth was too fast and messed with bombardment a lot.
• Rebalanced bombardment by increasing base bombardment damage and having chemistry reduce received bombard damage. This way early game when you have a few ships, the bombardment is strong enough but doesn't become overpowered later on. 
• The star with ancient megastructure is guarded by high-tech hostile ships. My favorite strategy for getting an advantage over computer players was to colonize central star early. Admittedly that was super unfair and needed to be nerfed.
• Info sheet raised/lowers state is preserved when ending a turn or rotating a phone. It was annoying to me to have the colony info sheet disappear when ending a turn, every turn. Now I only need to figure out how to keep a fleet selected over turns.

Bug fixes:

• The game ends when a human player is eliminated. It would be an interesting feature to see the computer playing against itself, may I'll implement it in the future. Until it's formally coded, there is no point game going on without a human, both normal mode and survival mode.
• Survival can't be started if a human is eliminated.
  
• Fixed crash when 5 player game ends. An interestingly specific corner case :).
  
• Fixed normal game always giving a maximum reward. For some reason, the reward was determined at the start of the game and updated only when loading a game (when a particular object was recreated).
  

Month of polish

How would have thought that polishing UI would take so much time? Or conversely that there are so many UI components to pass through in such a simple game.

But don't expect fancy graphics and sci-fi fonts just yet. By polish, I meant raising UI from "just enough so it works" to "not an eyesore anymore". This still required checking placing and spacing of elements, adjusting their size, making the stuff that can grow large is scrollable, and repeat all of that for the landscape mode. Yup, you can play the game like a game now! Though I find portrait mode more practical for mobile apps, especially when not seated, stuff just looks nicer in the landscape mode when an app supports it adequately. I'll add some fancy sci-fi look and feel down the road but I have to first decide on a general theme of it.

Along the way, the contacts screen got renamed to diplomacy and made into the list of the known status of all players. It shows your relations with them (peace with uncontacted ones) and a score of all players, including yours. The screen sort of doubles as a leaderboard now.

Qubit spending screen got a little bit of functionality change too. You can't reallocate bonus levels arbitrarily anymore, you can only refund the levels you bought in the current turn.

Global news screen got a bit of controversial update, it shows a banner ad below news text. I'm not a fan of advertisements either but I'm not making this game entirely for free. There will be some monetization in it but I promise there will be no evil schemes. The banner will show only on the news screen, the galaxy map screen will be free of ads forever, and the news screen will not show for minor news if a certain number of turns did not pass since the last news item. Why did I decide to put an ad banner there instead of a more prominent place then? Well in most games a news screen (like GNN in Master of Orion games) is made to look like a funny version of real TV news: anchorman, news text and image in the primary screen area, and some white noise running at the bottom, usually a scrolling text with some jokes. In a way, I've placed an actual advertisement as a joke. Hopefully, you won't find the fact offensive.

There were some minor gameplay changes implemented this month. Restrictions on what you can see on the map are now enforced properly:

• A star needs to be scouted in order to learn its planet size
• A star needs to at least be inside your vision range to know if somebody else has a colony there
• You need to have a fleet at the star to see other's colony population and factory count
• You can only see the immediate next destination of other's fleets, not all waypoints
• As before, other's fleet has to be in vision range to know about it at all
  

And there were some bug fixes too:

• The colonization checkbox won't flip its state when clicking around the map anymore
  
• Another case of a computer player hanging in an infinite loop fixed
• Research progress not working properly after loading game fixed
  

The problem with the colonization checkbox was basically that the Android UI framework, like many other frameworks, doesn't make a distinction between user clicking/taping a checkbox and code setting/clearing check mark. So when selecting one uncolonized star after another, without deselecting or selecting some other type of object in between¸ the UI update logic would inadvertently set the colonization checkbox of a previous star to the state of the next one.

The research progress bug was an interesting one, after loading a game it was possible that multiple research fields (across multiple players!) would get research points simultaneously at the end of a turn. After loading, multiple research fields would share the same research progress describing object so investing points in one of them would advance all with the same object. It was hard to pinpoint down the exact moment when that object would get shared because save file data would look normal (no object sharing) and for no visible reason research loading code would make some objects shared and some distinct. And it was a single line of code on my side manipulating a data structure from a standard library, so a debugger could not step inside and let me see what is going on. After reading the documentation on that data structure (HashMap) very carefully, I've learned it doesn't behave as it does in other programming languages. Java Maps and their subclasses override default equality functions so two maps will show up being the same if their key-values are the same. In C# and other languages, the usual practice for collection's default equality function is to just check if memory addresses (references) are the same and have a separate function for testing item equality. Fortunately, the fix was not that difficult, I only need to change how caching identifies which objects have been loaded and have cache users work with that identifier. Each saved object already had a textual name so I just used that instead of a reference to the object's save data.

Phase two progress

The game development is progressing, a bit slower than the previous year but it is progressing.

I should really make some more descriptive names for the development stages. Phase one, two, three are not descriptive at all, and alpha, beta stages are not applicable. By those labels, the project is still in pre-alpha and will be for some time. Let's call phase one stubbing phase because in that phase all features are technically implemented but with stubbed details. Things that are left out are mostly content, say for "the colony builds ships" feature, the code for building queue and general construction item is written but there is only one ship type to build, just enough to test the feature. Parts of logic that are left out or stubbed are mostly ones that give a game feel but don't affect the structure much. For instance, for the map generation, it's enough for the first phase to have it place player homeworlds at the first few stars in the internal star list and have the proper placement be implemented in the second phase. Consequently, let's call phase two the unstubbing phase, where loose ends from previous phases are addressed and the actual content is added. This phase still has a lot of work to do so I'd add a third phase for fully finishing (polish, test, release) the game.

Stuff done since the last post:

• Game creation settings - map size, player count, human player name, and color
• Players can have one of 7 colors
• Unstubbed map generation
• Map zoom and pan limits
• Different star types
  
• Cyclic building queue
• Factory count can be fractional, like population
  
• 3 combat ship types
• Constrained ship movement
• Pathfinding
• Unstubbed computer player logic
  
• Player scoring
• Players can have custom supplementary data
• Qubit bonus cost increases with level
  
• Graphics (serviceable, needs improvement) for all ship types, factories, and icons on a map screen
• Improved ship movement visuals (not hidden below star when starting, the icon is facing movement direction)
• Graphics for each star type and trait
  
• Decimal number formatting
• Automated tests for utility code, almost all colony features, space combat
• Automated test integrated with repository host's CD/CI pipeline
• Various bug fixes
• Various code refactoring
  
• Design document
• App store listing and release draft

Looks like a lot but it has been 3 months, and real life situation that prevented me from posting updates here also prevented me to do more development. Even after accounting for repurposing blogging time to actual development and hours not reported to a time tracker (prototyping graphics, fill out app store information, writing design doc), time spent on the project has been about 1/3 less than in October and November last year. There was definitely some execution friction too. Having worked for years on the Stareater, I'm very comfortable with the stubbing phase and pure coding. The unstubbing phase feels very different, there are a lot of non-coding tasks and coding too is different. You have to make sure the game logic works for all inputs, not just ensure that code compiles and doesn't crash. This increasing the pressure to have good automated tests which in turn begs to have a thorough document describing which features the game has and how exactly do they work.

Computer player development was an interesting experience. Again, an area I only dipped my toes a little until now. I tried to make a simple implementation of every major area (scouting, colonization, ship movement) but almost all areas quickly grew in complexity. Then I decided to write in plain English words how a bot utilizing all game mechanics should behave and then turn those words into code. 90% of bot logic ended up being information analysis, 8% selecting the proper amount of assets, and 2% actually giving orders. I haven't fully play-tested it yet but it appears to be good at scouting and colonization. Diplomacy logic needs more work, at the moment it doesn't consider who is where on the map so it may declare wars that make sense from a relative strength perspective but not a map situation. Attack staging logic should be improved too because if war breaks out too early it will send ships one by one and just lose them without inflicting any damage.

Adding ship types, star types, and changing movement logic were more of standard coding tasks. New ship types have a rock-scissor-paper relationship when it comes to the space combat cost-effectiveness and they behave a bit differently outside of the combat:

• Battleship - strong against cruisers, expensive, good at bombardment, no movement penalty in a nebula
  
• Destroyer - strong against battleships
• Cruiser - strong against destroyers, no movement penalty in an asteroid field

I'd like to add more galaxy speed to cruisers and something to destroyers but nothing natural to an anti-armor unit comes to mind at the moment. Star types for now only affect ship movement speed when leaving them but there too I'd like to add more later:

• Normal star - no special effect
• Dwarf star - double ship speed
• Giant star - half ship speed, would like to make it have smaller colony size
• Dense asteroids - all ships except cruisers have half speed, would like to add production bonus
• Nebula - all ships except battleships have half speed, would like to add the ability to hide ships

Ship movement modifiers are just the tip of the iceberg of the new movement system. Now ships have a limit to how far they can move at a time but by doing multiple hops they are free to travel anywhere. The hop range is about 2 star distances. The idea is basically taken from tiled tactics games, enemies should not be able to just move through each other without triggering combat but otherwise, the space should be open to interstellar travel.

Introducing multiple ship types invalidated the idea that a warship is implicitly at the end of a building queue because there is now a question about which type of warship. That's why there is a cyclic queue feature, you have to enqueue warships types manually but they will rotate in the queue as they are built. So once you set up desired fleet composition the colony will continually produce it.

At this point, I've regretted not having automated tests. There were multiple combinations of repeating and non-repeating construction projects I had to manually test after every single change to the building queue code and each run would uncover a faulty scenario. Manual testing didn't take so much time, about an hour in total, but I feel like I've aged for a whole day in the process. Making an automated test for a game was a bit of unfamiliar territory for me but it turned out making a minimal game state for a test was an easy thing. In a Java/Kotlin project it is very clear what is a "normal" code and what is a test code so you can have tests reach into what would otherwise be internals of the module and not have the test and test supporting code included in the release build. In the process, I dipped my toes in the CD/CI + Docker fanfare and set up a pipeline on the code repository host that runs tests on every code change upload. Not super useful, especially due to the limited monthly time budget but I learned some cool tech and I can set up something similar locally to trigger on every upload attempt.

Admittedly, code coverage is not that great at the moment. I'd say slightly less than 10% and the thing that needs improving first is how to tell what needs covering. Test framework can calculate line coverage but that's a very flawed measure that at very best overestimates the coverage. Having a branch coverage figure would be much better but ideally, there should be a way to tell how many features are covered. I'm trying to think of something that would do like that but for the time being, I'll have to rely on fallible human brain to sync tests with the design document.

This is the first game, heck first program, I have made a complete design document. It took a few failed attempts on other projects and three on this one. Almost a year before I've started coding Ancient Star, I've drafted a high level design document. From it, I've removed a bunch of features to simplify the game and made another document. But both of them were not really useful so I've made a third one, with low level details, explaining every detail of the game rules. It is 10 pages long, plus table contents covering a whole page height. And this game is supposed to be simple!

Not being an artist I've managed to make some decent looking graphics past few months. Here are star types (the last one being a normal star with the "ancient star" trait):

I'm proud of the result but don't ask me how I made them. Hint: they are coded rather than drawn. Ship images are more of traditional drawing, made in Inkscape, measured, and rewritten to SVG instructions. They are so so, not very pleasant but at least they are distinct. I'll rework them at some point. Here you can see ship images along with other graphics (factory, research, diplomacy, supply icons):

And last non-coding task that is more or less done is apps store listing. All the necessary "paperwork" is done, data is entered and a test release draft (signed app package) is made. I'd still like to do another pass on the long description, make proper a feature image and add more screenshots before hitting a release button for real.

Ancient Star - phase one complete

Diplomacy, vision range, and survival mode are implemented. This concludes phase one of the project where all major game features are implemented in at least rudimentary form. Two weeks ago I wasn't joking about the phase getting nearly over.

Once you get the other player (ship or colony) in your vision range the diplomatic contact is established. From that point, both parties can select the desired relation toward each other. Relations are war, peace, and alliance and the effective one is the worst one the involved parties have selected. If one side has selected peace and the other side wants alliance then the peace will be in effect. So war is the easiest to declare while the alliance requires the will of both sides to ally.

By default, players are at peace and it takes a declaration of war to be able to do any combat action. For now, alliances don't force any relations and military action to third parties. They are purely a peaceful way to end the game. Once every player is in an alliance with each other, the game ends. It sounds cheap but remember, there is a ranking system involved and not everyone will want to end the game while they can still improve their standing.

Once the game ends the player is rewarded with qubits and has an option to start survival mode. Yup, there is a premium currency in the game, and I promise to play nice with it. In the survival mode players fight increasingly stronger waves of enemies coming outside of the map and the goal is to stay alive as long as possible. Also, in this mode qubits can be spent on additional bonuses. For now, the bonuses are bigger industry, ship attack, and ship defense multipliers per technology level.

The next step is phase two, of course :). In the second phase, I'll work on improving the quality of the game, do the preparation work for publication on Google's Play Store, and at the end of the phase have the game available for beta testing.

Ancient Star - basic AI and news screen

With AI infrastructure and news screen, phase one (basic feature implementation) of the project is getting very close to being completed.

Having calculations run in the background and affect UI at the end turned out to be very simple. So now there is AI that controls "bot" players and plays them all in parallel in the background. It has very basic logic for now: build scouts, visit unscouted stars, build colony ships, and colonize everything available. In the future, the logic will be more elaborate and goal oriented.

This required some changes to the code structure. Controller classes players use to read and manipulate the game state have been moved from UI to game core subproject (where game data and game logic is) so in theory, AI can be coded without being a part of an Android application. And the other change was to how a turn is ended. So far the human player had absolute control over the matter but now each player marks their turn as ended. The next turn is processed when all players have ended the turn.

When a certain portion of the map is colonized news screen triggers, informing all players about the event.

 

Again, a simple-looking feature that had more going on under the hood. Now there is a proper concept of player events, uniting tech advances and news items. On a new turn, UI runs through the list of new events, switches to relevant screens, and moves to the galaxy map once all events are cleared.

Ancient Star - autosaving, money, Orion?

The feature "to do" list is getting smaller and smaller. This week three features got implemented: a special star, monetary colony stimulation, and autosaving and continuing a game.

The reason why the game is named the Ancient Star is that there is a special star on a map (for now in the center) which holds remnants of an ancient civilization. Colonizing that star will grant a considerable research bonus to the owner and will be the center of a conflict after the end of a normal game. There is more foundation for future work there, all stars can have a trait and "ancient" is only one of them. In the future there will be more traits, affecting ship movement and colony productivity. I'll come back to this after I implements movement range limits.

Next feature this week: money. Money is gained passively from the population working in factories and can be spent on multiplying colony productivity (both industry and research). For now, numbers are 0.2 credits income per manned factory, and spending 1 credit yields the same amount of industry and research as 1 unit of the population would produce. Money doesn't improve ancient ruins bonus and research during construction. Initially, money can only double colony output but each point of sociology tech improves that multiplier by 10%, exponentially. So later on stimulation can seriously jump-start fledgling colonies. Also stimulating multiple colonies without big enough cash reserve will spend whatever cash there is (tax income + cash reserve) equally over all stimulus receiving colonies. So if you stimulate all of your colonies you'd get a 20% boost.

And finally, I've recovered from serialization burn out and integrated the thing with the rest of the game. Now the game will autosave when you navigate away from the galaxy screen or the game app as a whole. When the autosave file is there, the game can be continued later on.

Ancient Star - game over

Now that there are means to end the game (bombardment and ground combat) it is a good time to make the ending itself.

Many 4X games are about the journey then the destination and some of them tend to have no fanfare at the end because of it. This bugs me more than it should, I like to finish all my games and the lack of acknowledgment at the end feels unsatisfying. That's why I've made it this "early" in my project. It also makes me think more about the overarching question in game design: what is the goal? Usually, 4X games have victory conditions where there can be only one winner, and that in my opinion creates a lot of game design problems. Mainly, if you win by eliminating everyone then the end game is one interesting conflict followed by a long and repetitive mop-up phase. If there are multiple victory conditions then you are likely to get a situation where everyone is playing almost a different game that abruptly ends when someone else reaches their goal.

In the image above you can see players ranked by some score (1, a mock value). Meaning I'm experimenting with something different, instead of trying to be the only winner, players are trying to be ranked as high as possible. I'm also pondering the idea of having a score that doesn't feed directly into military power to have some opportunity cost of being higher ranked. I made a similar system in the Stareater where you directly "sacrifice" your colonies for the score but since the game is not finished yet I still don't know the real downsides to it and I want something less extreme in this game. At first, I thought of using the population as a score but when someone gets eliminated, their population will be zero or, depending on when elimination counts, some low circumstantial value. Also, the population is a direct indicator of economic strength and to an extent military potential. So I thought why not research points? They are the closest to representing the art and culture of a civilization, they are accumulating value so they can't be taken away, and counter-intuitively, having a lot of research doesn't directly indicate a strong military or economy. Heavy research is an investment that trades "now" for "later" and makes you vulnerable in the meantime. 

Anyway, nothing is set in stone yet and a mock score of 1 will stay for a while :).