Small update

I squashed several bugs and refactored some of the old code so it's more clean and easy to fix if any problems pop up.

I've decided to change from random 6 planets per star system to user defined amount. At the new game screen, there are two new options. They are Minimum Planets and Maximum Planets per star system.

By default this is 0 minimum (no planets at all) to 6 maximum. You can change it to be 1 minimum and 1 maximum, and every star system will have only one planet (aka MoO 1, except for some system having no planets. With only 1 planet, the generator will populate only half of the stars with a planet if the minimum is set to 0), or you could change it to 0 minimum and 5 maximum (aka MoO 2)

The maximum "Maximum" value is 100, and minimum cannot be higher than the maximum amount, but can be equal if you want to force equal amount of planets per system.

100 planets per system may be a bit excessive, but I don't want to force limits on some players who want more than 6 planets per system. My goal is to give more choices to the players, so they can try many different scenarios, therby increasing the replayability of the game.

Currently I'm working on scrollbar class, so the players can scroll through research items, construction items, etc. When that's done, I'll focus on the galaxy screen and start implementing fleet movement and exploration.

Optimizations, Empires, and Exploration, oh my!

The galaxy generation code bothered me a bit. In a previous post, I talked about optimizing it so it's somewhat faster. But if I do 800x800 random galaxy, it takes my computer over a minute to generate the galaxy (it's a quad core with 4 gig of memory), and there were only like 4,000 stars when it was done. Surely my computer can place 4,000 stars randomly faster than that, so I brainstormed for a faster algorithm. Then it hit me, I can use the quadtree concept I used for galaxy drawing to generate the galaxy. Here's how it works:

Parent node encompass the whole galaxy, and have subnodes that divide the galaxy. This continue to branch until each node are only 1x1 in size. I then tell it to remove nodes that are in illegal areas (for shaped galaxies). Then I tell it to randomly find a node and give me its location. After getting the node, I place a star there, then remove the adjacent nodes. This continue until there's no more nodes.

The end result? The same 800x800 random galaxy that took over a minute to generate now generates it in about 2 1/2 seconds! This is a major optimization! As a result, I'm satisified with how it works, and its speed. I seriously doubt anyone will play in those huge galaxies, but just in case they do, they won't laugh at my generation code.

I've started importing some stuff from the old code (before I started refactoring the whole thing), and did some code improvements and cleaning up. Planets are back in, and each star system can have up to 6 planets. The "IsExplored" is added, and the function "SetHomeworld" is implemented. Starting a game from the new game screen now creates homeworld for each of the player.

I also added an EmpireManager that will manage all the empires. When a player hits end turn, Empire Manager will iterate through each empire, and if it's computer player, execute the AI code, otherwise halt and let the next human player play. When all empires are done, then end of turn will commence. There's no "End Turn" yet, but the Empire Manager will help organize the code for me.

The exploration functionality is there, so when you start a new game, you only see your own home system's name. All other stars don't have their names displayed.

Now that my goals as stated in previous post are accomplished, my tasks now are to import all the old code and re-implement them in the new code. This includes colonization, exploration, fleet stuff, end of turn processing, and other stuff. When those are done, you'll be able to start a new game, select the galaxy shape/size, select players, and start it, then explore/colonize. I might throw in planetary development, but no promises!

Still working on it!

Sorry about lack of updates. Things kept me busy, mostly me getting sick :( But I've become better.

I've worked on the game, and it now transition between different screens (clicking on new game takes you to new game screen). I also modified the player options. Instead of having three dropdown menus per row, I combined two (human/computer and difficulty) into one, so it looks like this:

Human

Computer - Simple

Computer - Easy

Computer - Medium

Compuer - Hard

Computer - Impossible

One thing to note, it's possible to have more than one human in the list of races, which allows for hot seat multiplayer, or for you to control two or more races. Or you could even have only yourself in the galaxy (for testing an expansion strategy perhaps?).

I've also optimized the galaxy generation code so it creates a new galaxy a lot faster (about 1/28th the time it took previously). But it can still be optimized more, I may look into methods for that. But for now, it can generate a galaxy with about 2,000 stars in less than 5 seconds. I doubt anyone would play a galaxy that huge, but the option is there if they do want to.

I'm currently working on the galaxy screen, and optimizing the drawing process (I don't want to iterate through all 2,000 stars if I'm zoomed in and can only see 4 or 5 stars). I've discovered a method that will help speed up the process, which is the quadtree. It's kinda like a binary tree, but with 4 children per node. I'm also working on the galaxy setup when you click on "Start" after setting up the new game options, it populate the galaxy with races that you've selected.

After those are done, I'll re-import the old code I had before I started the whole refactoring process, which includes colonizing planets, fleet movement, planetary management, population migration, empire income/expenses, ship construction, exploration, supply range (fuel range) and maybe some other stuff that I forgot. Then I'll release that version for testing!

Camera working, and ship placement algorithm done!

As you can see, the ships are arranged so the biggest ships are in the middle, with smaller at top and bottom. The algorithm works like this: Sort the list of ships from smallest to largest. Fit as many ships as possible on the frontmost column (facing the enemy) starting from smallest, but place the largest ships in middle. If more ships than the column space, then put the rest of the bigger ships on the next column, a bit farther from the enemy, and so forth until all ships are placed. This took me a while to finally figure out, but when I figured it out, the solution was so simple I'm kicking myself for not thinking of it sooner.

I've also tweaked the camera class so it can work with either the galaxy viewing, space combat, or ground combat. As a result, I can move around the space battlefield and zoom in/out.

I've also figured out a simple solution to the UI problem with the new game screen, so things are looking up! I think I will leave the space combat screen as is for now, and finish up the new game/main menu, and add transistions between different screens. Then I'll reimplement the galaxy screen from the older version, and hopefully it'd be kinda playable.

First space combat screen!

I've decided to put the new game screen on hold for now, and focus on creating some other screens, because the user interface was giving me a headache. So I decided to work on the space combat screen because that's the most fun part of the game! Seeing your ships pwn the enemy ships (or vice versa, which isn't as fun)!

There will be max of 16 different ship sizes, I've taken a screenshot of the initial combat screen (all it does is display the ships properly, along with the amount of ships stacked). The ship on top left is the smallest (16x16 pixels, or size 1). The ship under that is size 3, the ship on top right is size 5, and the bottom right is size 16.

I've thought long and hard about how the space combat should be like. This is what I've decided. Ships will stack, like in Master of Orion 1. However, the combat field is bigger than the screen, so you can look around, zoom out/in (maybe), etc. Defending ships will always be on the left, while attacking ships are on right.

Since this game will incorporate some physics (if you don't see a beam hitting a ship, it don't hit, and vice versa, similar to X-Com), weapons will perform a bit different from MoO 1. Here's the sum:

A weapon with many mounts (say, 10 cannons), will each fire in succession, so it will shoot 10 times visually. The topmost ship will take damage, and if it is destroyed, the next shot will hit the next ship, and so forth.

"Streaming weapon" means that it penetrates the ship, dealing damage to it, but continuing beyond the ship to potentially hit another ship. Imagine rail gun from Red Faction. It won't "carry over" to the next ship in stack.

Exploding weapons (such as anti-matter torpedoes) impacts all ships in the stack, so it is more powerful the more ships are stacked. Black hole Torpedo is included in this category.

Missiles will be treated individually, if enough damage is done to destroy a ship, the remaining missiles will hit the next ship, and so forth.

There may be other special weapons, and special shield characteristics (a shield that bounces off energy weapons for example) that may affect the tactics.

I'm excited to see the combat screen fleshed out!

Player selection layout implemented, somewhat

Here's a screenshot of the new game screen. It will have up to 12 players. If you're playing a local game, you can select either human, computer, or none for each player. Having more than 1 human controlled race will allow for hotseat multiplayer.

I'm still working on the layout, but implementing this showed a very big bug. The dropdown menu that is drawn before the next one, but overlays it, will be drawn underneath the next one. You can see this in action in the screenshot, at second to last player.

I'll have to think about how to fix this, but at least I'm making progress!

Dropdown menu is done for now, TextBox is next

The dropdown menu code is functional, with the exception of scrollbar. I can click on up/down arrows and it'd change the list accordingly. But I don't want to dwell too much time on this, so I'll leave it as is, since it's working, and focus on the last important User Interface element, the TextBox.

When TextBox code is finished, I'll have all the important UI elements available for me to use in all parts of the game. Things will progress a lot faster. I hope to have a playable version by this Dec.

Dropdown menus and "New Game" game setup screen

Since I'm refactoring the galaxy code stuff, I figured that it'd be a good time to start adding "Main Menu" and "New Game" screens. The main menu would have six buttons, "New Game", "Continue", "Load Game", "Multiplayer", "Options", and "Exit Game".

New Game screen will be used in both single player and multi player as a pre-game lobby setup. I've finished the galaxy previewer, so you can generate a galaxy, and it'd show up in the previewer. When you start the game, that exact same galaxy will be the game's galaxy. I've added a new feature of having stars being different sized (2x2 to 4x4). It don't really change the gameplay much, just adds a bit of variation.

I'm also working on code for drop-down menus. When that's done, I can just do this:

Combobox galaxyType = new Combobox(...), and it'd set up the combo box for me. Then I just do this:

galaxyType.Draw()

galaxyType.Update()

and it'd take care of the rest of mouse handling and rendering. It's mostly done, I just need to implement text and scrolling.

Here's a screenshot of the "New Game" screen, it only have the previewer and galaxy type drop-down menu with no text. But at least you'll get the idea.

Still working!

Things have slowed down a lot recently because we're busy with the new house. There's a lot of small things that we needed to do (replace some broken shingles, paint rooms, etc). Also, I've been busy with Worms Reloaded. Shame on me for playing another game when I should be creating my game! :)

I'm going through some refactoring that will help me be able to add in new things more quickly. I've refactored the button code so it just needs two sprites, instead of 5 like before. I'm in process of creating a "GameMain" class that handles everything from main menu, networking (if I ever implement multiplayer), to galaxy screen and battles. This will organize the code better.

I've worked out the last design issues of battle screen, galaxy screen (movement and colonization), and players' turns. You will see it when I'm done refactoring and tweaking. Sorry, no release in October :(

I wonder if anyone is still reading this...

Busy with real life...

In the last month we've moved to a new house. There were a lot of repairs to be done, and I've been busy with both work and the new house. I managed to get some work done, the galaxy UI is nearly complete. Just need to hook up the end of turn processing with the button, and change the way the ships are built, then I will release a new version, hopefully during Oct sometime.

Sorry about not posting in a while.

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 :)

New Version Released!

Here's a screenshot of the latest version, showing the construction screen, and the empire's financial summary.

I was unable to implement spending cap, so right now you can spend unlimited amount on construction. However, note the overrun cost in the screenshot. I want only 294 production points, but I only have 50 factories. Overrun works like this:

first 50 production points = 1 BC each

next 50 PP = 2 BC each

next 50 PP = 4 BC each

and so forth, doubling every time the total factories output is reached in each iteration.

It lists the overrun cost as 2664. So 2958 - 2664 = 294 BC

If I had 294 factories, it'd only cost me 294 BC. So overruns are very very expensive. There will be technologies that you can research that will reduce overrun costs.

Now, without futher ado, here's the download link for the latest version!

http://www.mediafire.com/?2p9sly1yjghsfbx

Make sure you have SlimDX installed

http://slimdx.googlecode.com/files/SlimDX%20Runtime%20%28March%202009%20SP1%29.msi

On a side note, Joseph pointed out that it's my game. While that's true, if it's fun for me, I'm sure it'd be fun for others. But I want to polish this game as much as possible, which requires other point of views. I will incorporate ideas and suggestions that I think are good and fun for the game, as well as my own ideas :) So feel free to leave feedback!

New Release Tonight!

I've been working on the economic aspect of the game. Tonight I will release a new version after I'm done working out the kinks. What it will feature:

Fixed idle fleet merging bug
Empire Reserves (if you don't spend all of your income, it will go into reserves)
Ability to spend more than you earn if you have reserves left.
Interest rate for reserves, they will earn some money even if there are no money going into it.
Capped spending.

What's with the capped spending? When you click on "End Turn", it will check to ensure that you have sufficient income AND reserves for your budget that turn. If you're spending more than you can afford, it will prompt you to adjust your budget. You cannot end turn until the budget is fixed.

While I was working on the economics, I thought of a couple nifty features that I haven't really seen in any other TBS games. Borrowing money with interest rate, and liquidating.

Let's say that you have an ally that's earning a lot of money. You hit a rough patch, and ask your ally to lend you 200 BC, with some interest rate. The 200 BC is directly deposited into your reserve, and you pay your ally back each turn automatically, plus interest. So let's say you take 20 turns to pay back your ally, with some interest rate. So you pay 15 BC per turn, which results in a total payback of 300 BC.

The amount of turns and interest rate will be set automatically, so you just ask for an amount, and the game will handle the rest. Advances in technology will enable you to get a lower interest rate.

Now what happens if you can't pay your ally back? It'd prompt you saying that you can't afford your budget. The best thing to do is to scrap your ships (reducing the upkeep, and getting the scrap money to pay back). If you don't want to scrap ships, or don't have any ships left, then the next option is to sell some of your planets. Each planet will have an "estate value". Newly colonized planets sell for a lot less than a fully developed planet. (Think of Russia selling Alaska to USA)

This will present an interesting twist to the game. An empire gets wiped out because it managed its funding poorly. All of its ships were scrapped, and all of the planets were sold. I don't think I've ever seen a TBS with this kind of defeat. Master of Orion 3 came close, with sections of empire revolting away if the empire is approaching bankruptcy.

In diplomacy, you can trade planets, but each planet will have its estate value listed, so you could trade one of your fully developed planet (worth 400 BC) for four of his planets (worth 395 BC total). Or trade technology for planet, or money.

Back on topic of development, I plan to work on planetary development after the update is released. It will feature a couple of things that you can develop on planets: Factories and Labs. It's not a complicated screen, just that there will be some tedious user interface programming.

Concept art

This is the concept art I've drafted up for the construction screen. On bottom left will be your empire's financial summary, it will be visible in all screens except for battle. In the construction screen itself, on bottom left is information about your production capacity and how much you're funding construction. On right is list of ship designs, then amount of funding, then amount per increment. If you set it to 5, then every increment you make in either funding or ship construction will add 5. This allows scaling

On top left is the ship's design, helpful if you want to review which ships you need (ie, torpedo ships or missile ships? Bomber or ramships? etc etc)

Feedback on this layout (aside from art, which I know sucks)?

Beyond Beyaan Economics

I've been thinking about economics for Beyond Beyaan, and I feel that I may be over-simplifying things by just developing factories on planets, and those factories will produce BCs (billion credit) where you spend on research, construction, or planetary development. In Master of Orion 1, you could have 1 to 8 factories per population unit based on your current tech/racial bonus. They contribute to whatever construction effort you have on that planet. That's not really "realistic" So I worked out a more accurate economic model.

Here is how it will work:
Each planet will have three components:

Population - They will spend money on consumer stuff (food, toys, homes, etc), resulting in BCs for you to spend on. The more population, the more BCs you get. This will not be dependent on factories. So having an undeveloped planet full of people won't be so useless, they'll give you money to spend! Population growth means that they're developing infrastructure and small businesses and stuff. Also, population is a factor in planetary development, the more people you have on a planet, the less cost overrun you will encounter building factories/labs there.

Factories - Those are big factories capable of producing parts for starships and other major constructions. They will reduce the cost of building starships. If you start with a planet that have 10 factories, you can spend up to 10 BC before you start getting cost overrun. Cost overrun is basically stretching the factories capacity at diminishing return. Think of overtime pay for employees, equipment breakage/repair, etc. The more factories you have, the less overrun you'll encounter in building starships.

Labs - Those are government-funded facilities that allow you to pursue your research. This will work in a similar manner to factories, but with research.

I think this system will still keep things simple, but make things more manageable and less abstract. If you set up trading agreements with other empires, they contribute BCs, but not production or research points. So even if you have tons of BCs coming in from trade/population, if your planets aren't developed, you'll have a hard time building things.

Comments? Thoughts? Feedback? Feel free to comment!

Initialization!

I've created this blog as a place to put updates and pictures of the game I'm working on, Beyond Beyaan.

I will post pictures and more details later!