Development is still continuing, albeit more slowly.
I have been subsuming the responsibilities of my co-founder and taking over the marketing and Kickstarter process for our game.
Things are still going!
20 November 2017
12 January 2017
Alpha Testing Phase Started
Hey all,
We have finally reached the alpha testing stage of development.
Currently operational are these game mechanics:
We have finally reached the alpha testing stage of development.
Currently operational are these game mechanics:
- Stars and galaxy - DONE
- Planets - DONE
- Planetary cities - DONE
- Starship design - DONE
- Starship production - DONE
- Fleet creation - DONE
- Research tree - DONE
- Fiat currencies - DONE
- Galaxy chat - DONE
- Technology tree - DONE
- Fleet travel between stars - DONE
- Creation of new colonies - DONE
- Fog of war - DONE
7 June 2016
First Alpha Test Push
We are closing on the alpha test and Kickstarter launch, so I am going to cease regular posting on the blog for a bit during the final push to the first alpha test phase such that I can focus on finishing the product.
á na márië,
gumshoe, out.
á na márië,
gumshoe, out.
31 May 2016
Our Web Portal is Encrypted Now!
This week has been consumed with upgrading our servers to use SSL. SSL is required to keep your usernames and passwords secure from hackers in transit between your computer and our servers.
We are using the new service "Let's Encrypt!" which offers free SSL certificates for any website.
The Let's Encrypt service has a Linux program that is installed as a service and updates the SSL certificate every 90 days automatically in the background. I am quite happy that this service exists now, and thank all of the people involved in making Let's Encrypt a functional reality.
á na márië,
gumshoe, out.
We are using the new service "Let's Encrypt!" which offers free SSL certificates for any website.
The Let's Encrypt service has a Linux program that is installed as a service and updates the SSL certificate every 90 days automatically in the background. I am quite happy that this service exists now, and thank all of the people involved in making Let's Encrypt a functional reality.
á na márië,
gumshoe, out.
24 May 2016
Game Development: Player Design Control
Today I wanted address some of our plans and ideas for including player input while maintaining prudence and suitability. We firmly believe that player input as a whole is necessary to guiding design decisions; because as much as we are building a game that we love, we want the players to love it too.
However, being of sound mind and prudent judgment, we want to avoid a Boaty McBoatface or TayTweets scenarios where the internet trolls come out in force in order to trivialize populist initiatives such as this. So, as you might imagine, we will not be giving players complete control of the direction of our game.
We have put a considerable amount of thought into this problem and presently have three major solution archetypes.
1. Structured Voting Application: Something akin to what Game2Gether at Amplitude Studios has done with their voting process, where the developers choose all of the voting choices and the players vote for it.
While this structure has promise and is a sure way to avoid issues, we also want to avoid creating an overly controlling referendum-type issue.
The structured voting application also fails to tap into the infinite creativity of players and leverage that to make new and innovative mechanics. While I am confident in our team, there are only four of us and there will be thousands to millions of players. The likelihood of a player having a brilliant idea is considerably higher than the likelihood of one of us having the same idea.
2. Voting Shares Experience Application: The second archetype that we came up with is a share-based voting system where everyone who has a verified email gets one vote, while people with accrued playtime will get additional votes. This system could either be structured or unstructured as far as voting options are concerned. This would allow more experienced and loyal players with seniority to have a greater say in the direction of the game, while still allowing new players to have input. This system has more flexibility also in that we can reward people for reading the forums or blogging about FATES. I hate to include Twitch in this list, but there are apparently Twitch chess channels.
3. Up-Down Voting Shares Application: The third paradigm that we considered is a Reddit- or StackOverflow-like system where you get both up-votes and down votes. This system would be unstructured and allow anyone to input suggested developments, while still allowing for people to knock down silly ideas. We would use a voting share system with this one also, likely in order to give active, long-time players more say into the direction of the game that they love.
We will probably end up using all three of these voting systems at various times during development, starting with the Structured Voting Application in alpha phases where to ambiguity of on the part of players is high and slowly migrating to an Up-Down Voting Share application when we are fully established and have a player base.
All of this will be subject to testing and development as we move forward though, but these are some of the ideas that we have been tossing around behind the scenes.
á na márië,
gumshoe, out.
However, being of sound mind and prudent judgment, we want to avoid a Boaty McBoatface or TayTweets scenarios where the internet trolls come out in force in order to trivialize populist initiatives such as this. So, as you might imagine, we will not be giving players complete control of the direction of our game.
We have put a considerable amount of thought into this problem and presently have three major solution archetypes.
1. Structured Voting Application: Something akin to what Game2Gether at Amplitude Studios has done with their voting process, where the developers choose all of the voting choices and the players vote for it.
While this structure has promise and is a sure way to avoid issues, we also want to avoid creating an overly controlling referendum-type issue.
(To any Russian readers, this is a gag meme and not reflective of reality.)
The structured voting application also fails to tap into the infinite creativity of players and leverage that to make new and innovative mechanics. While I am confident in our team, there are only four of us and there will be thousands to millions of players. The likelihood of a player having a brilliant idea is considerably higher than the likelihood of one of us having the same idea.
2. Voting Shares Experience Application: The second archetype that we came up with is a share-based voting system where everyone who has a verified email gets one vote, while people with accrued playtime will get additional votes. This system could either be structured or unstructured as far as voting options are concerned. This would allow more experienced and loyal players with seniority to have a greater say in the direction of the game, while still allowing new players to have input. This system has more flexibility also in that we can reward people for reading the forums or blogging about FATES. I hate to include Twitch in this list, but there are apparently Twitch chess channels.
3. Up-Down Voting Shares Application: The third paradigm that we considered is a Reddit- or StackOverflow-like system where you get both up-votes and down votes. This system would be unstructured and allow anyone to input suggested developments, while still allowing for people to knock down silly ideas. We would use a voting share system with this one also, likely in order to give active, long-time players more say into the direction of the game that they love.
We will probably end up using all three of these voting systems at various times during development, starting with the Structured Voting Application in alpha phases where to ambiguity of on the part of players is high and slowly migrating to an Up-Down Voting Share application when we are fully established and have a player base.
All of this will be subject to testing and development as we move forward though, but these are some of the ideas that we have been tossing around behind the scenes.
á na márië,
gumshoe, out.
17 May 2016
PostgreSQL 9.5 Upsert Capability
Our data permanence relies on PostgreSQL for its failure resistance. So, far this week has been spent upgrading our Amazon Web Services relational database system to the new PostgreSQL 9.5.2 to include the Upsert capability.
Upsert, you say?
Upsert is a technical term for an insert or update of a data row rolled into a single transaction. Prior to this I was jury rigging a solution in Java on the layer above the database, but now I can use the upsert to avoid all of the excess computational power required to juggle things in Java.
Why did take so long for PostgreSQL to implement, doesn't Oracle and MySQL do it already?
Yes, MySQL has an INSERT OR UPDATE capability, but it doesn't care about concurrency issues, namely race-conditions and thus data integrity is not preserved in a MySQL INSERT OR UPDATE transaction when you have multiple threads interacting with the database at once. The problems surrounding the insert or update are described very playfully in this post. Oracle does atomically, thread-safe upsert already, but it is not open source, so to have an enterprise-level open source database include upsert is a big deal.
However, translating the upsert from Java to PostgreSQL has had an annoying and unforeseen consequence. Heretofore the primary key assignment responsibilities lay in the PostgreSQL's 'bigserial' data-type which causes PostgreSQL to automatically create a sequence to increment the primary key. However, the upsert statement in PostgresSQL does a conflict check that requires the potential key to be input into the statement like:
where the Primary Key field has to be included in the INSERT statement, otherwise you end up inserting ad infinitum because there is no conflict when you don't have a primary key that you want to insert.
So this precipitated a change in how keys are assigned on the server-side software, namely that primary key assignment now falls to the data cache rather than the bigserial of PostgreSQL. It is annoying, but necessary to gain the atomic, thread-safe upsert that is completed in a single transaction.
á na márië,
gumshoe, out.
Upsert is a technical term for an insert or update of a data row rolled into a single transaction. Prior to this I was jury rigging a solution in Java on the layer above the database, but now I can use the upsert to avoid all of the excess computational power required to juggle things in Java.
Why did take so long for PostgreSQL to implement, doesn't Oracle and MySQL do it already?
Yes, MySQL has an INSERT OR UPDATE capability, but it doesn't care about concurrency issues, namely race-conditions and thus data integrity is not preserved in a MySQL INSERT OR UPDATE transaction when you have multiple threads interacting with the database at once. The problems surrounding the insert or update are described very playfully in this post. Oracle does atomically, thread-safe upsert already, but it is not open source, so to have an enterprise-level open source database include upsert is a big deal.
However, translating the upsert from Java to PostgreSQL has had an annoying and unforeseen consequence. Heretofore the primary key assignment responsibilities lay in the PostgreSQL's 'bigserial' data-type which causes PostgreSQL to automatically create a sequence to increment the primary key. However, the upsert statement in PostgresSQL does a conflict check that requires the potential key to be input into the statement like:
So this precipitated a change in how keys are assigned on the server-side software, namely that primary key assignment now falls to the data cache rather than the bigserial of PostgreSQL. It is annoying, but necessary to gain the atomic, thread-safe upsert that is completed in a single transaction.
á na márië,
gumshoe, out.
10 May 2016
Pace of FATES
The pace of a game plays into a lot of factors, and today I wanted to briefly discuss the pacing of FATES. The pace of the game describes how quickly or slowly the game plays out. The pace determines how tense the game is or how much thought can be put into playing it. Many games are very fast-paced and require reaction more than proactive thought and strategy and FATES will fall very much into the proactive thought and strategy category.
FATES should, if our design plays out appropriately, play like a very expansive, very convoluted version of chess. Most of the major players will be federations each vying for territory and influence in the Galactic Council and economic arenas, however there will likely be a whole host of smaller federations and single players who will fill the gaps in between the large factions potentially even serving as strategic buffers between major powers or even as mediators.
From server initialisation until someone wins should take around 6 months to 1 year, although there are parameters in place that can be tweaked to modify the pacing of the game. This should produce a pacing appropriate for both busy people who can only devote a few minutes a day to playing and the retired or other people with copious amounts of free time to play. Players will have plenty of time to consider moves and counter-moves and the only wrinkle that is presently foreseen is the timezone issue, where you have players who can execute actions during night time for other timezones thus limiting the response times for certain players. We have been tossing around ideas such as standing substitutes and war masters for federations, but nothing is decided yet on whether this issue needs to be addressed or how.
The goals of the alpha and betas tests will preclude a long duration game and thus the pacing will be modified such that alpha and beta games (except for open beta) develop much more quickly and reaction time will be significantly less due to testing constraints.
All of this will be subject to testing and user feedback however.
Later, I will be ready to discuss our plans for how we make use of user feedback and how we will collect it.
á na márië,
gumshoe, out.
FATES should, if our design plays out appropriately, play like a very expansive, very convoluted version of chess. Most of the major players will be federations each vying for territory and influence in the Galactic Council and economic arenas, however there will likely be a whole host of smaller federations and single players who will fill the gaps in between the large factions potentially even serving as strategic buffers between major powers or even as mediators.
From server initialisation until someone wins should take around 6 months to 1 year, although there are parameters in place that can be tweaked to modify the pacing of the game. This should produce a pacing appropriate for both busy people who can only devote a few minutes a day to playing and the retired or other people with copious amounts of free time to play. Players will have plenty of time to consider moves and counter-moves and the only wrinkle that is presently foreseen is the timezone issue, where you have players who can execute actions during night time for other timezones thus limiting the response times for certain players. We have been tossing around ideas such as standing substitutes and war masters for federations, but nothing is decided yet on whether this issue needs to be addressed or how.
The goals of the alpha and betas tests will preclude a long duration game and thus the pacing will be modified such that alpha and beta games (except for open beta) develop much more quickly and reaction time will be significantly less due to testing constraints.
All of this will be subject to testing and user feedback however.
Later, I will be ready to discuss our plans for how we make use of user feedback and how we will collect it.
á na márië,
gumshoe, out.
Subscribe to:
Posts (Atom)