|Epicinium - environmental turn-based strategy [Beta] [DevLog]||Post Reply|
|Feb 2 2018 Anchor|
Hi all! I've been developing this game together with my friend SLiV for the last months. I'm excited to share occasional updates and insight into the development process with you. Epicinium is currently in open beta; download links can be found here on IndieDB or on itch.io.
The game currently features online multiplayer 1v1 and 3- or 4-player free-for-all games, as well as AI opponents and an in-game tutorial. We're actively developing this game, so we try to put out a new version every week or so. Every Saturday we hold an online playtest session starting at 20:00 GMT, which you are of course very welcome to join. We also livestream this event on SLiV's Twitch channel.
Epicinium is a multiplayer strategy game where the players' impact on the environment matters. Combat destroys grass and crops, and trees are trampled as tanks drive towards your opponent to level their cities. Industry accelerates global warming to ludicrous levels, causing more destruction the longer the game goes on. At the end of the game, the winner is scored for how many grass and forest tiles still remain on the map.
How to play
Epicinium is a multiplayer strategy game with simultaneous turns. Each turn consists of a planning phase, where all players decide which orders they want to give their units that turn, followed by an action phase, where players watch as the the orders play out
Units will automatically attack enemy units they encounter; they will also fire back when attacked and attack any unit that moves away from them. Some units have abilities that allow them to bombard tiles, randomly dealing damage to whomever and whatever is present at that time. Anticipating your opponent's orders is key.
Between rounds, the season changes which might bring about new weather effects such as snow, drought or firestorm. At night, buildings can gain power and generate income. Cities only gain power if surrounded by enough grass, forest, water and crops, whereas barracks and industry grow larger when additional cities are placed nearby.
To defeat your opponent, capture or destroy all of their City tiles.
For an idea of what a game of Epicinium looks like, watch the introduction video where SLiV commentates a match of himself taking on the HungryHippo AI:
SLiV and I started development on Epicinium last May. After studying at the University of Amsterdam and working as software developers for a while, we found we both aspired to be full-time video game developers, wanting to combine the logical challenges of coding with our creative impulses. We had several ideas for games, but had to abandon some of them because they proved too ambitious for us at the time (but I'd love to return to them in the future!).
Eventually, we settled on our current idea: a multiplayer turn-based strategy game, inspired by Advance Wars, but with a twist: the war between players impacts the environment. As a consequence, players have to strike a balance between maximum firepower and not destroying the world we live in. After all, is it worth winning a war when you end up conquering nothing but dirt and ash? This inspired our working title, Aftermath.
We built the game in C++ on top of SDL. After working on the engine, game logic and combat system for a few months, SLiV made the initial sprites and I the initial netcode so we had a playable prototype. We held a few alpha playtests with a bunch of friends in the same room, which proved to be very fun (though bug-ridden). In November, we decided to rent a server and start an open beta. This is a multiplayer game after all!
Since then, our development has focused on making the game more accessible, understandable and attractive. Recent additions are an in-game tutorial, gameplay sound, a simplified weather system, 3- and 4-player maps, and loads of bugfixes and balance improvements. At the moment we are working on:
Some points that I think are unique about Epicinium or interesting to fellow developers:
We will regularly post updates here. We're curious what you think! Comments and feedback are very welcome and we will happily answer your questions and go into detail.
We hold weekly online Epicinium playtests on Saturday from 20:00 to 00:00 GMT. The next one will start in 6 hours from posting. It's always a blast, and we're looking for more participants, so I really hope you'll join!
This week, we tried to figure out what's causing the infrequent dropped TCP connections. After a lot of fiddling around with Wireshark and tcpdump, I concluded that the problem lies in the transport layer or deeper. I've contacted our server host to get to the bottom of this. Luckily, the problem doesn't occur that often, but it's annoying when it does, of course.
Meanwhile, work continues on music. I've drafted some compositions for the title screen, but I haven't yet completely captured the right vibe for the game. I hope to have something ready for you to listen to soon.
Following our previous introduction video, we recorded a new gameplay video, where SLiV9 and I try out different strategies against each other. Let us know what you think!
Edited by: UnarmedLad
|Feb 13 2018 Anchor|
In this DevLog, we will tell you about Epicinium version 0.16.0, and give a peek into a feature we're currently working on.
A new version
We released beta version 0.16.0 of Epicinium last week. It includes improvements to make the weather system more fair and fun. Since the previous update, we've simplified the weather system, so that the weather effects now depend on three factors:
All the weather effects encountered in the game depend on these three things. For instance, you will see the speed-reducing Snow on tiles with at least 1 humidity in winter, while tiles with 4 humidity have year-round Snow. Additionally, there's the HP-lowering Frostbite in winter starting at 20% Chaos, the damaging Firestorm in summer at 40% Chaos, the HP-lowering Bonedrought at 60% Chaos, and finally the all-destroying Death at maximum Chaos. Most of these weather effects also grow worse at higher levels of Chaos. Of course, we will keep tweaking and balancing the weather system as we go.
Other important changes include the prevention of a GPU memory leak (remember coding people, if you store sprites and palettes separately on the GPU be sure to also free the palette afterwards, hehe). Also, we added a player list to the UI so you can finally see who you're up against, or get a sneak peak into the players' wallets if you're observing. If you are curious what else is changed, we keep a list of release notes just for that.
We also started recording short featurette videos that each explain one aspect of Epicinium's gameplay. There are two videos as of now, one explaining the basics of the combat system, and the other showcasing Rifleman units.
While we toil through bugs, crashes and disconnects (still in contact with the server hosting company, but it's taking some time to sort out), we are also working on some new gameplay features. One of them I want to talk about for a bit: peacemaking. "What!?", I hear you say, "Peace in a wargame!? Ridiculous!" But that's indeed what we're thinking of.
You see, right now there are two ways a game of Epicinium can end for you: either you lose because all your cities got destroyed or captured and you get a score of 0, or you win because you are the last player remaining and you get a score equal to 100% of the Grass / Forest tiles still left on the map. With the peacemaking feature, two remaining players can, under certain circumstances, negotiate about ending the war early while both get a percentage of the points remaining.
Of course, peace must be hard-fought, so as we have it in mind right now, a player will get the opportunity to make a peace offer when the other player captures one of their cities. (But not their last city, for then they would have lost.) The other player then has one turn to decide to accept or decline this offer. By linking peace offers to the capture of precious cities needed to survive, a power shift needs to occur before the possibility of peace. Hopefully, this will make the possibility of peacemaking exciting and fun, and also discourage match-fixing situations.
For an example of how this might work, imagine Anna playing against Bahram. They've been playing for a while, and Anna has a slight advantage and manages to capture one of Bahram's three cities. Bahram knows this is bad, but he figures he might be able to make a comeback if he started building tanks, since Anna is using mostly riflemen and relies on farms for income. However, he also knows that the battle would probably still take a very long time, his industry and tanks destroying most of what's left of the environment and thereby robbing him of a good score at the end of the game. Therefore, he decides to send a peace offer for 45% percent of the points. Anna is not so sure she can convert her advantage to a victory, so she accepts and the game ends there and then with 68 points left over on the map, of which Anna receives 37 and Bahram 31. If Bahram had decided to continue, there would have been a chance of winning, but with less points, seeing that the entire map would've become unlivable by the end of the war.
This feature will require a lot of testing to make sure it's fun and balanced, so this likely won't be in the next version, but stay tuned and let us know what you think! :-)
Edited by: SLiV9
|Feb 17 2018 Anchor|
Hi folks! We just released version 0.16.1 today, featuring a settings menu and memory usage optimizations.
These past few weeks we've been hard at work to squelch some crashes and disconnects that seem to plague the game at the moment. We've talked with our webhosting provider, and they have moved us to a different setup that will hopefully get rid of the TCP disconnection issues. We've also reduced the RAM usage of the game by roughly 75%, so this should help prevent crashes related to high memory. If you are still crashes or disconnects in version 0.16.1, please let us know!
Lastly, there's another online playtest session later today (20:00 GMT). As our community continues to grow these sessions are getting more and more fun, so be sure to pop by!
|Mar 22 2018 Anchor|
After numerous setbacks and rigorous testing, we finally released Epicinium beta 0.18.0! It features password-protected user accounts, gameplay changes, and RampantRhino, a new AI opponent to play against. RampantRhino is our first AI that utilizes all of the buildings and units (well, nearly - no zeppelins yet). Challenging it should make for some interesting games.
A lot of time was spent to set up the infrastructure for user accounts (MySQL, PHP, Apache, TLS). We feel that having a good accounts system is very important for a multiplayer game. In previous versions, players would pick a username. Behind the scenes, this would generate a "secret" which was used for subsequent logins to the server. It seems easy, but it was a real hassle to use the same username on another installation or machine (you would be informed that the username was already taken, so you'd need to copy the file containing the secret over to the new installation manually).
We've now done this properly: register your account and log in from anywhere using your password. Logging in will generate a session, which is remembered if you enabled "Keep me logged in". As an added bonus, we now have a domain and webpage: epicinium.nl. Check it out! This also paves the way for us to make things like a leaderboard, so Epicinium ratings will mean more and players can flaunt them. We are working on this for the next update. Go ahead and play some games, you might be on it! We'll talk some more about how the ratings work later in this article.
Gameplay changes: Frostbite
Something we continuously work towards, is making sure the environmental mechanics and weather effects are not just there for their own sake, but that they actively influence the player's decision making. If players cannot respond to an effect in a meaningful way because it occurs regardless of their actions, the effect does not really add any value to the gameplay other than aesthetics. A major design goal going forward is to ensure that the weather effects improve the strategy and fun, instead of the game being fun in spite of them.
As an example, in version 0.18.0 we changed Frostbite to only apply to open fields (grass, dirt, desert, crops etcetera) and to deal damage instead of lowering hitpoints. This forces players to make sure their riflemen seek shelter in nearby cities, forests of trenches, whereas tanks can freely go wherever they please. In response, a player could use this knowledge to predict where the enemy units will go and attempt to occupy or bombard those spaces. We hope these changes create more strategic opportunities and make Frostbite more interesting to interact with overall.
Because our game changes almost every week and our playerbase is still growing, we wanted a rating system that is simple and also quite loose; a player should be able to win just one or two games and immediately see a change in their rating. Also, the rating system must reflect not just whether they won or lost, but also the score the player obtains after every match. The winner of a match is awarded between 0 and 100 points based on how well they did in keeping the map intact, whereas defeated players always get 0 points. As we both studied mathematics before diving into game development, it would be tempting to spend three months coming up with a mathematically ideal system, but we knew that we needed something that was easy to implement and easy to iterate on.
The easiest rating system would be to average the scores of all games played so far. This has an immediate downside: if a player loses the first ten games they play, their rating will forever be dragged down. Even worse, after playing a hundred games each subsequent game could alter their rating by at most 1%, making real progression impossible.
To resolve this problem, we could take a running average of the last ten games played. This would be sufficiently loose: even if a player had lost a hundred games, winning ten games in a row would skyrocket their rating. However this system could end up stifling players who keep track of their wins and losses. Suppose in the last ten games a player played they received 100, 0, 60, 0, 0, 0, 20, 40, 80 and 0 points respectively, for an average of 30. Winning a game with a score of 60 should increase their rating, but their last-10 average would drop to 26 (note that the corresponding line actually drops in the following image, despite the win).
And there lies the crux: we want a simple rating system that increases when you score higher than your current rating and decreases otherwise. We can achieve this by having an iterated function whose fixed point is your average score. We settled upon: R' = 0.9 * R + 0.1 * S, i.e. your next rating is 90% of your current rating and 10% of the score you obtained at the end of the match. If your current rating is 30 and you score 60 points, your next rating will be 30 - 3 + 6 = 33. This gives the players that want to climb a clear objective during each game: obtain a score that is higher than your current average.
There are still some issues with this system, and we will likely change it in the future once we reach a larger playerbase. For matchmaking purposes, we might switch to a variant of the ELO rating system, but we would first need to come up with a way of incorporating the score. So we might end up quenching our mathematical thirst after all...
|Apr 16 2018 Anchor|
During our months of developing Epicinium, we've noticed that we need to continually strike a balance between defying and meeting expectations. Games are an interactive medium. If a game goes against players' expectations at every turn, it becomes inaccessible: players will just become frustrated and stop playing. Especially in a multiplayer-focused game where you're trying to build a community, that's bad. On the other hand, if there's a strong vision behind the game, fulfilling all of the players' expectations will quickly cause your original vision to become buried, and you might end up with Clash of Whatever, part SomeRomanNumeral. We're not sure we've been entirely successful at striking that balance until now - we probably tend to err towards inaccessibility -, but we will illustrate this balance by giving some examples of common player feedback we've gotten, and how we've handled them.
No unit merging
A very common reaction from players who are playing the tutorial is "why can't you merge units?". In Epicinium, players control units on a grid-based map, which consist of one or more figures. You can have a Rifleman unit with three figures, or a triple Rifleman, which might become a double Rifleman if one of the figures is killed in combat. Only one (ground) unit may occupy a single tile at a time. People have the expectation that you can merge these units, for example by moving a unit consisting of one lone Rifleman into a tile occupied by a double Rifleman, thereby combining to a triple Rifleman. This expectation is very natural, and stems from people's knowledge of how in real life, people can combine to form different groups, and perhaps from playing other strategy games where you can merge squads. However, if a player tries this in Epicinium, they are disappointed: the lone Rifleman will promptly stop moving one tile before reaching the other unit. Sorry!
The reason we haven't implemented unit merging originates in how we designed our combat system. A triple Rifleman is much, much stronger than a single Rifleman, definitely more than three times as strong. They have more firepower (shooting three times in one encounter rather than once makes all the difference in a combat system without health bars), and higher survivability (incoming attacks are spread out among the figures, resulting in a much higher chance that none of the figures dies). Triple Rifleman units are basically a reward for the player's patience and endurance; they've managed to grow a City to three power, letting it survive three consecutive nights while resisting the temptation to utilize them for anything else that costs power. By contrast, a single Rifleman is only good for picking off straggler Settlers and doesn't stand a chance when fighting larger forces. Allowing the player to create a triple Rifleman by merging would allow them to create a very strong unit very early in the game, throwing off the investment-reward balance we had intended.
In this case we feel that in order to keep our vision of the game alive, we need to defy this particular player expectation. Nonetheless, it is very useful for us to learn that this expectation exists. Maybe it's a good idea to give this mechanic a try anyway. Maybe it's a design choice stemming from assumptions we had in the beginning that no longer apply today, and it's perfectly possible to implement merging and re-balance the game with some tweaks in other areas. At the same time, just because players expect it doesn't always entail that we should do it. But in that case, at least, we need to do something to address the expectation; explicitly mention the impossibility of merging early in the game, visually subvert the reason people make the assumption in the first place (as Advance Wars does, where squads of however many soldiers are represented on the map by a sprite of a single soldier), or have an in-game logic reason why merging is not allowed.
Selecting units and tiles
An example of where we did see the "errors of our ways", thanks to player feedback, is our selection mechanic. In Epicinium, a maximum of three selectable things can be on the same tile at once: a ground unit, an air unit and buildings. We used to have a system where, wanting to select anything, you would have to left-click anywhere on the tile, a selection menu would pop up and then you would have to click on the corresponding panel. We figured the player would have to do this even when there was only one thing to select, for else the selection menu would come as a surprise whenever it would inevitably come raging into the china shop another time. You would always have to go through this menu before giving any order, which was (and still is) performed though another menu, the order menu, which is brought up by right-clicking the selected unit or building. We quickly found out that players were utterly confused by this system. Still figuring out the controls and already a bit disconcerted by when to left- or right-click, they now had to keep apart two similar-looking menus produced by opposing mouse buttons before even able to give an order, the most basic mechanic in the game! We decided to retire this selection system in favour of the more intuitive figure-based ("click-on-what-you-want-to-select") selection system. (The original system can still be found under Selection Mode: Context Menu in the settings, in case you want to try it out.)
Displaying unit stats
One more example is the tile/unit stat boxes that now grace the left side of the screen. We had long held on to a design philosophy where all the necessary information could be gathered by the player by observing the game world. In fancy terms, this is called "diegetic UI". For example, the health and strength of a unit can be learned by counting its figures, the power of a City by counting its lit-up buildings, thus eliminating the need for extra, space-invading UI elements. However, we recently concluded that pursuing diegetic UI exclusively is just not desirable for a pixel-art strategy game. Eventually we would run out of ways to display new information. A unit's movement speed; the color of the figures' boots? The number of firing volleys in one encounter; the number of medals of their uniform? It would quickly become very cluttered visually, and players wouldn't know where to look for these things anyway. A player who filled in our feedback form rightfully claimed that "having information is key in any strategy". He desired access to all statistical details in the game. We agreed and added the stat boxes.
Sometimes it is not a matter of expectation versus vision, but just a matter of time. One feature that we have had requested multiple times is the ability to rearrange the orders on the order list, and to quickly revoke orders or stop old orders. This is something we intended to add since the game's original conception, but there was always something else a little higher on the priority list. Additionally, we feared that it would take a lot of engineering work to rewrite our delicate little interface engine to be able to handle elements being dragged around at the whims of The Player. We felt that all that work might not be worth it if the player can achieve the same goal without it; orders could already be rearranged by assigning them again in a different sequence. This mentality changed when we realized not enough players were actively thinking about the sequence in which they gave their orders; a lot of players were not even aware of its significance. That's why you can now drag around orders at will. Hooray!
Most importantly, you can now rearrange orders in the new order list; that is, within the list of new orders that you have given in the current planning phase. You are not able to rearrange old orders, but you can drag old orders to the new order list to make sure they are executed after other ones. We also added little blue buttons; clicking the box-shaped button on an old order issues an Stop order that negates it, whereas clicking the x-shaped button on a new order removes it from the order list.
To help new players understand the importance of the order list, we have also disabled fog of war by default for human players. This makes it clear that the players alternate while executing their orders. It also makes it easier to see enemy attacks coming and respond in time, which might require rearranging some orders. AI opponents do not have global vision by default, and for competitive matches the fog of war can be reenabled.
We do worry that the UI has become somewhat too large over time - both in on-screen size and in complexity -, so we may be making further changes in the future. Let us know what you think.
|May 26 2018 Anchor|
This week we released version 0.23.0, which came with some big gameplay changes, including a new unit: the Militia. In this devlog we want to highlight some of the recent changes and our rationale behind them. If you haven't already, you can try out these changes by downloading the latest version from our main page.
In order to keep things exciting, it is important for both players to have a fair chance of winning throughout the match. We found that having one of your City tiles captured by an enemy Rifleman unit was a little bit too crippling. Not only has your opponent achieved 50% of their goal (to capture or destroy both of your City tiles), you also lose a source of income and a means of producing Rifleman units. Conversely your opponent gains extra income and production, and the natural protection that the City provides helps them keep all of these bonuses while you struggle to reclaim your City. In order to alleviate this, we changed the win condition from capturing your opponent's City tiles to simply occupying both City tiles at the same time. Although easier to achieve, having one of your City tiles occupied is slightly less damning than having one captured, because you only need to get rid of the occupying unit in order to get your City tile fully operational again. To make early rushes a little bit weaker, the Rifleman units that you start with have been replaced with a new Militia unit.
The Militia unit is similar to the Rifleman unit, but they cannot capture tiles and each little figure only has 1 hitpoint. This means large Militia units are still very good at attacking, but suffer considerably more losses when attacked in retaliation attacks or attacks of opportunity. The reduced hitpoints also makes Militia units that are occupying your City tiles a little easier to remove. Militia units can also have up to 5 figures. They take the place of Rifleman units and can be produced at City tiles or Farm tiles; the Rifleman unit has been moved to the Barracks and its cost has been halved. Rifleman units can still capture tiles as usual, so they are now a more tactical unit to be used in conjunction with Gunner or Sapper units.
We also made some changes to make defending more viable. As stated above, one of the things players had troubles with was prevent enemy units from slipping past their defenses. One of the reasons for this was that if you kept a unit on one of your own tiles, the production of units on that tile would be blocked. When producing a unit at a tile, you can now select where you want the unit to go after it is produced; it can stay on the tile, or move to an adjacent tile. This change allows you to keep a defensive unit inside a City tile to protect it, while still being able to produce units at that tile.
Another change concerns the interaction between the Trenches tile and bypass attacks. A bypass attack happens when an attacking unit moves past another friendly unit to attack and then moves back afterwards. If the target of a bypass attack survives, it fires back at the attacking unit, but the bypassed unit can also take some hits. Trenches are usually used to protect your Gunner or Sapper units, but when an entrenched unit was part of a bypass attack, the Trenches used to offer no protection, leaving the entrenched unit very vulnerable. Since version 0.22.0, entrenched units no longer take part in these bypass attacks, leaving the attacking unit to fend for itself.
We have also streamlined the in-game UI a bit, because we felt it had become too large. Although we want players to have access to all the information they need, too much information can detract from the overall understanding of the game. Therefore we looked at what information is really useful during gameplay and what could be better displayed in a different way.
For instance, we removed the "chaometer" that gave a very rough estimation of how far global warming was advancing, and replaced it with newspaper announcements that appear every time global warming reaches a next stage. As a bonus, the newspaper's headlines warn about the new hazards to expect, which means we don't have to front load all of that information in the tutorial or a UI element.
We are currently running our first Epicinium tournament over on our Discord server. As we release new versions between rounds, the players are continuously helping us improve the balance of our game, both by giving feedback and simply by playing the game in a more competitive setting. One of the design issues we will be trying to tackle next is making sure rush tactics have enough downside to give the defending player a chance to come back after thwarting the first wave of attacks. Expect more on that in the coming weeks!
Edited by: SLiV9
|Jun 1 2018 Anchor|
We released beta version 0.24.0 today to bring some balance changes that we felt were needed after the gameplay changes in version 0.23.0.
When we replaced the Rifleman unit with the Militia as the standard infantry that could be made at City tiles, we had hoped this would make infantry rushes a bit weaker. By also making Militia cheaper and having their maximum size be 5, we instead made these rushes more oppressive, as very large Militia units are cheap, fast and deadly. Even worse, defending your City tiles also become more difficult because the lower hitpoints of the Militia meant that they profited less from the City's defense bonus.
Therefore, City tiles now produce Rifleman units once again. They cost 10, which is a bit more expensive than when produced at the Barracks. You still start the game with some Militia units and further Militia units can be produced at the Farm. This allows you to build a Rifleman unit at your City to defend against the starting Militia of your opponent.
Rifleman units are now intended as a defensive unit in the early game, but their Capture ability still makes them very powerful in the mid and late game. To prevent them from being too oppressive too soon, we reduced the movement speed of Rifleman units to 2, down from 3. Hopefully this will allow players to better defend against early Militia rushes, without enabling Rifleman rushes. Of course, we'll keep an eye on how this plays out.
We also fixed some bugs and made some other changes; the full release notes can be found here.
|Jul 11 2018 Anchor|
After being occupied for a couple of weeks by the founding of our cooperative (A Bunch of Hacks), we have turned our focus back to improving Epicinium and recently we released beta version 0.25.0. This update introduces weekly challenges, new dust and grass particles, and an easier way to provide feedback directly from within the game to our STOMT page.
Starting this week, a new challenge will appear in the game every one or two weeks. Completing challenges awards you with stars, and you can play a challenge again to try to get a higher score; your best attempt counts. The stars you accumulate over the weeks are added up and displayed next to your name in the multiplayer menu. Challenges are played on special maps against a special AI. Some challenges may have different starting units or rulesets as well. A mission briefing appears at the start of the challenge to tell you what you need to do to earn stars.
For this first challenge, the objective is the same as in any other game of Epicinium: occupy, capture or destroy all enemy City tiles and try to keep as many Grass and Forest tiles intact to get a higher score. If you score at least 1 point at the end of this challenge, you will get 1 star. Scoring at least 25 points gets you 2 stars and scoring at least 40 points gets you 3 star. Instead of starting with two City tiles, you start with three Rifleman units and a Farm tile. This challenge is played on a very small map, so expect global warming to grow out of control really fast. Getting all three stars is meant to be very difficult (it's a challenge after all), but definitely possible.
Let us know what you think, either by commenting here, dropping by our Discord or from within the game using the new feedback form.
Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.