Making progress

There are some good news and bad news.

First, the bad news. Releasing the new version is taking longer than I expected, because when I went back to galaxy generation and camera and scrolling, I fixed some other related issues, and new issues kept coming up. Every time I fix an issue, I discover yet another issue, but I promise that the overall enhancements/optimizations/etc will improve the game!

Now, for some good news that's related to the bad news. I've finished the system and fleet mouse selection, fleet selection is working again. No user interface for that yet (splitting fleets, sending them to a destination, etc) However, when I clicked on a fleet, no fuel range showed up. This puzzled me for a moment, then I realized that I refactored the circle algorithm to only handle returning a filled circle, not fuel range. So I just need to simply rearrange the code a bit to use this return value. When I started on this, I realized that currently there are only two values for each grid cell, passable or non-passable. What if there's nebulaes, shouldn't they slow your ships down? What if you research a technology that slows down the enemy fleets within range? Both concepts are from MoO 1, and those I'd like to implement. This means I'll have to overhaul the fuel range/grid cell system to allow for this.

I'm sure in the end, when I do finally release a version, you'll notice a lot of differences! I might even add nebulaes to test the pathfinding!

System Overhaul

A friend of mine and I discussed about fuel ranges, and we pondered about what would happen if you lost a system that's connecting your other systems (getting cut into two separate regions that can't reach each other). As it is now, construction points will still apply, so if I have one system that's cut off from the rest of the empire, it can still build ships. Which could become an exploit (trade a planet to an ally that have massive construction advantage, and he can pour ships to that system).

So I decided to remove the construction screen, and change the ship construction to be system-wide. No more list of ships to build, you'll have to go to each system and specify which design (or projects like stargate) to build. It'll be almost the same as Master of Orion 1, there will be a slider specifying the amount of funding to go into that system's construction. The total factories is a sum of all factories on all planets in that system that are under your control.

However, research is still accumulated from all planets into one place. Farming is system-wide only.

I'm working on planetary development "screen". It's not really a screen, more like a tabbed section under the list of planets, like MoO 1. If you select the system's star, you will see the ship design that you want to build, funding for construction and farming, and the system's food consumption. If you select a planet, it will show you the planetary development funding (three sliders, one for each field, factory, lab, and farm) and last turn's pop growth/decline.

If a planet maxes out on an area (factory), the excess funding will go back into your reserve, and the slider will be set to 0.

With this system, it's easy for me to add or remove planetary aspects (pollution, terraform/ecology, etc). For now, there's only factories, farms, and labs. If I add pollution cleanup, that means I can add a racial perk that either reduces pollution or ignores them (like Silicoids), making the races more diverse. But I also don't want the game to be overly complex.

As soon as I get planetary development and rest of user interface working, I will release a new version. You should be able to notice a lot of differences and improvements.

Here's a screenshot to help illustrate what I'm working on. Notice the missing "taskbar", I'm still working on overhauling the user interface. Sliders are there now, the screenshot's a bit old.

Galaxy scrolling/zooming done!

I've finished converting the galaxy mouse input to support the recent changes. The galaxy now scrolls around SMOOTHLY! It uses acceleration/velocity formulaes to achieve the smooth gliding feel.

Zooming in/out is more accurate now. Previously, when you zoom in, it'd kinda zoom into where your mouse is pointing, but felt that it jumped around a bit. Now the same grid cell that you're hovering above will stay in that area while you zoom in. As for zooming out, the grid cell in center of your screen will stay in center. It's a lot more nice now. I really like how it looks/moves, and I doubt I'll tweak it any more. The only thing that I think I will add is a slider that determines how fast you can scroll around that you can set. But that's for later...

Stars and fleet icons and fuel range and paths are all being drawn now. However, the "taskbar" and mouse selecting fleets/stars, and the UI aren't working yet. I plan on overhauling the UI to use an UI class that automatically handles buttons/sliders/etc. Once that's done, I can easily add in more screens (planetary development, etc)

I may have bitten off more than I can chew...

My decision to change the sprite code stuff into a sprite management class had a cascading effect. I went back to the sprite code and changed them to use the sprite management class. While doing so, I noticed that quite a lot of code depended on the sprite's size information. So I had to fix those as well. While fixing those, I realized that the camera wasn't as independent as I wanted, it depended on the sprite information as well!?!?! So I removed the code that depended on the sprites, and realized that I've been doing yet some other stuff wrong!

Long story short, I've decided to comment out most of my code for later review, and focus on galaxy drawing and camera manipulation. The cascade effect reached as far as the galaxy generation! I decided to remove the "special rule" I had for star system and grid cells. How it worked previously was that star systems and grid cells have two separate coordinate system. One star system grid cell is equal to 4x4 grid cells. If I say a star system is at 2,3, it actually means 8,12 in grid cell. This is why all the stars always line up, you don't see stars out of alignment.

So I changed the star system to base on the grid cell layout, this means the stars can be staggered. I'm currently in process of tweaking the circle algorithm to incorporate this change. It may take me a couple of weeks or more to get the game back to something like the latest released version, but I promise that it will be a lot better, more smooth, and more elegant.

Ugly code

I created the graphic manager class that will handle sprites and animation. However, when I went through my code and making them use the new class, I realized that the way I did things weren't quite correct.

How it works currently is that it loads the sprite, then uses that sprite's size to handle input and stuff. If I add a button that's 1,000 pixels in height, it will cause the game to draw the whole thing, overlapping everything.

So my plan is to call the drawing function, and tell it the size I want it to draw in (for example 200x40), and it will scale the sprite if necessary to fit in that size. That way, I can separate the input handling from the sprite size.

After that's done, I plan on revamping the galaxy drawing code. I plan to increase the resolution of fleet icon and star sprites, and implement smooth scrolling/zooming. Right now, it jumps one star's size in a direction when scrolling. I also want to fix zooming so it's more accurate in zooming in. When the end of turn prompts "You have explored" or "Select a planet to colonize", I also want them to focus on the star system in question.

Refactoring time again!

When I started work on planetary screen, I realized that I'm doing some things wrong. Each screen have its own list of sprites that it stores. And for each button I basically re-invent the wheel for every screen. So each screen have its own sprite of the same sprite (for example, button in galaxy screen is also duplicated in construction screen, taking up more memory than necessary), and I have to re-program the button functionality for each screen.


This is making the progress slower than it should be. So what I'm doing is to create a GraphicManager class that handles sprites, and all other parts of the game will call this GraphicManager to draw a specific sprite. GraphicManager will also handle animations and return whether or not a mouse click is within a sprite's area. Maybe even handle slider bars and some other basic user interface stuff.

What this will do? This will make creating new screens a snap, since I won't have to reprogram each button's interface. So bear with me until this is done. I think when this class is done, I will add twinkling stars, rotating planets in planet list on galaxy screen, and some other nifty superficial visual effects :)