Plan for 0.7 features

As promised, the feature list planned for next milestone, after two features are already done :). This milestone will more deliberately follow a way of working which emerged in the previous one: one under the hood change, one feature implementation and then preview release. On top of that I'll try to add more meat to the game and work toward establishing similar rhythm of implementing systems and adding game content.

Features planned for 0.7:

• Save game preview, a small thumbnail image of a game state in a save game list. This one is already implemented and you can see it in action in previous release.
• Organization traits. Previously a player could pick an organization he is going play as but it was not reflected in gameplay, every organization was virtually the same. With this feature each organization will have a preferred research field and it will advance faster within that field. It's not as groundbreaking as MoO II racial traits but I hope to design research in a such a way that each field would promote different play style. Also already implemented but will be included in next release.
• Stareater brain is going to be a special star system, kind of like Orion system in MoO series but with more prominent importance. Controlling this system will grant owner an ability to control whole stareater and work toward victory condition: leaving stareater's pocket space.
• Colony maintenance is a comeback for a feature before last rewrite but with more time in the oven. Each hostile planet trait will incure certain maintenance fee per population which is going to be payed by whole nation, not just that particular colony. It's similar how Sword of the Stars handled hostile planets and discouraged too fast expansion. Additionally global maintenance system is a groundwork for future mechanics (like espionage).
• Population migration is another feature comeback but this one is as simple as it sounds. As colony gets more crowded people will try to migrate to more roomy places. I may complicate it with planet habitability being a factor in migration desirability but for now I'll limit migration range to planets in a star system. In some future version I might add interstellar migration.
• Area of effect weapons are going to be weapons which damage all units in a tile. Top unit of a target stack will receive full damage while other units in the area are will get reduced "splash" damage. Another feature I'll try to push with this feature are torpedoes, missiles which travel on the map like ships do in order to reach target and can be shoot down.

Since I've already finished two the listed six features I may add more along the way but on the other hand there is plenty of non-feature improvements waiting to be done too. I seriously need to change GUI engine and that's a huge work. Fortunately it can be broken down to small manageable pieces but I still have to be careful with architecture. Then there are graphics. I'm working on procedural planet generator for minting high resolution cartoony planet images and it's progress is so-so. I have decent asteroid algorithm and rudimentary rock planet recipe which should work for Earth-like, Mars-like and Mercury-like planets. I'm still looking for good random stripe generator for gas giants and Venus-like could covered planets. For starships I've finally developed a tool which suites my style of drawing so there is an opportunity for updating existing ship graphics and include source code of images in version control instead of binary data. That's plenty of work to do, will see how much time and energy I'll have, my real life situation is about to get permanently changed.

Plan for 0.6 features

Loads of tech, that's the plan! And some space monsters.

It's been only a month and I already feel like v0.5 rewrite was done over a year ago. Strictly speaking software is never finished but I drew the line back then. Big rewrite was over and there were no glaring bugs. There was some functionality like ship design upgrade and colony/star list which didn't make through migration but they are either moved to future plan or moved back to drawing board.

This version will be about improving the "engine" and adding more gameplay, both featruewise and contentwise. There will be again moderately big code refactoring but I hope nowhere near as much as in previous version. In any case it should be possible to break it down to smaller (doable within a month) chunks. Code improvements made in v0.5 rewrite made that possible. Without further ado here are features planned for version 0.6:

• Diplomacy with some basic capabilities like "declare war" and "cease fire". Will see for more complex interactions but for now I'd focus on laying foundation, figuring out where to put negotiation logic and how to handle it on user interface.
• Hot seat multiplayer. Multiplayer as a whole is not in short term plan but I made a statement some time ago about how certain change brought the hot seat implementation closer to reality. It's time to test the theory.
• Semi-exclusive research like research system in Master of Orion II where you can get only one item per technology field level. Stareater won't be so harsh, you will be able to get all items but you'll have to spend extra development effort. Idea is to instead of picking only one item you'd make your first, second and third choice. First choice item will be the cheapest to prototype, second choice will be expensive and the third will be even more expensive. On top of reworking research system I plan to start adding actual technologies to the game. I've made an draft document with about 120 candidates and more are to be added.
• Ship repair and upgrade will be reintroduced. Ship damage will persist after battle and colonies will passively produce repair points. Once all ships at a star are repaired, surplus repair points will be used for upgrading or retrofitting ships.
• Missiles in combat. First ambition level is to have "instant hit" missiles which will function similar to beam attacks but with slightly different chance to hit and limited ammunition. Next ambition level are torpedoes, missile which move across the map like space ships, can be destroyed and do area damage.
• Space monsters are going to remind you that you are inside of a living organism. Most of them won't attack you directly but will interfere with growing your empire. On the development side their purpose is to give you something to fight before meeting other players or during the peace time and to provide some lore about the Stareater universe.
• New rendering engine is already in development. Previous engine was using old OpenGL API, rendering loop was not very controllable when it came to timing and I'd like to make it easier to link visible objects with user interaction. Part of it is already done by now since messing with OpenGL and multithreading was more interesting to me then writing a post so that's why there is a delay :).
• OpenGL based GUI is something I was looking forward to for a long time. WinForms are so restrictive, even for making ugly but servicable UI. The game uses a lot of lists, each displaying items differently and WinForms have two kind of GUI controls for lists: a simple ListBox where each item is just text and ListView which is basically carbon copy of file list in Windows Explorer. Both are inadequate for my needs so I've been faking lists with other components and the process is so prone to errors and full of workarounds. On top of that there is no way to easily change the look of controls so if I'm going to basically rewrite their drawing logic I might as well do it in OpenGL and solve other problems.
• Refactoring state data is something I've been constantly doing in the last version. State data are stored in data types which beyond just holding the data don't have any more functionality of their own. The problem is there are a lot of such data types and each needs copying, saving and loading logic so there is a lot of repetitious code which looks like it can be generalized except no programming language feature can do that. Efficiently at least. In the last version I've tried C# text templates which are pieces of code for generating code (or any other kind of text file). They work but are hard to debug and update. I've been prototyping another approach, looks promising so I'll try it out.

Orbital habitation

Back in version 0.3 I've been thinking about adding orbital habitation feature that would allow players to populate moons and even planetary orbits. For the rest of the post I'll refer to moons and orbit as just orbit. I ditched the idea because I couldn't come to terms how farming and mining should cooperate with the feature. Should there be a limit how many miners can exploit the planet, should there be penalties for transporting goods from surface to orbit (because there is such penalty when building ships). Splitting colony to two, one for each "plane", would help organize the matter but brings another question. Since surface and orbit would be very different in productivity and construction costs,  should there be different building queues for each "plane"?

Recently I thought about bringing orbit back. Thing is, I wanted to make gas giants feel different from normal "rock" planets. Orbital habitation seamed as the nice tool to achieve that, normal planets would have a small orbital area compared to a surface while gas giants would have it other way around. Logic was that gas giant "surface" would be actually surface of it's moons and a "orbit" would be the gas giant itself. But same questions from 2 years ago made me to ditch the feature again. Instead I'll bring gas giant moons directly into play.

Firstly I'd like to add special traits to all planet types. Traits would be mainly negative stuff like acidic atmosphere (increased environment hostility), active vulcanos, large mountains (less inhabitable space). Occasional there would be positive effects such as active core (less radiation) or fertile soil.

Than I'd add moons in place of gas giants. Each gas giant would be represented with cumulative surface of it's moons and traits that partially affect colony, simulating diversity of moons. For instance Jupiter has 4 moons "worth of notice" so it would be represented with 75 size points (75% of earth sized body) with vulcanic (Io) trait that affects 1/4 of colony, water world (Europa) trait that too covers 1/4 of colony and some gas giant specific trait like cheap fuel (faster ship resupply). What partial trait coverage means is not decided yet. In the simplest case it would be simply reduced normal trait. In a more complex case it would kick in when colony starts to utilize that part of moon system. For instance Io's vulcanic trait would start affecting the colony once it's population grows beyond 75% of maximum with increasing strength as population reaches 100%. I'll decide it when I start implementing planet traits.

New game screen

So, GUI time. To be honest, I didn't do much coding. I've spent some time writing about technologies in design document. For now research and development are covered by the document but those topics also opened some new questions and made me aware of one more topic related to technologies. The new topic is  point spending focus. So far I thought about it as a little detail but it turned out it's bigger than that, big enough to have a chapter for it self. The questions I mentioned are should research scale with the number of players and should researched theories be easy share (traded during diplomatic agreement or stolen through espionage). Problem of scaling is that if theories are easy to share, having an ally could drastically speed up the research. I'm not talking about 10%-20%, I'm talking about 100%-200%. By writing this, I recalled a certain feature of Civilization EVO game. Trading technologies there didn't simply counted as acquiring fully researched tech, instead cost of researching traded tech was halved. I like that approach and maybe I'll do something along that line.

Oh, that picture on the top? It's a concept for a "new game" screen/window/form/dialog. It's much like old one except "Map" and "Starting population" drop down menus are replaced with buttons that will open respective dialogs. Reason for those changes are support for multiple map generation methods and more options for starting population. The concept is by no means final and there are some stuff I'd like to change. For instance, there is no way to select player's color and I'd like to add some way for choosing "faction" and color for the opponents.

Also I'd like to mention that I was a little distracted by making tools for creating graphical content. One such tool is for toying with procedurally generated images (picture above). Old images for stars on the galaxy map were in GIF format and don't contain information about transparency in the so called alpha channel and this tool is designed to produce such images. Also the tool is a framework for implementing different image generators.

Other tool is for making "vector graphics", images defined by shapes rather than by limited number of pixels. As you can guess from the picture, the tool will be used for drawing ships for the Stareater. The thing with this tool is that shapes' vertices are always on the grid. Somehow I find it that my drawing skill work best with that restriction.

And last but not least distraction is the IKON library. I was writing unit test for IKSTON to do the "test app" right, to test the nifty TDD features of Visaul Studio and to easily check whole library when I change something. I'll continue with these distractions, I have to write some more unit test for IKSTON and there is still a lot to do on the Grid Canvas (that air plane on the image above). I hope I'll soon find enough motivation to finish the new game screen for the Stareater and to finally start with the interesting stuff.

IKON and IKSTON

As mentioned before, I've designed my own data format for the Stareater data. The language has an abstract foundation and concrete version. Abstract part is called IKON (Ivan Kravarščan's object notation) and on it's own doesn't define any data format and cannot be used as such. What it does define is:

• Identifier format (sequence of a-z, A-Z, 0-9 and _ characters).
• Value syntax:  sign data [@ identifier]*
• The sign is a character associated with the parser for that kind of value. 
• Identifers after "@" are reference name, "*" means zero or more.
• Each value should  have a type.
• Abstract classes, interfaces and helper classes for quick development of concrete data formats.

IKSTON (Ivan Kravarščan's object notation) is concrete IKON. It resembles to JSON without double quotes in keys in key-value pairs. It has five types of values, number, text, array, compound, referenced values. Text is perhaps the simplest. Sign for text is ", the double quote. Text ends with the second double quote that is not escaped. Escape codes are:

Escape sequence	Translates to
\\	\ (backslash)
\"	" (double quote)
\n	new line character
\r	"carriage return" character
\t	tab character

Standard stuff, escaping escape character, escaping "end of data" character and a few convenience options.

Numbers are slightly more complex, sign is =, equals character and number parser reads (after skipping whitespaces after sign) the input until it finds a character that not either from 0-9, a-z, A-Z or period or minus. Reason for accepting letters is that scientific notation (such as 1.5e3 instead of 1500) and special numbers such as Infinity, -Infinity and NaN should be accepted. Scientific notation is useful especially since a lot of cost values in Stareater tend to be 9 digit values and infinity "symbol" is good to have around. Also it's good to point out that a number is ambiguous terms when it comes to programming. Numeric IKSTON values do not automatically convert textual representation to numeric representation (integer, decimal, floating point) but they offer methods for getting a value as specific numeric representation.

After explaining text and number values, arrays sound are simple, sign is [, left square bracket, data are whatever IKON data there is and closing character is ], right square bracket. For example:

[ "text1" "text2" =1 =2 "text3" =1e6 ] @testData

Now you see the deal with sign characters. In many other data formats numbers are just numbers but in IKSTON numbers require equality sign. It may seen unnatural but the up side for that is there are no type guessing. Text may not accidentally end up being number. Example also shows how references are declared. Before explaining compound type, example first:

{ star
   size = 12
    x = 9
    y = 4
    name "Alpha Centaury"
    planets [
        { Planet size = 100 }
        { Planet size = 120 }
        { Planet size = 10 }
    ]
}

As you can see, the sign in {, left curly bracket. First thing in the compound value is the identifier with the name of the "class". As stated before each value has a type. Numbers, texts and array have the constant type names (IKSTON.Numeric, IKSTON.Text, IKSTON.Array respectively) while compound values have whatever that first identifier is as a type name. After type name, compound value can have key-value pairs (identifier and IKON value) before being closed with }, a right curly bracket.

Shish, that's a lot of explaining for a something that will not be used "as is" in the project. IKSTON will be used for application settings but localization and game data will use different implementations of IKON. Come to think of it, save game format might be the pure IKSTON. I've already started with localization implementation but more about that in the next post.

New code organization

Terrain for a new version is being prepared. Currently I'm working on how should the source code be organized. As stated (hinted that is) in previous post there will be separate projects for the "game core", GUI, map generators and AI, see the big picture below. Game core would consist of game mechanics (MVC model), MVC controller and interfaces for map generators and AI.

Second thing I'm working on is documentation for the code organization. There will be a document that lists and describes responsibilities for each component. It will answer questions such as what data should be in "Game" class, what data should be in "Player" class, what namespace is responsible for what and stuff like that.

Third thing is external dependencies. There should be well define formats for data files and localization files. I was looking for third party solution but wasn't really happy with any. XML is not exactly "human readable" and more importantly, not human editable. Only environment where XML is OK is when developing Android applications in Eclips IDE. Eclipse with Android Development Tool make a very powerful and easy to use environment but in the case of Stareater there is not going to be such advanced support just for editing XML. JSON and YAML were also considered. There is a quite good .Net library for JSON, Json.NET and a solid library for YAML, YamlSerializer but I wasn't fond of using either markup. Maybe it's just me being picky... Anyway, I've created yet another "my own format" that meets my needs.

That's just about how to read and write data files but there is more to be defined on how to format the data. In previous versions, there were two complex data formats, functions and text builders. Functions were used to represent values such as how food production changes with technologies and how damage increases with weapon tech level. Problem with functions was that their textual representation were either prefix  or postfix (also know as Polish and reverse Polish notations) to simplify parser. Prefix and postfix are notations where operator is before (prefix) or after (postfix) operands while notation where operator is between operands is called infix notation. Simple a + b translates to + a b in prefix notation. Prefix and postfix notations are easier to implement, operator precedence is not an issue and there is no ambiguities such as 2/3/4=?. Those notations are too much machine/algorithm oriented, expressions with more than one operator may look cryptic to the eyes used to infix notation. In v0.5 I'm going to make parser for infix expressions. ANTLR looks like a good tool for making parser in .Net though they have silly homepage :).

Text builders are used for localization. Initial idea was to make a simple key-value mapping where a key is a kind of the text identifier and a value is localized text. Than I've spotted situations like "Remaining: 5 turns" would require two key-value pairs to localize because it brakes down to the following sequence of textual units: transalation for "Remaining", semicolon, number of turns, translation for "turns". Another thing to notice is that last word should not always be in plural. To cope with that, localization data format had three ways of expressing localized text. One was simple single line of text, another was sequence of primitives (literate texts, conditions, functions) and last one was multiline block of text with substitution parameters. It was not hard to implement that and it was indeed powerful enough to put words in the proper form even in Croatian but readability was not the strongest point. Hopefully in v0.5 it will  improved.

Uf, that's a lot of work and I haven't even started with GUI. Good design documents are the key and I'll spend some time writing them before I star coding.

Stareater 0.4

Five days ago version 0.4 finally got packed up and ready for download. Big changes happened between 0.3 and 0.4, space combat is implemented, ship design interface is changed to reflect redefined space combat, star system management is introduced, part of colony management is moved to star system and basic AI is implemented.

Plans for version 0.5 are not yet defined but this is a list that is currently on my mind:

• Define exactly how planets and colonies work
• Refactor whole code base
• Redo GUI
• Victory conditions

Only last item adds something tangible to the game but other items where piling up for a long time. It's time to do those things right. Every now and then something about colonies would go off. Since all game mechanics are based on non-integral arithmetic final numbers can get too low or too high than intended if parameters are  not constrained. Math behind colonies has such problems and I'd like to take some time to think about how exactly colonies should behave. There are other part that I'll address in a similar manner such as map generation.

Refactoring is also something that should be done before adding more features. I'd like to strip user interface code from all non-interface related code. That means game logic, data preparation and data conversion should be outside the GUI source code (classes). I'm aiming for model-view-controller design pattern where game logic is model, GUI is view and controller mediator between them. Also I'd split source code to two projects, one with model and controller and other with GUI. While refactoring, I'd like to redo whole GUI. There has been a number of conceptual changes that are not properly propagated to the user interface and some thing simple has to be done differently. Galaxy map is such thing. I'd like to scrap "big picture box in scrollable pane" implementation and try my luck with OpenGL.

That's enough to keep me busy until the end of the year.

Zvjezdojedac, planovi za verziju 0.4

Ukratko stavke za slijedeću verziju Zvijezdojeca su slijedeće:

• Upravljanje na razini zvjezdanog sustava
• Umjetna inteligencija za upravljanje kolonijama
• Svemirske bitke
• Preinaka prikaza informacija za kolonije
• Prikaz liste kolonija
• (Možda) Preinaka varijabli za formule da budu strong typed

Upravljanje na razini zvjezdanog sustava

Kao što sam napisao u prošlom postu, maknu bih podjelu gradnje na civilnu i vojnu i napravio bih da se brodovi grade na razini cijelog zvjezdanog sustava. Nešto slično kao u prvom Master of Orionu. Na svakoj koloniji bi se moglo odrediti koliko se sredstava odvaja za projekte na razini sustava a upravljanje redom gradnje bi se vršilo na sučelju koje je trenutno prikazuje informacije o zvijezdi i popis planeta.

Umjetna inteligencija za upravljanje kolonijama

Globalni plan za UI je da se upravljanje razlomi na razine. Prva razina bi bila glavna mapa. Algoritam bi određivao koliko je pojedini sustav u posjedu ugrožen i kolko su ostali sustavi pogodni za istraživanje i naseljavanje. Na temelju tih informacija bi se slali brodovi i određivala tendencija gradnje brodova. Druga razina bi bila pojedinačni zvjezdani sustavi. Algoritam bi za tu razinu na temelju informacija s prve razine određivao što će se graditi na razini sustava (da li ratni brodovi, da li kolonizatori ili poboljšanja za planete). Također, na toj razini bi se određivala tendencija ulaganja u zvijezdani sustav tj.  koliko će kolonije odvajati sredstva za sustav a koliko za sebe. Treća i najniža razina bi upravljala samim kolonijama. Znači, što kolonije grade i koliko u što ulažu.

Za početak napravio bih nešto jednostavno, UI koji će razvijati svaku koloniju kao da je sama svemiru. I dodato bih neki jednostavan algoritam za drugu razinu kako bi računalni protivnici gradili brodove za testiranje bitaka.

Svemirske bitke

Najsočniji dio svake igre. Trebam još definirati kako će se koji atribut ponašati. Imam neke ideje ali moram ih još uskladiti. O tome više kada ova stavka dođe na red.

Preinaka prikaza informacija za kolonije

Trenutni prikaz mi se čini kao da prikazuje previše informacija odjedanput. Htio bih napraviti sučelje na kojem se na prvi pogled može vidjeti koliko je koja kolonija razvijena i produktivna a da se do detaljnijih informacija može doći kada se miš pozicionira iznad pojedine stavke (Civilization 4) ili na klik (desni klik u Master of Orionu 2). Time bih dobio više mjesta za prikaz detaljnih informacija i izračuna kako je koja brojka dobivena i na sučelju za kratki pregled, ne bih morao prikazivat puno toga.

Prikaz liste kolonija

Nekoć davno 4X strategije sam igrao na način da bi svaki krug zavirio u svaki grad/koloniju i gledao da li mogu što poboljšati. Takvi turnovi su znali potrajati i po 10 minuta. S vremenom sam se naučio kako se većina micromanagmenta može izvesti preko popisa kolonija (Master of Orion) odnosno gradova (Civilization 3). Kod takvog pristupa, turnovi traju pola minute. Moć popisa kolonija zasniva se na prikazu bitnih informacija i načinu sortiranja stavki. Dobar popis kolonija treba biti u stanju odgovarati na upite dosta visoke razine, kao npr. "koje kolonije su dobre za izgradnju brodova?" ili "koje se kolonije još trebaju razvijati".

Za početak ću napraviti jednostavnu listu s nazivom kolonije, populacijom, procjenom razvijenosti i nazivom zgrade u gradnji i s mogućnošću sortiranja po tim svojstvima.

Preinaka varijabli za formule da budu strong typed

Ovo više finesa ispod haube. Ideja je da od <string, double> hash tablica u kojima se može nalaziti sve i svašta, napravim singleton razred u kojem će za svaku varijablu u igri postojati članska varijabla. Prednosti takvog pristupa su da ću imati jedno mjesto na kojem će varijable biti hijerarhiski poslagane, neću morati izvoditi finese s nazivima varijabli (trenutno skoro svaka varijabla ima za svoj naziv const string da ne moram rovat po kodu i prepisivati), možda će biti brže, ne ću morati instancirati toliko dictionary<string, double> objekata i biti će manje parametara u metodama za izračun vrijednosti formula.

Uglavnom, uz par velikih djelova gameplaya ova verzija će biti više fokusirana na fluidnost sučelja. Nadam se da ću je dovršiti do kraja godine a ako Bog da, u roku 2 mjeseca. I da ću po implementiranim featureima prestići FreeOrion :)