So, recently, I changed over the backend session cache from a server-specific Java ConcurrentHashMap implementation to a Redis cache.
Our session caching system is now powered by Jedis!
But seriously, Jedis is the Java implementation (one of several) of the access client to the Redis cache.
The Redis cache itself is an impressively small -- only 13Mb of RAM running the server on Windows 7 -- and stores keys as hashed strings to save space for people who don't already hash their cache keys. I am storing the sessions as JSON strings using Google's Gson to serialize and deserialize the JSON to and from my custom session objects. The memory usage of the Redis compared to the ConcurrentHashMap that I was using are similar, but I gain the ability to access Redis from other servers in the same VPN as my other backend servers, so I can skip my clever passing of encrypted sessions via HTTP parameters.
The Jedis client itself is fairly compact and straightforward to use for the most part. The only slightly complicated piece is the pooling, but it operates on the Apache Commons Pool 2 library, so there is copious amounts of documentation for it.
On top of this, I wrapped the Jedis in an API to mirror the ConcurrentHashMap API that my previous cache used, so it was a simple drop in solution for the implementation and only took about 1 hour of time to complete, which was incredible. Most of my coding takes several hours to do and then hours to days to sometimes weeks of debugging. So, to have it just work was astounding and speaks highly to the quality of the programming of the Jedis folks.
á na márië,
gumshoe, out
This post is going to introduce some basics of what a fiat currency is, how it works, and why it is important enough to be included in this game. This article will be a bit dense, but I will try to keep it as simple and straightforward as possible.
Fiat currencies (or fiat money) are imaginary units of value created and issued by a government which derives its value by the faith of a people in the competency and stability of said government.
In other words, it is funny money that gets value from you and I using it. It's like Monopoly, only on a far grander scale.
The fiat currency works by a dizzying array of complicated mechanisms only a handful of which will be modeled in the alpha and beta versions of this game, namely the exchange markets and the sovereign debt markets. These two, in simplified forms, will be sufficient to give players of FATES: Carpe Moerae the experience that only central bankers (like those at the U.S. Federal Reserve or Bank of England, etc.) receive.
The exchange markets operate by allowing individuals the capacity to turn one unit of currency from a nation into a set number of another currency from another country. Most of this exchange will be done behind the scenes in FATES: Carpe Moerae using a linear multiplier to compare all player currencies to one. From there, the computer will simply divide and multiply to display all pricing data in your currency in game, so the complexity should be minimal, at least on the surface. What you will notice, however, is the fluctuation -- sometimes extreme -- of prices as both your own currency and those of every other player on your server change in value.
The currency model, currently, is very simplistic, and will be expanded to more closely model real global finance as we go forward. At present, it operates on a simple algorithm. You can print money and you can spend it. When you spend it, the value of your currency goes down, meaning that one unit of your currency will buy fewer goods and resources. When you tax, trade, and invest, the value of your currency will go up by a set amount. In managing the process of spending and producing, you will be able to have control over the value of your currency. Will you choose to keep a highly valued currency and be able to purchase lots of resources for very little, or will you devalue your currency and be able to undercut market prices easily because of currency exchange rates? These are choices that you will need to consider in the long run if you want to be successful in FATES: Carpe Moerae.
The sovereign debt markets will be a bit more complicated and are not fully designed or implemented yet. The idea of sovereign debt markets is the players will be able to invest in their friends (or enemies) in order to facilitate growth or to create dependence scenarios to create leverage. The bonds will be redeemable at expiration for the base amount plus the interest rate on a given player's debt. The debt can be used in lieu of printing currency and can be demanded back at any point in time by the player lending the money. This will create a wide range of geopolitical scenarios and a means of producing, maintaining, and exerting leverage on other players in FATES.
We have tossed around other ideas in expansion to these two primary features, such as allowing federations to issue currency and subsume the responsibilities from individual players to the federation leaders, much like how the European Monetary Union works.
Ultimately, though, this will be a grand experiment to see how each player manages their economy and finances and see how these elements play out in the player psychology and interactions between players. In learning to identify and manage their own currency value, players will get a good feel for how fiat currency works in the real world, and hopefully become more prudent about voting with regards to the dangers that fiat money presents to a society.
It will be interesting, for sure.
á na márië,
gumshoe, out
Being a strategy game, the economics of the game will be absolutely essential to the evolution and development of players through the lifetime of the game. Mastering the economics of any strategy game is the surest path to victory, and this game will be no different. The prime difference between FATES and most other strategy games that you have played is that FATES economy is based very closely on the real world, especially the global financial system. In mastering the economics in FATES, you will inevitably see the same mechanics at work on the global stage and various wars in the real world that are presently progressing in the shadows of awareness will become evident.
However, for part one of this series on economics, I am going to address simply the fundamental resources in FATES, how they will be acquired and used and how they will be transported and traded. I will touch on the financial and currency stipulations, but I am going to save the meat of that for part II.
The economy in FATES will operate on five fundamental resources, metal, composite, ceramic, food, and currency. The metals, composites, and ceramics will be used to construct planetary structures for developing individual colonies and to produce spacecraft for interstellar exploration, exploitation, and warfare. The food resource will be used as a limiting consumption resource both for planetary populations and fleets based at planets on a per capita basis. Each planetary population unit and spacecraft crew will eat a specific amount of food per second. The food will either have to be produced at the planet or transported in from other systems. There will be storage facilities for each specific resource that can be constructed on a planet surface in order to allow for specialized planetary infrastructure. There are several types of colonies that we expect to arise naturally, such as food planets, industrial production planets, military outposts, commercial shipping planets, financial centers, and research planets.
Each resource will have specialized terrain features that increase production such as metal veins, springs, etc. that boost individual resource production in adjacent planetary slots. Each planet will specialise in producing certain materials thus creating a need-based economy among players who will have excesses of certain materials and shortages of others. These resources will be able to be traded on the Galactic Exchange for fiat currency units. The Galactic Exchange will operate using each player's fiat currency and automatically calculate exchange rates and display the costs of resources available in the players own currency; however, the cost of resources will vary widely from player to player based on how well they manage their fiat currency. A player with a very strong currency will be able to buy lots of resources inexpensively but will also be constrained in selling their resources. Likewise, players who possess weak currencies will be able to sell their resources very cheaply on the Exchange, but will be unable to purchase resources easily or cheaply.
Thus management of the fiat currency will be paramount to successfully competing in FATES: Carpe Moerae. If you do not wish to manage your currency, however, there will be an Archon available for purchase which will manage it for you.
The resources that are traded on the exchange will be transported and charged transportation fees based on distance from the seller to the buyer. We have been tossing around the idea of pirates or privateers being able to raid resource shipments, but for now, these will not exist.
I will be addressing more details on the fiat currency system next week, but this should begin to give you an idea of how the economics in FATES: Carpe Moerae will operate.
á na márië,
gumshoe, out.
FATES: Carpe Moerae will be a hardcore strategy game at its core.
What does this mean? This means that if you lose all of your planets, you will be out of the game.
However, there will be some nuanced mechanics that will help to alleviate the impact on new and developing players to prevent them from being abused by larger and more developed player empires. I want to discuss some of these mechanics in broader scopes and discuss how they are intended to work.
The primary way that new players will be protected is through the federation system. There will be statistical mathematics in place that will very strongly incentivise federations -- especially the larger and more powerful ones -- to recruit in lower score players. This mechanic operates on the basis of comparison of the score distribution of all of the players in a given federation and the score distribution of all players on the server and grant the federation a bonus to resource collection, taxation income, research, production, and construction based on how closely their federation player score distribution matches the servers'. These bonuses will be the largest in the game -- around a maximum of +30% -- greater than all other factors. This will discourage federations from stacking all of the best players into one federation, as doing so will yield a bonus of less than +1%, where as balancing a federation with new players and more experienced players will yield larger bonuses.
The second mechanic that will assist new players in developing their empires more quickly is a server birth time-based bonus that will slowly scale upward as the server ages. This bonus will help to accelerate new players who join later in the life cycle of the server. This bonus will decay over the span of a few weeks as the new player gains experience and develops their empire. The server age bonus will allow them to catch up and help to alleviate the disadvantage of starting the game after the server has launched.
The third mechanic that will help to prevent new players from being abused is the galaxy placement algorithm. This algorithm will seek to place new players as far from well established empires as possible and near any friends that they have indicated ahead of time through friend sharing links. The galaxy placement algorithm will put some raw distance between new players and large empires giving them more time to develop their empires, awareness and knowledge.
The final presently planned mechanic that will aid new players is the Galactic Council diplomatic immunity or protection treaties. These treaties will be voted on by a simple for-opposed vote and will take effect if the for votes outweigh the opposed votes. As such, this mechanism will require the new player to have a sponsor already established in the Galactic Council -- and not have enemies also in the council, and can either be stand alone initiatives or part of larger negotiations. These treaties will also be temporary and will be enforced by the CETU armada.
So, while FATES: Carpe Moerae will be a hardcore strategy game by nature, there will be various mechanics in place to prevent new players from being abused. All of these mechanics will be tested out in beta test phases and are always subject to change. Hopefully, this post will allay the fears which some players have expressed to me already.
á na márië,
gumshoe, out.
I am going to take a brief hiatus on discussing game mechanics to discuss some of the technical solutions that helped us get to where we are now.
This game runs on a couple of key technologies, some of which have emerged just in the last few years. The first key technology is Java 2 Platform for Enterprise (J2EE) including the full servlet stack using Tomcat as our servlet container. The second is HTML5 including the latest JavaScript. These two technologies make up the backbone of our entire project, J2EE for the back-end server code and HTML5 for the client side code.
Originally, (around 2014) the back-end code relied on a PostgresQL database directly and this worked up until we needed to update millions of resource entries per second, at which point even the batched groupings of SQL statements, like,
UPDATE schema."TABLE_NAME" SET "RESOURCE"="RESOURCE" + "RESOURCE_CHANGE";
were still not fast enough to update all of the resources for every planet, since it was responsible for updating millions of entries. This project nearly died here were it not for the clever thinking of one of our previous technical people, Cris, who later moved on from the project. He suggest the idea of using an in-memory caching system, which ended up solving the speed problem completely.
We began by looking at existing caching solutions, such as memCacheD, Java Caching System, EhCache, and Google Guava, but we discarded them for a variety of reasons including excessive overhead, poor output formats, uncertain security, and poor performance in our cloud environment. Ultimately, I ended up designing and building a customized caching system for this game specifically seeking to accomplish our odd set of goals of simplistic structure, ease of Json output without excessive transmutation, security, and speed.
The system revolves around storing a minimalistic view of the database in a Java object in the RAM of the server. Surprisingly, the entire database in Java only amounts to about 1.6 Gb of RAM usage for 40,000 stars.
The system has the convenient property of allow us to output JSON without creating any new Java objects for most of the Application Program Interface (API). The API covers all of the communication protocol between the game client and the server and most of the communication is done with HTTP GET requests.
The game client itself is an HTML5 abstraction that was created using the game development software Construct 2. This program allowed us to quickly get a demonstration test client up and running displaying 100,000 stars immediately, so we selected this suite over other options like GameMaker, D3, or doing it in raw JavaScript.
So, looking at it altogether, the game stack looks something like this:
The PostgresQL database provides us with failure resistance, the Tomcat servlet container allows us to run all of the multi-threaded servlets and game engines that crunch numbers quickly, all of which are stored in the in-memory cache and fed to the game client via the servlet API. The actual architecture is a little more complicated than this, but I don't want to bore you all.
I'll address other technical aspects in future posts.
á na márië,
gumshoe, out.
