Pre-Order the Game!

Desura Digital Distribution

Monday, October 31, 2011

Space-based races thoughts

I was reading some rants from a person who said that the races in 4X space games are too similar. They're all ground based, and there's no major differences aside from race attributes such as creative or repulsive. He suggested some different races, and one that struck me was space-based races. Each person is basically a sentient starship (think of crystal or space eel from MoO 1/2).

This got me to thinking, is this even possible to be implemented in my game? I thought about it a bit, and realized that due to my emphasis on macro-management, it is indeed possible! However, this is just speculation, and I don't know if I will actually add it. But if enough people request it, then I will look into it.

I would need to add the ability to generate commerce, research, and construction from ships through add-ons. The ships are maintained through commerce (commerce are a food source for those races, such as gems and rare metals), and they can "genetically modify" new ships (ship design). This would require racial technologies, which are already implemented in my game.

However, what's to prevent them from hiding in a corner and just keep on building ships that generates outputs? So one requirement could be to have them be adjacent to a star system with unoccupied planets. Their output can depend on the best bonus in that system (if there's a planet with bonus to construction, the ships would use that planet). This whole process would be abstracted away. If no income is being generated, the ships will starve and you'll be forced to cannibalize some of them to feed others.

Spying and ground invasions won't work against those races for obvious reasons (technologies are race specific, and are locked in their memories, and they don't have planets to own)

Gifting planets/ships to them will work, and will grant them access to ground invasions and the ability to capture technologies through that method. However, the technologies may or may not be useless compared to their racial technologies. But it can provide a stable source of income for the space races. But they can't produce the ships other than their own designs, so they won't suddenly build normal starships from nowhere.

What do you guys think about space-based lifeforms in this game? It's very possible to implement it, but I would need to tweak the ship code to support special modules and have the ships be able to generate output.

Saturday, October 29, 2011

More work on galaxy screen

I said that I'm working on finalizing the galaxy screen. Well, here's one more thing that I just finished!



And they twinkle as well! It was tricky getting them to scroll properly. Most games just cheat in this area, if a star falls off screen, warp it around. But in this game, if you click on a location, and the stars just randomly move around, it'll disorient you. So every background star has an actual coordinate that is converted based on it's "layer" when it's drawn. The result is a consistent starfield that don't change no matter where you're looking in the galaxy.

There's still some tweaks to be done (maybe reduce the amount of background stars?), but it's making the game feel more lively!

Friday, October 28, 2011

Finalized designs

I've spent a lot of time lately thinking about how everything should work in the game, and some design issues that I've been facing for a while. I finally finalized how things will work. I'm writing this down for two reasons; People can see what the game's end gameplay will be like, and for future reference in case I forget something.

First, let's start with waste management. This has been bothering me a lot. The problem is that when you get improved construction bonuses from technology or whatever, the waste output increases on a linear basis on how much you've allocated to construction. It's kinda like a chicken/egg situation. If you increase construction output, it should increase waste management as well. But if waste management increase forces construction decrease, the cycle starts again. While thinking about this, I hit on a simple yet elegant solution: Make the waste management handle last turn's waste output. That way, you can increase construction output a lot in one turn if you need to hurry up the production of a ship, then clean up afterwards.

Waste will be stored until they're finally disposed of. There will be a limit on how much waste can be stored before it start making people sick and die, and the more waste there are, the quicker people will die off. If everybody dies off, and there's still waste left on the planet, then the next people who settles the planet will have to clean it up. This way, I can add events for accidents that overloads the waste capacity of a planet, and technologies that increases the holding capacity.

Planets won't be terraformed through waste management output as originally mentioned. They will be terraformed through the global production screen along with other ships. Terraforming will be very expensive, and will be accomplished one stage at a time (Barren -> Arctic for example) Constructing planets from gas giants and asteroids will be accomplished in the production screen as well.

The fleet icons in galaxy screen will be reworked a bit, because right now they're confusing with three different fleet icons (system, starship, and transport) overlaying each other. It will show only one of the three icons. If all three exists, only transport icon will be shown. If starship and system ship exists, only starship icon exists. Otherwise system ship icon will be shown.

Planets screen will provide a way for you to manage more than one planets at once. Here you can specify different outputs for different types of planets, similar to MoO 3's development plans. This should reduce micromanagement a lot in large galaxies.

The last finalized design is the space combat. I've been trying to think of a fair way of doing turn-based space combat. The problem is that the first player to move has an advantage because he can kill some ships before they can even shoot back. So I discussed this with some people over in www.spacesector.com, and I've reached an decision. The space combat will be quasi-turn based combat. If you've played Frozen Synapse, you might understand the concept.

At each turn, you issue movement and firing commands. Once you've finished issuing commands, you hit "Done" and you will watch the ships move and fire at each other. Ships will fire at their designated targets as soon as they enter firing range. This will look similar to Imperium Galactica 1's space combat. Once all commands are done, the turn ends, and you're back to the command issuing stage for the next turn.

One problem with attacking star systems is the number of planets for each system. It'd be very tedious to attack one planet per turn, and this gives the defender an advantage due to the ability to call reinforcements to defend other planets. So planets and stars won't be featured in space combat. If you're invading a star system, you can't bomb or invade planets until after space combat phase. However, your troop transports will be a part of combat, and they'll be top priority for the defenders to destroy.

When the combat phase is done, you will be presented with a screen showing planets, and your firepower amount. If you have two ships equipped with a planet destroying weapon each, you can destroy two planets that turn. The amount of population that you can kill is determined by the amount of bombs you have total. For example, if you have 10 ships equipped with 2 nuclear bombs that kills 5 population per bomb, you can kill up to 100 population that turn. So if there's three planets, each with 75 population, you bomb one planet, killing all 75 population. Then you bomb the second planet down to 50.

You will be able to control how many bombs to drop, as well as how much of each transport to land per planet. You can try invading first, and if that fails, bomb the planet. Or the other way. There will be technologies that reduces the damage that bombs do.

The ultimate bomb will be the "Black Hole Generator". It targets stars, and if you decide to use it, it will annihilate the entire system, leaving a black hole. There won't be a way to turn black holes into star systems, so this is "end-all" weapon. However, everybody will hate you for using it.

One other thing that you will be able to do, if you have a fleet next to an system that isn't owned, is to destroy planets/star. The window will come up if you have the ability to do so. This can be used as an offensive or defensive measures. Offensive by preventing them from colonizing more planets since planets are destroyed. Defensive by preventing them from establishing footholds in your area if you see transports incoming escorted by armadas.

Whew, that was a lot of stuff to cover. Tonight I'm going to work more on the galaxy screen, finalizing the UI stuff!

Wednesday, October 26, 2011

Third iteration of System Window

I'm in progress of finalizing the Galaxy Screen. Last post showed a part of that goal implemented. I've decided to overhaul the system/planet UI so it's more nice and take up less of your screen. When you have a system selected, it don't have a planet selected automatically, which means more visible area. When you have a planet selected, it shows the planet's UI window below the system UI. This is what it looks like:



You may notice one big missing item. What happened to the ship selection for building ships? I realized that I can go back to my original design, so I've removed the ship selection for planets. I originally envisioned a screen where you allocate ALL of your planets' construction output to different projects such as star ships. I even had it implemented a long time ago: New Version Released

Then when I added fuel ranges (removed a while ago), I realized that it don't make sense if two systems aren't connected to each other, but still be able to supply parts to build ships. And I had a klunky solution for where ships are built. So I removed the "Empire-wide ship production" and made it per-planet. Then I later removed fuel ranges because I felt it didn't mesh well with my game design. And recently I added fleet reserves (all newly built ships go here), so no ships are actually put into galaxy unless you mobilize them. Then I realized that the whole design changes has gone a full circle, and now I can just put all the planets' construction output into one screen, and the constructed ships will go into reserves.

Funny how things turned out eh? Anyway, this UI isn't final, I need to add two buttons (Transfer Population and Mobilize Fleet), as well as redoing the "Transfer Population" window. The artwork for those are coming soon.

Saturday, October 22, 2011

Still working!

To show that I'm still working on Beyond Beyaan, here's a screenshot of the new movement indicator that I just finished:



The boxes that were used to show the fleet movement were really ugly and bothered me. So I decided to finally replace that part with the same mechanism that I will use for beams in space combat. And it's looking a lot better! I may adjust the colors later. The dark green is the current fleet's path, while the light green is the path that you're selecting for that fleet. The screenshot don't show that the path indicator is streaming towards the destination however. It's looking a lot better than the old box like this:

Thursday, October 20, 2011

More progress on Phase 2

I've implemented collision detection and texturing, along with input handling. There's a bug with textures (it only uses one for everything).

Next on list: Implement billboards (2D images that always face the camera), monsters, shooting/particles, and death.

I'm getting there...

Tuesday, October 18, 2011

Progress on Phase Two

In my previous post, I've managed to set up a 2D rendering using OpenGL, and started on a rewrite of MoO 1's program using MoO 1's existing assets. With the 2D all set up, that project is now on hold while I complete the phase two of my goal of learning OpenGL.

I do have some good news, I've managed to set up a 3D rendering, and simple blocks/ceiling/floor similar to Wolfstein 3D. This is what it looks like currently:


There's no texturing yet. I plan to implement a simple maze generation algorithm, so each level will be randomly generated. Then I will add some simple 2D billboard monsters that you need to fight, as well as shooting projectiles and killing them. I did say that it will be very very simple FPS game :) When that's done, I will return to Beyond Beyaan. I'm glad that the delay isn't as long as I'd feared it'd be.

Monday, October 10, 2011

Phase One completed

I've started the reMoO project using OpenTK (a OpenGL wrapper for C#), and it handles input and file loading. Right now, it shows the intro video, and if you click, or wait til it's done, puts you into the beginning of the main menu (just a ship with whirling background). No sounds though, because I'm deaf :)

This is sufficient for me to start on the next step, creating a simple 3D shooter. Once that's done, I will be back working on Beyond Beyaan and reMoO.

This is a screenshot showing the comparison between my reMoO (bottom left) and DOSBox (top right):

Saturday, October 8, 2011

Good news and bad news

First, let's start with the good news! I've implemented finances, and turn counter, into the game. On bottom left you will see your reserves amount, plus your income (or deficit). Bottom right you'll see the turn counter. If your income is low enough for you to go into negative reserves, you won't be able to end your turn until you've balanced your budgets. Here's a screenshot:



Now for the bad news. At work, they've asked me to set some personal goals for myself. I decided on learning OpenGL. This was a few months ago, and I haven't started on that goal yet due to this game. But while browsing the Realms Beyond forums, I saw that some people are working on a re-write of Master of Magic. That re-write, named reMoM, uses OpenGL in my favorite language, C#. So it got me thinking, what if I do a re-write of Master of Orion, it'll help me accomplish my goal, and still work on something that I'd enjoy.

So this is my plans:
Put Beyond Beyaan on hold until I've accomplished my goal.
Develop a framework for reMoO that loads in LBX files, initializes OpenGL, and handles input.
Put reMoO on hold, develop a very very simple 3D shooter similar to Wolfstein3D, just enough to learn the 3D aspects.

At this point, my goal is now accomplished, so I will then go back to developing both Beyond Beyaan and reMoO. This will let me work on one project if I'm frustrated with one problem in another. I hope to finish my goal within a month.

Saturday, October 1, 2011

Modding Now Officially Supported!

I've finished the last details and separation of global vs local images for being able to load in your custom game data, and added the drop-down in main menu. So modding is now officially fully supported!

How it works is that you select a data folder to load when starting the game, then pick one of the three options: New Game, Continue, or Load Game. All three will use the picked data folder. Save games will be created in the mod directory, separate from other data folders. This will avoid you trying to remember which save games is for which mod, and avoid data corruption. For example, if you load a game that contains a race that the current data directory don't have, it'd cause problems.

Here's the screenshot!

Galaxy Setup Screen

Another screen that I've mostly finished, the galaxy/game setup screen. Top part is for the galaxy stuff, and bottom part is for game setup.

I know, it's not anything new, just a re-worked screen. But it makes the game feel more polished and done. Here's the screenshot:



Next up is re-doing the in-game galaxy screen. I plan on replacing the movement indicator with lines instead of "boxes", re-do the planet and fleet sub screens, and add turn indicator and empire finances summary. Also implement the reserves idea.