Pre-Order the Game!

Desura Digital Distribution

Monday, December 16, 2013

Ship Design

I've implemented the ship design screen and a placeholder for the screen where you view/scrap ship designs.  The latter is a placeholder because I just wanted to get it all working.  UI re-design will come later.  However, there's some bugs and missed functionality, such as graying out other colony base specials if you already have a colony base special for example, that I need to resolve before this is 100% done.

Here's the screenshots!

The ship design screen (note that the smaller ship sizes aren't grayed out, but the missiles' 2 vs 5 shot handling are implemented):


The ship specs window where you view ship designs' specs, and the option for scrapping those designs (Just a placeholder, no ship sprites and ugly UI design):


Wednesday, November 27, 2013

Getting there...

More work on Ship Design screen.  Almost done with weapon and special selection.  There's some special handling of Missiles that needs to be added (2 vs 5 shots), and some event handling of button clicking, then it's on to displaying and scrapping ships when 6 designs exists:


Monday, November 25, 2013

Equipment Selection

I apologize again for the lack of updates in a while.  My work has been busy with getting our next big patch ready, it has sapped my motivation for coding.  So when I get home, I had no desire to touch coding, but rather, playing Minecraft to relieve stress.

But now, things are winding down, and I'm getting back on track with development.  I've implemented most of the equipment selection functionality and UI.  Right now you can select anything except for weapons and specials.  After weapons and specials are done, I will need to implement design confirmation and UI handling when you already have 6 existing designs, then the ship design feature is done!  Here's a screenshot of the equipment selection in action (cost is the actual cost, factoring in the number of engines required to power it):


Friday, October 18, 2013

Apologies for lack of updates

This past couple of weeks hasn't been a good couple of weeks.  My whole family got sick with various illnesses (mainly cold/sinus infections), and are now finally starting to get back to normal.  Also other things that popped up that took up my time.  Hopefully next week I'll be back on this and finish up the ship design screen!

Just letting you guys know that I'm still alive :)

Thursday, October 3, 2013

Helpful Indicators in Ship Design

Whew!  Verifying whether or not an equipment slot can be improved was a bit tricky, but it's now done!  If you recall, in MoO 1, when you fill out a ship, various fields start dimming out to indicate that you can't equip any bigger/better equipment.  I imitated that behavior, which was more work than I'd thought it'd be.  One thing to note, dimming doesn't mean you can't click on it, just that you can only equip smaller equipment.  Here's what it looks like now with the same Scout design as last post:


Tuesday, October 1, 2013

Ship Design

Unlike my government, I got some work done today.  I've finished the layout and look of the ship design screen.  Cramming all that information and UI components wasn't easy, but it's done for now!  It's open to adjustments in future, but for now I just want a functioning ship design screen.  I need to hook up mouse events and displaying lists of equipment to choose from, as well as few other things that I need to polish up, then it'll be fully functional.  Here's what the scout design looks like, note the info on space/cost usage per power in engine area, which I think is very vital information when considering various equipment to add:


Thursday, September 26, 2013

Preview...

This is a preview of the screen that I'm working on.  Guess which one it is :)  Yes, everything related to technologies has been implemented for ship design purposes (power, space, cost, etc, along with miniaturization based on tech level, and you can research new technologies, as well as using the "secondary item" of a technology, like Ion vs Heavy Ion Cannons).  So only things left for technologies are space combat handling, colony improvement functionality, and "advanced tech" that just raises the tech level of that field.  Technologies affecting colonies (more factories, stargates, missile bases, etc) will wait until I do the planet list screen.


I got a question for MoO 1 pros:

Does miniaturization affects a ship's maintenance?  I mean, if I research something that makes something cheaper on a ship, does the ship update its cost which affects its maintenance?  I'm assuming no due to the Scout/Colony Ship cost bug (you design Scout 2 or Colony 2 with the same design as Scout 1 or Colony 1, but it's cheaper because the original was created with tech level set at 0).  Right now, Beyond Beyaan handles maintenance with miniaturization implemented, so maintenance gets lower over time with the same ships, but I can change that to match MoO 1 if this is not the case.  Or do you guys think I should keep the miniaturization updating of maintenance?

Saturday, September 21, 2013

Preview of Morions!

The artist said Morions artwork is almost done, and gave me some preview art.  You can see the portrait and one of their ships below.  When Morions are done, that leaves only one more race artwork before I have 10 races, enough for Master of Orion 1 gameplay :)  Things are looking good for a beta this winter!


Friday, September 20, 2013

Preview of research screen

A friendly reminder, for those who want to buy five sci-fi games in a bundle for $7, which includes Beyond Beyaan, there's only two days left to buy the bundle!

I'm working on the research screen where you set the percentage of research points going into each field, and to view researched technologies.  I've finished adding the UI components, soon I'll hook up the mouse event handling.  There's some bugs/formatting to fix as well (it don't have the correct research cost displayed for example)  But in the meanwhile, I welcome your feedback!

(Note, when researching an item that has the research cost met or exceeded, it will display the percent chance of discovering the item on right of the research invested display)


Monday, September 16, 2013

Font, Color, and Size Vote

First, thanks to XenoBrain for the blank main menu button artwork!  I decided to experiment with font, color, and sizing with this.  I just learned that the 2D engine that I'm using supports font shadowing!  So with this, it's a lot more readable.  However, I'm undecided on the color, which of the three do you like the best?  I'm leaning towards Gold as it's most readable.  If you have any other color combination suggestion (font and shadow colors), let me know!



The MoO 1-esque font that I bought also came bundled with three other fonts.  Basically narrow and wide versions of two different fonts.  I didn't realize this, since the font that I tried only came with one ttf file, and when I purchased it, I set the font data to that font.  But looking at the other fonts, I realized that they're more readable than the one that I was using.  I'm thinking of changing to the wide version of the font I was using (JLSSpaceGothicC), but if you guys prefer the other font, let me know (also, narrow or wide version that you like better).  Changing this will require some re-sizing of some UI controls as the font will extend past them in some places.  I'd like to change once and fix some UI sizes, then forget about fonts until I implement the UI layout code.


Edit: Thanks for your responses!  I've decided on Wide Space Gothic font, and discovered that at size 11, it's about the same length as the narrow one at 12, but is more readable (i.e. the exclamation mark don't look like a bar).  Here's what it looks like:


Friday, September 13, 2013

v0.5 is now live on Desura!

That was quick, approved hours after I uploaded it last night.  You all can now grab it and try it out!

Thursday, September 12, 2013

Ships and v0.5

I've added the ship production as well as corrected a few bugs related to it.  You can now build more scouts or colony ships.  To change the ship that you want to build, just click on the construction box in the planet UI and it'll change to the next design in the list.  In the future, I plan on adding UI for selecting a ship from list, instead of looping through each ship design.

With this, I was able to colonize more planets, send population to them, and basically start feeling like a 4X game :)  Tonight I'm uploading the new version, 0.5, so hopefully you all will have the new version from Desura within a few days.


Wednesday, September 11, 2013

Loading and Roadmap

Whew!  The loading of saved games are now done!  In the course of working on this, I've discovered a few bugs and crashes unrelated to loading, and fixed them as well.  So the game is now better as a result.  I've also finally gotten rid of the DrawingManagement and its clunky drawing (the new SpriteManager is noticeably faster, so I've been changing over to it).  Also I got rid of unused and old graphics, leaving only the actual sprites that I will use in the game.

I've also bumped the game's version up to 0.5 due to the Save/Load being implemented.  But I'd like to do one more thing before I update the Desura's version, and that is the construction of new ships.  There's still no design screen, but the ship designs are there, so for now, the idea is that you'll be able to build more scouts or colony ships.

After the Desura version is updated, I will work on version 0.6.  The version 0.6's roadmap, or the "Empire Management" that I hope to have done within a month or less:

Implement Planets screen (list of planets that you've explored or colonized, as well as ability to boost production by transferring credits to a planet, and setting tax revenues, mostly UI stuff, with some features that needs to be added)

Implement Fleets screen (List of fleets that you have, with the option of scrapping a group of ships inside a fleet, or scrapping a ship design entirely, mostly UI stuff, with some minor feature additions)

Implement Research screen (Ability to set percentage of research in each field, as well as displaying researched technologies, purely UI stuff)

Implement Ship Design screen (The ship design code is already there, just need UI to create new ship designs, with a few features that needs to be implemented, such as normal or heavy version of weapons, single or double hulled armor, etc)

Implement the "Map" screen equivalent (instead of a separate map screen, you can zoom out/in and press appropriate keys to toggle displays of information, Fuel Ranges is one example already implemented.  Need to add "Environment" and "Territory" displays)

Tuesday, September 3, 2013

Loading and MoO 2 races

I'm still working on the loading part, it's not as easy as saving out data :)  I haven't had much time lately due to stress from work (got some critical issues to resolve) and holiday weekend.  But it's getting there, I promise!

As for the post's title, let's talk about MoO 2's new races.  Since the kickstarter campaign raised sufficient funds to fund 3 additional races, these will obviously be equivalent of MoO 2's new races when I implement MoO 2's features.  However, the question is, what if I want to play MoO 1's ruleset instead of MoO 2?  How will the 3 new races fit in?

I've posed the question over at realmsbeyond.net's forums and after a brief discussion there with Refsteel there, I think I may have a good idea for the new races:

Triliarians - Their racial perk is that they have +25% max population on planets that they inhabit.  Coupled with good planetology field perk, this gives them two advantages: More troops to defend/attack, and more production, slightly out-edging klackons and meklars in end-game.  However, longer time to build factories and to grow population offsets this advantage.

Gnolams (Pudelhunds is the equivalent race) - This one is a bit more challenging because economics work very differently from MoO 2 than in MoO 1.  So here's my proposition:  Have their racial perk be that they invest 25% less into doubling a planet's production (75 BC for 100 extra PP on a 100 PP planet), and they only suffer 25% corruption when investing into industry/taxing.  So you better ensure that they never colonize a rich/ultra rich planet.  The obvious benefit is easier overdriving of production, but there's also the ability to raise funds to give as tribute to other races to improve relations.

Elerians - Again, a bit of challenge.  Telepathy as it works in MoO 2 would be too overpowered for MoO 1.  Imagine being able to take over a 300-pop Orion just by having ships in orbit?  So we need a different approach that is keeping the theme.  So for Elerians, I'd say their perks are having the whole map visible to them from the start (removing the need for space scanner technologies), and having a +2 fuel range bonus (maybe +1 if 2 prove to be too powerful) due to their knowledge of obstacles and such.  This would be very advantageous in beginning, but towards the end-game, their bonuses are not as powerful.  Or perhaps +1 fuel range bonus, with an increased chance of capturing technologies when invading a planet (mind reading and all that)?  Coupled with "Good" in Propulsion technology field.

As for the MoO 1's "weak" races, here's what I'm proposing to help them balance against other races, especially with new races:

Mrrshans - The worst race: Their main issue is blood feuds with other races, which makes them waste production on fleets and invasions, this is aggravated by the AI's default warlike personality. What if we reduce their relationship penalties, and boost their computer field by one level (for targeting computer technologies that couple with their racial advantage)? Maybe reduce the chance of having the warlike personality for AI?

Darloks - Their computers are Good, why not Excellent? They should be the master spies after all. This should be enough to give them a boost

Bulrathis - Since AI send massive fleets of transports in hopes that some will make it, maybe just adding this one feature will make them more balanced? Add 25% chance of successfully landing troops, and when the troop landing tech is researched, increases to 75%? So less troops are wasted, and they have a chance of taking over planets?

What are your thoughts on those ideas?  Overpowered or underpowered?  Don't forget that we can tweak the races' technology fields' affinity to help balance things out.

Tuesday, August 27, 2013

Saving

The research prompt is done, you can now research technologies.  I decided to bite the bullet and forge ahead on saving/loading games since most of the underlying data structure is already in place.  The saving mechanism is now done.  Next is the loading of games.

One thing that's neat about this system is that the save games are saved inside the dataset that you are using, which are copied over to your local application folder.  What this means is that if you launch a mod, its save games will be separate from other mods.  No worries or trying to remember which save works with which mods.

Here's a screenshot of the semi-final saving and in-game menu (I need to get a generic OK/Cancel button artworks, will commission that soon...):


Tuesday, August 20, 2013

Preview of Research Prompt

This is the UI that you see when you get a tech breakthrough, as well as selecting items to research.  I've combined the two separate screen from MoO 1 into one UI (The new tech, and the tech selection).  On top is the newly discovered tech, with its accompanying icon (for now, the ? is a place holder until artist creates the icon artwork).  If researching your first item, then it shows the field's description to help introduce new players to that field.

On bottom is list of available topics to research, and if you hover over it, it shows a description of that technology.


It's not quite done yet, still have under the hood code to finish...

Technologies

Just a quick update on the code backend.  I've added all the technologies and their correct values to the game.  I also matched Master of Orion 1's random technology selection rules, so the list of available technologies should be familiar.

I'm currently working on adding UI for selecting technologies to research, as well as displaying newly researched technologies.  Then the "technology screen" that you can look at for viewing researched technologies.  Should be done soon...

Thursday, August 15, 2013

Newscaster!

The artist have finished the artwork for the newscaster, and the first icon (the news item that you see in top right corner).  I was very pleased with how it looks, so I gave the artist the go-ahead for rest of the icons (21 more icons, all matching MoO 1's 22 news items).  I was also provided with an animated gif to see how it looks in practice (The speaker part won't be as regular in-game, but it gives you an idea of what it looks like)


There's no text on the icon, unlike MoO 1.  This is so that I can add text programmatically, and it can be translated into different languages without having to alter the artwork.

Friday, August 9, 2013

IndieBundle and Lowered Price

Indiebundle.org contacted me and offered to have my game as part of their sci-fi bundle.  We worked out the details, and it's up on their site now!  http://indiebundle.org/scifi-bundle/  There's four other games in the bundle, but Beyond Beyaan and one other game is in "Plus" bundle, which means you need to pay $7 to get the two extra games.  Otherwise it's $5.

I've also lowered the Desura price for my game to $5.99 to compete against certain digital releases of similar games.

Thanks for all of your support!

Thursday, August 8, 2013

Demand for Linux version

During the development of Beyond Beyaan, I've been asked many times if I have plans to port the game over to Linux.  So here's my official announcement regarding Linux version.

Yes, I will develop a Linux version.  However, since it uses an different environment, and don't support DirectX, hence SlimDX which my game's 2D engine relies on, I will have to change to another 2D engine that runs inside Linux AND Windows.  Since this is a drastic change, I will wait until the game enters beta, then branch off and work on a Linux compatible version.

Now, when will the game enter beta?  It will enter beta when all the gameplay features and UI are implemented, similar to Master of Orion 1.  AI won't be tuned or balanced, those will be done during the beta phase.

Here's the remaining major features/UI that need to be implemented before the game enters beta for clarification:
Saving/Loading games
Ground Combat (Transports are working already, just need to add this)
Researching Technologies (The technologies are already in the game, just need UI and logic for researching them)
Fleet Management Screen (Code already stores all fleets, just need UI)
Planet Management Screen (Code already stores all planets, just need UI)
Diplomacy Screen
Spying
Diplomacy relations code (such as no combat if you arrive at an allied player's planet, penalties for attacking a colony, meeting a new race, etc)
Ship Design (The technologies and underlying code already support ship designs, you can see scouts and colony ship as evidence of this, so only UI is left to actually add new designs)
Finish the planet code (Such as refitting factories, building ships, missile bases, etc)
Start on some rudimentary AI code
Victory/Loss checks

Here's what will be implemented after beta starts, not in any particular order:
Random events
Newscaster (BNN)
More work on AI
Linux version
Bug fixing/polishing

After those are done, the game will become a full version.  Only at this point will I start adding modding support (replacing hard-coded values with data-driven values, like technologies, scripts, etc)

Hopefully around winter, the game will enter Beta.

Monday, August 5, 2013

Transports and new video

I've implemented transports, so you can interact with them, send them off to another system, etc.  The only thing that I haven't added yet is ground combat.  But the good news is that I've uploaded a new version to Desura, finally!  Both Demo and Alpha branches are updated (Alpha is the full version).  Yes, the 4 new races artwork is included in the alpha branch!  It's waiting for approval right now.

I also created a new video showcasing the features that I added ever since I reverted to an old version.  You can see fuel ranges, transports, colonization, etc. Hope you all enjoy it!  Again, no sound, due to me being deaf, but I will hire a sound programmer at one point...




Saturday, August 3, 2013

Colonization

I've implemented colonization UI.  The code behind the UI supports multiple planets/ships, but the UI as of now only have up to 4 different colony ship designs and one planet.  When I add multiple planets, it'd be just a matter of updating UI to work with the already existing planets code.

Now for screenshots!

The ui for prompting player if they want to colonize:


And yes, landing animation!  Basically just the ship coming down, but at least it's something!  You get to preview the ground view that will also be used in ground combat.  This one is Jungle planet.


I've also started work on actual transporting of people, it's mostly implemented, except that when the new fleet is created, it don't go anywhere...  Once I fix that, I'll add ground combat.  Hopefully in a day or two...

Friday, August 2, 2013

Exploration Notification!

I've started working on the "Processing Screen" part of the game, and added comments on where various steps in processing should go.  This will be almost identical to the MoO 1's process (the order it resolves different items).  Then one of the first things that I added is the "Explored System" notification.  Here's a screenshot of it in action:


Next up is the Colonization prompt, and the actual colonization process with accompanying landing animation.  I'm trying to get this game as much playable as possible soon, because there's something big related to this game coming up next week.  More news on that soon!  It means soon I'll upload a new version to Desura, both Demo and Full, and the Full will finally contain all the new race artwork!

Thursday, August 1, 2013

New Game and Race Selection

Whew!  I replaced the old "New Game" screen with its old ugly UI with the following UI.  The icons with question mark are random races.  Let me know what you think of it!  Suggestions are welcome!  Oh, I also branched off the galaxy generation code into a background worker, so galaxy generation no longer freezes up the UI.



Friday, July 26, 2013

Fleet UI

I've replaced the old fleet UI (the ugly blue box with no art whatsoever) with this new spiffy UI!

What it features:
Clicking on a point in the galaxy will grab all fleets that is overlapping that point (even if they're not on top of each other exactly).  No more frustrating careful clicking to get to that fleet that you want when two or more fleets are overlapping.  It lists fleets on top of the UI.

Hovering above a ship's box in list of ships will display that ship's sprite for easy visual reference.  I chose this approach because otherwise I'd have to allocate 160x160 pixels for each row, lots of empty space.

When you issue an order, it will split out that fleet, then automatically select rest of the idling ships.  So you don't need to click on the idling ships again (such as sending out scouts in beginning of game).  Selecting fleets now feels more intuitive and is robust.

Under the hood improvements and cleanup.  Oh, I forgot to mention that both System View and Fleet View windows are movable, so you can drag them around if they're blocking your view (I show this in right part of the below screenshot).

Now for the screenshot!


Thursday, July 25, 2013

Ship relocating UI done!

I've finished the validation stuff for both ship relocating and population transferring.  I also implemented the UI for ship relocating.  For the screenshot, I temporarily disabled the validation stuff, aside from fuel range restriction.  Green line is population transfer, blue line is ship relocation:


I'm putting the planet UI on hold now, since it's functional (can build buildings, can generate research points, can set relocation/population transfer).  Next up on agenda is re-doing the fleet UI and adding space/cost/power values to technologies so that eventually I'll be able to re-do the ship design UI.  After those two, colonization and the accompanying UI.

The pieces are starting to fall into place, and the game will soon be playable again!

Wednesday, July 24, 2013

Population Transfer

The UI for population transfer, as well as path display for it are done.  There's some validation stuff that I need to add (checking to ensure that the system is explored and colonized), as well as end-turn processing that generates the actual transports and subtracts population, but most of the hard work is done.  I'll let the screenshots speak for themselves.  Note in the screenshot, I added a selection border around selected system, tooltip when hovering above button, two buttons under the planet ui's sliders (relocate and transfer), and green path for current transfer plus amount of people transferring in bottom left of UI.  It's ironic that the system's random name is "Lies", this is all truth, I insist!


As always, I welcome your feedback!

Monday, July 22, 2013

Demo Races uploaded, and race tidbits

I created a demo version for each race that the artist completed (Nurds, Araneas, Velociraptors, and Pyrrhans), and uploaded it to the repository.  Each have a simple triangle ship artwork for each of the ship design, as well as stick figures/houses for ground combat.  The main portrait is the same as normal version, but the happy/angry expressions re-uses the main portrait, with "Angry Expression!" and "Happy Expression!".  This is to enable me adding all races in the game without using the paid version of assets.

So there's only two more races left that are still missing their artwork before I have a full set of races for MoO 1-esque gameplay (Don't worry, the other three races will come in later for MoO 2-esque gameplay, when the artist finishes those).  Currently the artist is working on the "BNN" artwork (Think GNN, but Beyaan News Network instead) and the associated event images.

Since obviously Beyond Beyaan's races are different from MoO 1, here's the list of which race replaces which race, inheriting that race's bonuses/penalties:

Humans - Humans (Duh)
Nurds - Psilons (both nerd races)
Pyrrhans - Alkari (Since both are birds)
Salix Cybornia - Klackons (Since tree cyborgs are half-machine, they're more productive per pop than regular)
Zero People - Meklars (Computer, control more buildings)
Velociraptors - Bulrathis (Good at ground combat)
Space Hamsters - Mrrshans (Good at attacking)
Araneas - Sakkras (Ever see a mother spider with baby spiders on its back? eww, they sure reproduce a lot)
Morions - Silicoids (Both types of rocks)
Zygobies - Darloks (Since Zygobies takes over hosts' body, it also takes over their mind, therefore good at spying)

Later, when I start work on adding MoO 2 features, those races will take over the MoO 2's races:
Pudelhunds - Gnolams
New race (Unannounced yet) - Trilarians
Kickstarter-backed race (still haven't finalized details) - Elerians

As for code-wise progress, right now, I'm adding population transfers and relocating new ships features.

Wednesday, July 17, 2013

Fuel Ranges

I investigated MoO 1, and measured its parsecs in pixels (if you turn the grid, lines are spaced 5 parsecs apart.  DOSBox upscales the screen from 320x240 to 640x480).  I found that 5 parsecs equals 100 pixels, so 1 parsec = 20 pixels.  I then measured the star sprite, it's 11 pixels.  I then compared my star's sprite, which is 32.  Almost exactly 3 times bigger, so I've set my game's 1 parsec to be equal to 60 pixels.

Then I implemented fuel ranges, mostly.  There's some bugs and some polishing-up that I need to do before it's complete.  While implementing this, I thought, it's kinda annoying having to click on a star with your scout, and see if it's within range.  If not, click on another star, and so forth.

So I decided to add a visual layout of your fuel range.  This can be toggled on/off by pressing the "F" key (I will later add radar range layout when I get to radar code).  You can see two circles in the below screenshot, the normal range and range with extended fuel tanks.  On left, the destination is within range, while on right, due to colony ship having no extended fuel range, the destination is out of range.  What do you think?  Something that you'd use?


Monday, July 15, 2013

Technologies

While working on the planet UI, I studied on how missile bases work (how much they cost, etc), and realized that in order to get this UI correctly working, I'll need to implement technologies first.  Missile base's cost and maintanence relies on which shield, missile, armor, etc that you have, plus any minitaurization.

So I'm in progress of implementing technologies now.  I've committed some large changes, which breaks the build.  There's still a lot to be done, but for those who's interested, I've implemented how MoO 1 researches new technologies (investment, interest, and chance of discovering the tech).  So if you want to see how it's done, check out my changes.

Hopefully within the week, I'll have a working technology system, then I'll finish up the planet UI.  After that, it's ship designing and ship construction, plus colonizing new planets.

Thursday, July 11, 2013

Artifacts Found!

Over on Realmsbeyond.net forums, someone sacrificed their Master of Orion strategy guide and scanned it into a PDF.  I obtained a copy from him, and looked through it.  O____O!

It might be a design document for the game for all the details it contains!  400 pages of goodies, including how races' home systems are set up, rules for random planet generation, many formulas for how things works, and even how the AI battles in tactical combat, as well as how they decide which system to attack.  In the guide, they said they pored through the source code, and the guide is based on version 1.3, which explains their in-depth knowledge of the game.  This is a huge boon!  I've added the PDF to my project SVN, so go ahead and check it out!  I'm not sure about legality of this, but since it's not in print anymore, and to re-print it wouldn't be profitable, I think it should be fine.  If you or you know someone that objects, let me know, and I'll remove it.

I learned something new from the guide, when you're in main menu, press and hold ALT, and type "TUTOR", it'll start a pre-set game in simple difficulty!  I never knew it had this!  The guide then tells you what to do turn by turn.  So, pretty amazing stuff!

Tuesday, July 9, 2013

Planet Production getting there

I think I've finalized the look of the planet UI.  I also implemented part of the planet's production stuff, specifically the "buildings" (they're factories in MoO 1, renamed to "Buildings).  Here you can see that I'm building them, on left I haven't reached the max amount of buildings yet.  In middle, it will reach the max, and will generate BC from the excess production.  On right, it've built the max amount of buildings, so all production is generating BCs.

I think that this is a bit more clear than MoO 1's "RESERVE" which don't tell you how much is being added to your reserves.  Later when I add advanced controls technologies, I will show "Upgrading (XX%)" when refitting older buildings.  Not sure how I should handle the "MAX" when you're building more than you have the population to operate them.  Speaking of which, does those factories still produce pollution even if there's nobody to operate them?  How does refit work exactly?  The manual said it's the difference in cost between two levels of technologies, but that's not very clear...

Still got some work to do before this UI is done, but this is one of the most important UI in the whole game :)  What do you think of it?  Is it clear (Click the image to expand)?  I found the awesome font that feels very similar to MoO 1's font (for reference, I added a screenshot, look at top two lines and see the font I'm talking about), I hope it is legible :)



Sunday, July 7, 2013

Pyrrhans race, Demo approach, and MoO 1 mechanisms

I would like some feedback on an approach for the demo version that I'm considering.  Since the game is open-source, the only way I can make a demo version is by including only the demo assets.  However, since some racial attributes will be hard-coded at this point, I will need to include races.  So here's what I'm proposing:  I will include each race's neutral portrait, and add a sign on bottom that says happy or angry for those two extra expression portraits.  For ships, ground troops and other artwork, I will draw triangles (think old asteroids triangle ship), stick figures and other simple artwork.  So those races will be in the game, and will be added to the repository, but in order to enjoy the "Full" experience, you'll need to buy the game which will give you the full artwork.  What do you think of this approach?

The artist just finished with the Pyrrhans race, so I'll show what I mean using their portrait as an example (Also showing one of their ships which are pretty cool):

Yeah, that's newspaper on the floor.  Despite their advanced technology and cool ship designs, they can't figure out how to get their bowels under control. :)

Now for the last part, here's what I've uncovered with Master of Orion and how it plays that most people may not have known, and some questions for those who may know the finer details:

1. Remember that when you research a new item, older items reduces their space and cost usage?  I thought that was why the colony special could fit on a medium ship later in game.  But what I didn't realize is that ship space also increases based on construction tech level!  In the manual, it says that ship space increases by 1% per construction level.  When I checked this in-game, it was actually 2% (manual was based on version 1.2, it may have changed in 1.3 or later).  So what this means is that at level 100, the ship space has tripled.

2. I thought that when you select an engine for a ship design, its size would be constant.  I was wrong.  Anything that uses power increases the number of engines required.  This explains why when adding a shield that has 5 space in small ship, it actually uses up 10 space.  The extra 5 space was from engines being added to power the shield.  Now, does anyone have an exact formula for number of engines required?  Does higher level engines have the same number of engines for the same level of power?  How much power does the base empty ship hulls require?


Friday, July 5, 2013

More work on planet UI

Things are starting to fall into place for the planet UI window!  I'm still working on it, but I think I've got the final layout for it!  The UI isn't fully working, but most of it is there.  I plan to add lock button on right of each slider, then flesh out the code behind the UI so that it interacts with the planet data object.  A preview, what do you think?


While we're on the topic of planet management, there's a few things that I need some clarifying on (I tried looking them up, but got general concepts on how they work, not the actual formulas) (Note also that one unit of production on a planet is equivalent to 1 BC):

I looked at how production is calculated in MoO 1.  What I don't get is the extra 1.  The idea is that at level 1 tech, each population produces 0.5 BC (aside from klackons, which doubles population's production), and each factory produces 1 BC.  So starting with 50 pop on normal difficutly, and 30 factories, it should be 55 production.  However, when I looked at MoO 1, it starts with 56?  Where's the extra 1 coming from?

How exactly does reserves work?  I know that if you put 100 production into reserves, it stores 50 BC.  But what happens to production when you put money into a planet (I know it boosts production, but I need to know the exact formula)?

How much pollution does a factory produce?  1 BC? Does it cost 0.5 BC to clean up 1 BC pollution as per a guide I found?  So if I have a tech that reduces a factory's pollution to 80%, it means that it's now 0.8 BC of pollution per factory, and therefore costs 0.4 BC to clean up?

Friday, June 28, 2013

Start of Planet UI and Renaming

I've started on the new UI for colony management.  It will eventually match MoO 1's functionality, with a couple of differences:

1. The item being worked on in each field will be a button that when clicked, brings up a new window displaying possible options.  This is especially handy when you want to build missile bases instead of that expensive planetary shield that takes forever to build, when enemies are approaching your planet.

2. You can rename a colony by clicking on its name in the text field, and just type in a new name.

Here's a screenshot of what I have so far.  Note that the design is not final, I'm just throwing in all the UI elements that will eventually be there, then I'll start moving them around until it all looks good.  Note the new font in star's name, and that I've explored some systems around me:


And here I've renamed my starting system to "Mah Homewarld"

Saturday, June 22, 2013

Fleet movement working!

I had some extra free time, so I finished up the fleet movement and selection of destinations, as well as displaying current path of the selected fleet.  Fleets now move to their destination, and after arriving, if it's not explored, it is now explored.  So, yeah, the gameplay part is getting there :)

On a side note, have you ever experienced this when you don't have hyperspace communications:

"Hey, I'll send some of my warships to this system to protect it."
A turn later, you see the enemy sending ships to another system
"Oh snap! I want to tell my warships to go to that system after they've arrived at current destination to save a turn!  But I can't!  I have to wait until they arrives before I can issue orders."
If you were able to tell them to move on, they might have arrived in time, but no, your colony gets destroyed because your fleet arrives one turn too late.

So I've added the ability to tell your fleets to keep on moving if you want them to go to a new destination right after arriving at their current destination, as shown in the screenshot:


In this case, the fleet has already left Scietn (Yeah, a random name) heading for the orange star.  I want it to move to the rightmost star immediately after arriving, and made an order to do so.

Now this raises a few balance issues, I'm going to address the ones that I know of:

If the original system is unexplored, I'm going to say to leave it unexplored because your fleet didn't actually stop for a full turn there.
If the original system has enemy fleet, your fleet stops and engages in combat as normal.

Any other situations that I missed that might not be balanced with this change?  I can add an option to enforce "No Secondary Destination" or something like that to match MoO 1's gameplay.  What do you think?

Fleets Updated

I've overhauled the fleet's movement system so that it uses the new free-moving system.  Fleets adjacent to a star system will sit on either side, depending on if it's departing or just chilling, similar to MoO 1.

I also updated the races to use the new SpriteManager instead of DrawingManagement (SpriteManager is faster and more efficient).  So each race now have their own fleet icon.

While this may seem like a short blog post, in actuality it was a lot of work.  Just look at the SVN history to see how much code I changed to achieve this.  There's still things I need to do to finish this, but it's now about 80% done!

Screenshot of a fleeet adjacent to the home system (Space Hamsters' fleet icon):


Wednesday, June 19, 2013

Changing from Grid to Free Point system

In early versions of Beyond Beyaan, I went with a grid-based map where everything is in tiles.  However, in end I decided to not do it, and changed over to free points.  But now when I reverted to the old version, the grid stuff is back :(

I'm now in process of changing the game to work with free points.  I'm done with star generation and drawing, but it broke the fleets and anything related to ships.  Camera is still a bit wonky.  Hopefully I'll get it all sorted out, then I can start adding back new stuff!

Here's a screenshot of the stars on a free-point system at closest zoom using the new animated star artwork:


In other news, the Pyrrhans artwork is nearing completion, will post an update when it's done.

Saturday, June 8, 2013

Star names!

This is the best decision that I've made, making virtually everything hardcoded.  Now I don't need to worry about how to make a feature support different stuff, which reduces a lot of stress. I've started importing stuff from the old revision that are handy, such as mouse cursors, SpriteManager, etc.

Then I decided to do something new, and finally fulfill one of my promises to the kickstarters.  Star names!  Their star name submissions are now used when the galaxy is generated.  If the names run out, then it generates a random name.

Here's a screenshot - Yes, one of the stars is "Predestination".  Be sure to check their 4X game out as well!


Wednesday, June 5, 2013

Reverted to a pre-SVN version!

I tried reverting to the revision when I first committed my source code, but the build failed!  I realized that I didn't include assets until revision 4, but even then, the data didn't match the code!  Yes, I know I said I'd strip out data, but I'd like to do it step-wise.  Grounding my teeth in frustration, I cast around looking for the right data from my old backups from before when I started using SVN.  I found an oldie that contained the source code as well, it's waaaaaay back when I still used grid based movement, and when I just finished adding sliders and stuff for planet management.

So I decided to scrap my whole revision, and just copy that old version over to start off as a base.  Behold, the mash-up programmer art and the new artwork!  This is a screenshot that I just grabbed now!


I've committed this version to SVN (if you still want the moddable one that I worked on, go to the branches and download it from there).  So go ahead and check it out.  In fact, since I'm now blatantly ripping MoO 1 off, I'll keep the artist's original star system selection (shown above) since it matches the old one instead of the spinning selection!

That step done, the next thing on agenda is adding back my glorious mouse cursor!

Monday, June 3, 2013

Enough with "Beating around the Bush"

Alright, I'm gonna be open and honest here.  The main reason for me adding modding support to Beyond Beyaan was to have the ability to play it like MoO 1 without being a blatant clone, "Oh, check this awesome 4X game, but if you don't like how it plays, you can just load up a mod and play it like MoO 1!"

If you check the 0.5 version on Desura, you'll see that I actually had it almost playable, it was just lacking AI, research, and certain features to make space combat work.  But most of the stuff were there.  You can invade planets, you can colonize, you can build ships, etc...  Now look at the latest version.  What do you see?  A galaxy... That's it pretty much.  What happened?

Well, right after that 0.5 version on Desura, I decided to re-do the economy system so that it'd be moddable.  That's mistake #1.  After finishing it, I felt that it should be moddable in other ways.  That lead to a sequence of a lot of work that just aren't visible to the users.

I'm not saying this to tell you that I give up.  No, far from that.  I'm telling you why I'm changing course and doing things differently now.

Instead of pretending that I'm not copying MoO 1, I'm outright just doing it now :)

I'm creating a branch and putting the current version in that branch for reference.  Then I will clear out most everything that I have so far, and focus on getting things implemented the non-moddable way.  This means hard-coding everything, including technologies, races, AI, etc.  I will restrict myself from using data files other than graphic files and save files.  I will copy MoO 1's gameplay as a base, to avoid design decisions.  This will be a re-imagined MoO 1 in every way.

You may be thinking, that'd be a drastic change.  The truth is, most of the delays were from me figuring out how to support modding for a certain feature.  For example, star systems?  I had to write code that reads in a data file that defines star systems, and the code had to be flexible to accommodate the different star systems.  It contains a list of planets, which in turn contains the bloated economy system that can accommodate any kind of economy that you want.  When doing it the hard-coded way with MoO 1 as base, the star system will just contain 9 values: the 5 sliders, population, factories, which ship being built, and owner.

Once the game's playable and all features are implemented, then I will start swapping out hard-coded parts of the game with code that uses data files to support modding.  Then after that's done, I will finally start tweaking the game to incorporate my design ideas.  I will keep the MoO 1 gameplay as "Classic" dataset.

I realized all of this when working on the new UI system.  The whole project has gotten so bloated that I'm basically endlessly designing and tweaking and getting nowhere, and having a hard time staying motivated.  This change will give me a boost, focusing on only the essentials now.  So please bear with me...

Thursday, May 23, 2013

Avoiding Research as "Overpowered Trait"

Quick update on the development side: I'm almost done adding Sliders to the new UI system, and is currently working on having "Screen within screen", where you can refer to another screen inside a screen to reduce typing.  For example, planet information display in both selected system display and planet list display.  After those are done, I will look into coupling C# scripts with screens, so you can specify which script file works with which screen, and have them share data.  This will allow you extra features such as screen transitions, space combat, etc.  When all of those are done, the bulk of new UI system will be done, and I can finally finish the Galaxy Generation screen.

Now, for the topic -

If I were to ask you which race was the best one in Master of Orion 1 or 2 (without customization), the obvious answer is Psilons.  Why? I mean, they're nerds, don't really have any other advantages in MoO 1, and has disadvantages in MoO 2.  So how are they so powerful?  The answer is that those games emphasizes technologies.  Other aspects in empire management don't affect your empire as much as technologies do.

Here's my approaches that I feel will balance this issue without nerfing the technologies' importance.

1. Production - Whenever you build a technology item, you automatically generate a certain amount of research points in a similar technology.  For example, if you build 100 laser cannons spread across 20 ships, you obtain Gatling Laser technology.  This is similar to real life.  Often when we build stuff, we also seek methods to improve how we build the stuff, reduce costs involved with building, or improve the quality of the stuff that we build (look at our cars for example, they're continuously being improved).  But the caveat is that production won't help you in a new technology field.  So building insane amounts of laser cannons won't obtain you the plasma torpedo technology.  This is to put the production-based races on par with the research-based races while still requiring some effort to research.  The amount will be randomized, and the tech tree randomized as well, so it'll be different each game.

2. Spying - In many 4X games, spying is weak, and is mostly to annoy other races.  Not often that they dramatically alter the outcome of games, unless it's to obtain technologies.  Again, note the importance of technologies?  For Beyond Beyaan, I want spying to be something that is worthwhile, and something that you'll want to invest time in about the same with research and production.  But how to do it?  Well, I'm going to add ability to target specific technologies to try and obtain it.  So instead of random draw of luck, you first scout out what technologies they have, then set bounties on each technology that you want.  You also set security funding on individual technologies (so you can put a lock down on Death Ray technology, but ignore the obsolete +1% Terraforming).  There will be technologies that improves the efficiency of your security funding.  Same for planets, ships, etc.  You can try and blow up their Death Star with your spies, but ignore their fighters.  Or try to incite revolt on a certain productive planet to cripple their economy.  In a nutshell, you micromanage the spying and defense, making them about as equally important as production and research.

3. Diplomacy - For diplomacy, most games basically make a diplomatic-race have good relations with other races.  But what I want is a intrigue-infused political system where you can play games with other races.  Beyond Beyaan will raise events, and those events will open up conversation options with other races.  For example, if your spy blew up a missile base on a race without getting caught, you can talk about it with that race, and your options would be something like "Haha, your defense sucks" (lowers relation without arousing suspicions), "Oh, I'm sorry to hear that, here's some money to help you rebuild it" (improves relations despite it being you who blew it up in the first place!), "I think that race did it, here's some evidence!" (can either impact your relationship positively or negatively, depending on your diplomacy skill).  Also, most of the conversation options that you see will be story/lore options that has a random modifier.  For example, asking about their race's history may improve your relations, and at the same time infuse story in the game.  Or maybe asking about their opinion of your clothes will negatively impact the relations.  As you converse, options will be opened up.  So instead of immediately opening up a trade agreement like in MoO 1, you have to converse with them before that option is even opened up.  The diplomacy perk will allow you to see what an option's impact on your relation will be, otherwise you'd be guessing.  So being diplomatically inclined allows you better control in politic scheming, which can be very valuable.

4. Economy - Another aspect that's largely ignored is economy.  Most games it's just a simple "Oh I have this amount of money, I can boost production or buy/finish this ship".  Anyone played as Gnolams and used their trade to win the game?  I didn't think so.  My approach is to have economy impact your military and production.  How does it impact them?  Let's say that you're not producing enough food to feed your people.  Let's say that you're farming about 25% short of what your people need to eat.  Instead of just them dying off, their production drops by 50% (double the shortage), which in turn drops income by 50%.  Let's say you have 100 upkeep, and 100 income, dropping by 50% means that your ships and ground troops perform 50% as effective due to defective/broken parts, insufficient fuel, etc.  Your weapons will do 50% damage, armor absorbs 50% of their normal rate, and so forth.  There will be a minimum efficiency, but the idea is that having a bad economy is not a minor inconvenience.  It will IMPACT your empire and your ability to fight.  If you just lost a planet that supplies 20% of food to your 100+ planet empire, well, crap, gotta fix that or you'll suffer.  If you lost a tourist planet that supplies 30% of your income, it will hurt.  But if your economy is in excellent shape, surpassing all your population's needs, they actually get bonuses.  Let's say you have 125% of what your people need to eat.  It means they reproduce faster, work more, research more, etc.  There will also be an upper cap on bonuses.  So with this in mind, destabilizing another empire's economy is now a viable strategy.  Instead of destroying all planets, just target those planets that supply the empire with food/money, and presto! their military is weakened, ready for you to attack them!  Spies will also play a part in this.  You can offer or receive empires loans or food supplies, and you can also have the option of declaring bankruptcy if you're in red, which will impact your relationship severely but helps stabilize your economy.

Now with all of those, suddenly specializing in research isn't so overpowered because other fields are now about equally as important!

--------------------------------------------------------------------------------

Another problem that unintentionally caused research to be overpowered is the shields in MoO 1/2.  They basically cancel a part of the damage.  This can imbalance the game because weak weapons are no longer effective in later stages.  Think of a tiny ship with Shield X, and 1000 ships with basic laser that does 5 damage.  They can't kill the tiny ship because Shield X simply cancels 10 damage before starting to absorb damage.

For Beyond Beyaan, I'm doing the shields and armor a bit differently.  Both Shield and Armor will have "Resistance" threshold, with Armor averaging higher.  If resistance threshold is surpassed, the damage is passed on to next level.  However, both shield and armor have a limited amount of "HP", that if 0, they stop resisting and allows all damage through.  So a Shield I absorbs 1 damage, and have HP of 10, it means it takes 10 hits before it stops absorbing.  There's no damage canceling.  A powerful weapon can punch through both shield and armor, while a large number of weak weapons can whittle them down.  This way, you can still use weak weapons effectively (swarms of fighters for example) to attack a powerful ship.  You also can have layers of shields (three shield generators for example) to shield your ships.  The idea is to make the combat feel organic instead of a number-crunching game.  I want to avoid "Min-Maxing" where there's "The One Ship" that can handle everything.  An enemy built an ultra powerful Death Star?  Make massive number of boarding ships and attempt to take it over.  An enemy built thousands of tiny fighters?  Build ships with powerful area-of-effect weapons that easily destroys small ships, but is weak against large powerful ships.  And so forth.

Tuesday, May 7, 2013

Nurds!

My artist finished the portrait of Nurds, as well as some of the ships. (How it works is that he creates the portrait and some of the larger ships, I look at it and see if the ship style and portrait need tweaking, then he finishes the rest of the artwork).

Here's what the portrait and one of their ships look like (think retro 50's spaceships!)


Things has gotten busy recently, but hopefully in a week or so I'll be able to work on the game.

Friday, April 26, 2013

Shader and Shader Values working!

I know that this probably isn't very interesting to most people out there.  But for modders, this is important!  For stars in my game, they are colored using shaders.  While others may just create different sprites that already have colored stars, I use a greyscale star, and replace each shade of grey with the correct color using a shader.  Same for ships (replacing certain red shades with empire colors for example).  You can see in my last post that the stars drawn are grey.

So I went ahead and added support for shaders in the new UI's images.  I also added camera control to the "CameraView" UI Type that allows you to zoom in/out, and move around, and define the thickness of borders in where it start moving around.  So for now, that part of the galaxy setup screen is done!

Just one more step, that is loading in another script's UI...  Anyway, here's a screenshot of shaders and camera view in action (well, not animated, but you get the idea, it's zoomed out and I moved camera to left and down.  Note the colored stars, which proves that shaders are working correctly):


Since I'm just getting the new UI system to work, the UIType class is one huge class.  I plan on breaking it down to smaller classes after I'm done with the whole thing.  So for programmers out there, pardon my klunky code.

Oh, the "code" for this screen?

Yeah, 21 lines of goodness to generate the above screen!  Starting to see why I'm excited about this?  See how the galaxy preview part is just 5 lines, defining how each star is drawn?

Thursday, April 25, 2013

Getting there...

This new UI system is a lot of work, but in the end I feel that it will be worth it.  I've finished fleshing out the drop-down UI type, so that it properly displays and handles both dropped and non-dropped states, as well as interacting with the game when something is selected.

I'm also working on getting star systems to work with the new UI system.  I added a new UI type, "CameraView", this will be used for certain types of objects.  CameraView supports moving, zooming, etc which isn't implemented yet, but that's the idea.  It will be used for galaxy preview as well as space combat.

Here's a screenshot of current version of CameraView (note that galaxy is generated via the new UI!), no shaders, no scaling, no zooming, etc:


What this means is that you can have a galaxy preview inside a screen, maybe planet list screen to show its location, or whatever you think suits your purpose.  There's a lot of work to be done still...

Thursday, April 18, 2013

Data working!

The UI now can get its data from game code!  This is big!  This is huge!  While this feature is limited right now, I can easily expand on it in the future to add support for other features.  I was worried for a bit there on if this is even possible, but now with that out of the way, I can easily create new screens and windows a LOT faster than before.  No more worrying about handling mouse events inside a screen (lots of duplicate code there).  I just specify XML files and the game handles the rest!

Here's a screenshot of the galaxy setup screen that I'm working on.  The drop-down on top right contains the list of available scripts that the game code found in the scripts folder.  This is not hard-coded at all!  It's all loaded from a XML file!  The "Cluster Galaxy" text that you see is actually a screen inside another screen, so you can create unique UI (dropdown that contains pictures and text for example).


I plan on expanding this more!  There's two more features that I need to add to the new UI system to finish the Galaxy Setup screen:

Ability to retrieve list of star systems and display them using sprites referred inside the star system class

Ability to load UI from inside a script file (galaxy scripts allows users to specify certain parameters, such as number of arms)

Once those's done, I will chuck out the old galaxy setup.cs file!  The first feature will be the hardest, but if done, will give modders powerful ability to specify how stars are drawn.  For example, draw a name above a star, or below it? Or even on the side?  Fleet icons?  Extra fluff UI to make it look nice?  Draw small planet icons around the star to show its planets? Etc...

Wednesday, April 17, 2013

UI and Data

Building an UI system that allows you to interact with the game's core mechanisms isn't easy.  It's easy to create a system where you can place buttons and other pre-defined components if the game is looking for them (i.e. hardcoded buttons that you can only specify their location and size for example).  However, the system I'm aiming for is to allow you to control more than that.  The game isn't expecting any particular UI, it only have list of events that can be called from the UI, and a list of functions that can return data.  The tricky part is creating the connection between the UI and the Data.

I originally picked C# because I liked its layout.  Now I'm especially glad that I chose it.  The reason is that while looking for a method of getting a variable name that's hard-coded inside the program, C# have a relatively simple method of doing this!  So I've created a test function that checks to see if I can actually retrieve the values of properties that I'm looking for inside a list of returned objects, and it worked!

Edit: Arg, it ate the greater than/lesser than brackets, so replaced those with () instead (all (T) uses those brackets)


public void FillData(T)(List(T) values, GameMain gameMain) where T : class
{
foreach (T t in values)
{
string value = t.GetType().GetProperty("GalaxyScriptName", typeof (string)).GetValue(t, null).ToString();
}
}


Basically it tells the function T is a class, and contains members.  Then it loops through list of instanced classes (in this case, GalaxyScript class that only contains one string member, GalaxyScriptName) and retrieves the value of the "GalaxyScriptName" property from inside the class.

What this means is that I can return a list of ANY class (StarSystem, Planet, ShipDesign, etc), and this function will work with any of them!  So I can populate UI with data!  However, this is just 1/3 of the work (yet it's the most critical part)!

The other 2/3 is setting up a way where the game recongize that the UI wants certain data, and provides it with those data, and having the UI fill in its controls with those data.  I've already set up a way for UI to tell the game it looks for a certain data (I'm currently in process of converting GalaxySetup screen to the new UI system):

in XML file (blue text is the UI telling the game it's looking for certain data):

Edit: Same issue as above, replacing with ()'s

(UIElement name="GalaxyDropDown" UIType="DropDown" OnSelect="UpdateGalaxyScript,[GalaxyDropDown]" DataSource="GalaxyScriptList" xPos="XMIDDLE+130" yPos="YMIDDLE-275" width="250" height="35" arrowxoffset="10" arrowyoffset="10")
    (Template height="30")
      (SubElement UIType="Label" xPos="10" yPos="5" content="[GalaxyScriptName]" /)
    (/Template)
  (/UIElement)

 

When the screen is refreshed, it sees that one control has a valid "DataSource" attribute, and tells the game to go get the required data as per this function:


public void RefreshData()
{
foreach (var uiType in UITypes)
{
if (!string.IsNullOrEmpty(uiType.DataSource))
{
uiType.FillData(_gameMain.GetData(uiType.DataSource), _gameMain);
}
}
}

So the UI part in letting the game know what it needs is done.  Now for the last 1/3rd part, getting both to actually work together.

Notice the "Template" element in the XML section above?  It basically tells the game that each row inside the parent UI follows this layout.  It can define its size, the child controls, etc.  Each row correspond to each class retrieved from the DataSource.  So if there's 4 galaxy scripts, the drop-down will have 4 options, each corresponding to one script.  Each row will have a simple text as indicated in the Template element.

The Template part isn't implemented yet however.  I'm trying to think of a good way to bind the attributes of a control to a class (If you're familiar with WPF and XAML, you can get ideas of what I'm trying to do here).  Hopefully soon this part will be done as well.


Sunday, April 14, 2013

Recent Build Updated to 0.1.52

I've added event handling in the new UI system.  It's pretty basic at this point, but I hope to flesh it out in the future.  This new UI system has already gotten rid of one .cs file, namely the "MainGameMenu.cs" file!  In the future, I plan on removing the Screens directory totally from the project, and replacing them with Screens directory inside the game's data directory.

Changing screens when screen don't exist in the new UI results in this error message:


Right now, there's a command "UseOldScreenSystem" that when called, switches over to the old screen system for Galaxy Setup.  When I convert Galaxy Setup, it will change over to Players Setup, and so forth.

I've uploaded the new version to Desura's "Recent Build" (0.1.52) that includes those following items:
New screen UI system
New mouse cursor
New game launcher
Added License.txt to clarify licensing stuff

Check it out and let me know if you still have mouse issues or find any other issues.  Thanks!

Saturday, April 13, 2013

Cursor

Some people reported their mouse position being off even after my mouse update.  So I decided to hide the window cursor and have the game draw its own cursor.  This is just a quick report so you know I take your bug reports seriously.


Still figuring out how to handle events for UI, should have it set up soon!

Friday, April 12, 2013

Main Menu using the new UI system!

After much sweat and tears, I've gotten the framework of the new UI system working!  What you see below is similar to the original Main Menu, but it's now using the new UI system.  I've removed the Options and dataset drop-down because those will be handled now by the launcher.  I haven't gotten it to work with the rest of the game, so right now it's stuck on that screen alone.  Once I get this screen to work with rest of the game, I will update the Desura recent build so you guys can give it a try.

It does process mouse events, you can see the "New Game" is highlighted because I'm hovering over it.  When this is more fleshed out, this should help me progress quickly in terms of development.  To a player, the changes isn't really noticeable aside from a slight boost in FPS (it's more efficient on top of being flexible!), but to a modder, it opens up modding approaches that previously required tweaking in-game code.


Thursday, April 11, 2013

UI and Velociraptors

The launcher that I added also does one additional thing.  It scans the install directory's data folder to see if there's any datasets that needs to be copied over to local user's application data folder.  If there are any, and none of them exists already on the local folder, then copy them over.  This serves two purposes.

First, with newer OS, modifying or creating files in the install directory in Program Files directory is a big no-no (security risks and all that).  So in order to have save files work, I've opted that the entire dataset is copied over to local folder first, then the game loads from that.  Saved files will be stored there.

Second, it allows you to modify the files without needing to create a backup.  Just modify the files in the local folder, and the game will not overwrite it with its initial data because it already exists.  If you mess something up, or don't like your changes, you can just delete the local folder and the launcher will just copy over the standard data.  You can modify the game's files in the install directory if you really want to, but to revert those changes you'll need a backup, or reinstall the game.

With that in mind, I started work on having the game load the data assets using the launcher's configuration.  On completion, I realized that some of the assets it's loading from are using hardcoded paths (fonts, certain graphic files, etc), and those are used in the main game menu.  The game reported errors when trying to start :(

At this point, I have two choices: Fix the hard-coded stuff so they point to the correct places, or start work on a new UI system that loads the screens from XML files which in turn loads images and resources dynamically.  I decided to opt for the second option for several reasons.

First, what's the point of having a 4X space game engine if you can't modify where or what the UI look like?  For example, MoO 1's UI layout is vastly different from my game, or MoO 2, or other games.  If you wanted to mod MoO 1 into this game, you'd have to change the game's code to accomplish that.  With this system, it'd be now possible to create a MoO 1 mod without changing any of the game's code.

Second, it'd reduce the time spent creating screens and windows, since all I have to do is modify the XML files, and the game will automatically handle it.  I can easily add screens and windows without having to declare them in code, then handling all the events, etc.

I'm taking it slow and will have both old and new UI systems running together.  I'm about halfway done with getting the basics of the new UI up and running.  After it's working, I will re-do the game main menu so that it uses the new UI system, but when you click on "New Game", it will switch over to the old UI screens.

The game will have a list of "events" or "actions" that you can attach to an UI element, allowing you to create your own screens.  In fact, you can create as many screens as you want, and have each link to other screens by "ChangeTo ScreenB" commands.  There will be some hard-coded stuff, such as galaxy rendering, space combat rendering, that you can call in your UI screens.  By those I mean, you can tell the game to "DrawGalaxy" in a window that's 500x500 big, instead of the whole screen.

Right now, I'm just trying to add simple buttons and event handling for those.  But when I get those working, other UI elements should fall in place.  Also, this new UI system uses the new sprite drawing system.  So those two will eventually replace the old UI system and the old image drawing process.  I won't convert everything at once.

Also, my artist just finished the artwork for the Velociraptors!  He will work on Nurds next.  Here's a peek at one of the Velociraptors' ships:


Friday, April 5, 2013

Launcher

While working with some other stuff in the game, I keep running into certain stuff, and finally decided to create a proper launcher where you can select resolution and if it's windowed or fullscreen, and which dataset to use.  With this, you can create a total conversion mod that have its own title screen and such.

The resolution/windowed/fullscreen options are working, however the dataset selection is not yet.  I'll need to re-write the data loading code to work with the new launcher, but in the end, it should be a lot cleaner and less cluttered in code!  As soon as I'm done with this part, I will update the Recent Build branch, maybe next week.  This weekend will be a busy one for me!

Here's a screenshot of the launcher in action:


Thursday, April 4, 2013

Concept for Planet Management UI

One other thing about regions that's been gnawing away at me is the "consumption" part.  While it makes sense in the real world that producing something must consume something (i.e. consuming wood to produce lumber/books/etc), does it make sense that you as the galactic emperor should concern yourself about those details?

"Your Highness, report came in from Region IV of Planet VII of Obscure Star!  They're complaining that they're not getting enough copper!"
"Very well, which regions have excess copper?"
"Region II of Planet I of Obscure Star Two does, sir!"
"Alright, let's send them there."

You're an emperor, not a logistics officer!  So I'm going to follow MoO 1's example and have each planet be self-sufficient in that they should be able to provide for themselves (hence the whole purpose of researching colony bases for hostile planets!).  This will simplify the resource model/system in Beyond Beyaan.

So with this change, I brainstormed about how fields should work.  In MoO 1, each slider can accomplish multiple tasks.  For example, DEF can build missile bases, but if you research shield, it builds that first instead.  Or IND with building factories or putting into reserve.  So each field can have a project, or just produce resources.  I like this, but what I don't like is the inability to change which project a field is working on.  If you see some enemy ships coming to your planet and you just researched Planetary Shield XX, which would you rather to do? Build 2 missile bases by the time they get here, or build half of the shield and have it do nothing when they attack?

I'm proposing that with the economy change, each field don't consume anything aside from a percentage of population's "Production".  If something needs to be consumed (i.e. pollution cleanup), have it be deducted automatically from that field's output.  If insufficient, then there'll be penalties.  If excess, then the excess contributes towards the field's current project.

You can select which project a field is working on.  As for what fields there will be in the game, I'm having six fields, they are:

Agriculture - This field feeds only the people in the region, and can also build agriculture improvements.  Excess food boosts population growth.

Environment - This field cleans up after population's production pollution, and can also build improvements that deal with pollution (such as automated waste processing and other stuff).  Also performs terraforming tasks.

Infrastructure - This field allows you to build general improvements to a region, such as trading port, tourist center, government buildings, etc.  If no project, production is "invested" and generates money

Science - This field allows you to build educational/scientific buildings, if no projects then produces research points.  So you have to trade off between building an improvement (a research lab for example) or contributing to current research.

Military - Can build military stuff such as garrisons, regional shielding, etc.  Garrisons and other buildings can boost defenders' chances of defending in ground combat.  Also can build defense platforms for space combat.

Construction - Large scale construction such as starships, stargates, colonizing a region, etc

Here's a concept art for the UI that I've created for managing outputs.  It's missing details such as region details, specials, etc, but I thought it'd help convey what I'm trying to say more clearly.  Remember that space restrictions will apply, so you can't just build everything in a region, and that you can change a region to specialize in one of the 6 fields (i.e. military region boosts defense bonuses and reduces upkeep of military buildings, for example)  Let me know what you think!


Last, but not the least, I've added a new branch in Desura, "Recent Build".  It's not as feature complete as the old version, but reflects my latest build.  So you can finally try the stuff I've been talking about!

Friday, March 29, 2013

Regions and Sliders Design

I'm going to overhaul how regions are done, and introduce an exciting new feature, but let me explain why I added regions in the first place.

In Master of Orion 2, in end-game, when you've obtained most or all of technologies, colonizing a new planet is a pain in the butt.  Why?  Because you need to queue up buildings that you want to be built.  Which buildings?  It don't matter, because they all help your planet out (Automated factories usually go first because it speeds up production of other buildings).  So in the end-game, you don't really care about which buildings to build, just that you want all of them built.  This kinda defeat the purpose of having unique buildings.  Unique buildings aren't important when you just want "All of the above" approach.

I wanted to have "unique" buildings/areas on a planet where you just can't have "All of the above", and took my inspiration from MoO 3's regions.  While overall, MoO 3 may be a disappointment, but I've found many elements inside it that I really like, and this is one.  With regions, you can have different races inside one region, and each region have their own improvements, limiting which buildings you can build on a planet.

However, I'm now at the point where I need to rework the UI and stuff for planets to work under the new system, I realized that I may be looking at it wrong.  Having unique buildings across specialized regions across planets across the galaxy can easily defeat the whole purpose by introducing tedious micromanagement with little rewards, where you just don't care about that one little building that boosts farming by 10% in an obscure corner of the galaxy.  It also makes each unique building lose their significance.  It'll devolve into "I need more food, let's build an farming region on the next available region and build all farming region buildings there!"

I spent some time thinking about how to avoid this and reading people's suggestions about my game (particularly the one over at rpgcodex), and I think I finally stumbled on an elegant solution that will help me achieve what I originally wanted.  So here's how I'm doing this:

Regions will be replaced with "SectorObjects".  You may be thinking, wait, isn't a planet a SectorObject as well?  The idea is that each SectorObject can have a subset of SectorObjects (aka regions).  This means that you can be as detailed as you want while modding (Having cities in regions in a country in a planet for example), and the game will handle it automatically.  

If a SectorObject contains a subset of SectorObjects, then it derives its population and economy from the subsets and adds them up for the UI to display statistics. Only the bottommost SectorObjects can be controlled by an empire, and as a result, they're the only ones with projects and sliders.  SectorObjects can be changed to different SectorObjects as a result of projects (for example, changing from Farming to Mining region, or terraforming from Desert to Terran planet).  Sliders are defined in data files. If only one slider is defined for a SectorObject, then it's hidden and always at 100% (this allows you to mimic Moo 3's regions).

What does all of this mean to you as a player?  It means that you can share planets with other empires!  Owning a SectorObject requires that certain requirements are met, such as sacrificing a colony ship, creating a project to colonize one, or having migration be able to migrate there without owning it first.  Once owned, your people will automatically migrate there, reducing the need of manually moving around your people.

Now, what about ground combat?  How will they be handled?  I think I have another brilliant idea.  Since each subset SectorObject has a parent SectorObject, you can choose to either invade the whole parent SectorObject, or invade each subset individually.  So if you're invading a planet that is 50% owned by an ally, you can choose to invade only the enemy regions, leaving the allied ones alone.  However, if none are friends of yours, you can invade the whole planet.  The ground combat will be handled like MoO 1.  Also, if you feel that you're outmatched, you can choose to invade only one region and establish that as a foothold.  Same goes for planet bombardment (selecting all of the planet, or just a few regions to bomb)

How does this help me achieve "Unique buildings"?  Another change is that the SectorObjects will have "limited space" for development.  This means that if a region have only 20 "Space", and you build something that takes up 10 spaces, it'll force you to choose carefully on what you want to build.  Also, with sliders back in, you can leave a region "Unspecialized" which don't give any bonuses or penalties for producing something, or change it over to specialized.  For example, if you change from Unspecialized to Farming, then the farming output is doubled, while mining, industry, and commerce are all halved. Then you can build few certain buildings (some may be restricted to certain types of regions, such as Automated Mining for Mining regions only) to further enhance the bonuses or to alleviate the penalties.  Each region can have their own special bonuses/penalties such as fertile grounds, radioactive deposits, etc.  If you change to a different SectorObject, any improvements that don't meet its criterias will be automatically scrapped.

All of this can be managed from one screen that for now I'll dub "Economy Management", you will be able to filter out planets or regions, apply broad changes (such as increasing food output to 50% across all farming regions) or even individually manage each region and their project.  This should help in reducing the tedium in managing planets, while allowing hundreds of planets under your control!