← Retour au catalogue

Esprit Jeu

Aether Summon

Par Micael Nussbamer

Soutenir la campagne

Statut actuel

Campagne en cours Temps restant : 2 jours et 9 h (fin le 31/10/2026)

Fonds récoltés : 15 €

Deck Building Fantasie Jeux de cartes Stratégie

Ajouter aux favoris Je me tâte J'ai pledgé

Aether Summon the Game

The idea for Aether Summon was born more than 5 years ago from the desire of having a TCG (Trading Card Game) like game, with the same sort of turn-based gameplay but without the randomness inherent to all existing ones, that make them be, effectively, hidden down below the several layers of keywords and appearance, a multi-layered poker game. Check it out by visiting https://aethersummon.com and clicking "TRY IT!"

(air, earth, fire, light, void, and water fluxes - the armillary spheres that channel the Aether domains running through Alastria)

Aether Summon went through several developments, initially it was even called Aether Wars, and while the goal of achieving a game without the type of randomness associated with draws and shuffling was managed, other game design issues started popping up in my mind and I took the chance to develop an actual engine and ruleset that further rewarded mastery over randomness, tactical thinking over "I win" items and specifically built to be played solely online, in a browser, desktop and mobile. That in itself, that it was entirely digital, made me look into different ways to approach such a task and contemplate new ideas. You can try it live at https://aethersummon.com

I've made a video detailing the contents of what is to be open sourced showing the game running, the docker compose files used to mimic a production environment locally, the terraform architecture for AWS, and showcasing the game, drafts, the plans, possible roadmap and other details. Check it out if you're interested in knowing more about what you'll be funding to be released under an AGPL license (everything except the infrastructure as code - docker compose, terraform, packer - which will be licensed as MIT). The game front-end is already fully responsive, allowing to do everything, including drafts, codex editing and duels in mobile or tablet viewports (or exceedingly wide viewports) besides the normal desktop experience.

The major goal of Aether Summon's game design was to remove randomness - there's a whole section about it further below, but there were other smaller objectives:

Solving matches in a single game

We can do away with multiple matches to decide a winner (or long gauntlets) because there's no draw nor randomness, so we don't need to worry about "balancing" bad luck.

This makes it so that finding the "proper" game winner can only extend to a maximum of 50 minutes, and only in case both players completely exhaust their timers (25min each) otherwise it will be usually less.

To offer some more strategic approaches to a single game system we created the "RECALL" mechanic, which uses a set of 7 scrolls the player chooses when creating their codex that isn't part of their initial playable scrolls. During a duel, at specific times of the game, in a symmetrical way for both players, they can retrieve scrolls from those 7 they chose and bring them into play. Basically creating a "bench" of scrolls that can be brought in against specific threats or game plans, furthering the strategic part of codex building. During "Recall" any flux is retrievable too, which allows to do some interesting deck building choices, since you can perhaps include scrolls that cost or use domains that you don't use otherwise and then on one of the recall phases you retrieve the flux needed to cast/activate that ability.

Rules, Gameplay & Scroll designs without rarity levels

There's no intrinsic rarity to any of the items in Aether Summon. While rarity is a nice incentive for people to spend money, or time, on the game acquiring items, it introduces a distortion to game design. If you assign rarities to scrolls now those scrolls have to have power levels that somehow walk hand in hand with their intrinsic rarity - what we see in other games is that for making them justifiable they usually pack in a single card several abilities and a disparate power level compared to the remaining less rare items.

It makes sense, in a way, it's a reasonable way of incentivising spending either, or both, time or money and rewarding that. At the same time, wouldn't a natural rarity emerge if all items have the same rarity? By this I mean, if the pool of choosable items is 20 and a "tome", or item pack, has 20 items, if we prevent repeated items when creating the contents of a tome, every single item of these 20 has a 100% chance of being included. As we add scrolls to the pool, lets say we add a new batch of 60 scrolls, now when opening a tome each one of these now 80 possible scrolls has instead a chance of 25%. 80 is still a pretty low number of items if we consider a fully fledged game, where it's not unreasonable to reach in the order of thousands of different items, specially if the game is basically playing those items. If the game reaches a thousand playable scrolls, it would mean a scroll has roughly 0.02% chance of being in a tome that is opened.

If now we add to that the fact that scrolls will naturally develop a "value" due to them being used or not, at certain times, and according to the meta, we should see a natural value emerging for those scrolls, since the most competitive forms of game-play require you to have somehow acquired those scrolls to play them, if at that time there's only a 0.02% chance of opening any particular scroll, those that are being played with greater success will probably be seen as more valuable and people will be trying to get them - opening, trading, or buying and by doing so increasing the "demand" for those being used across more "decks", which should drive their value up - but since new scrolls can be added arbitrarily the meta-game can change and so these valuations can also change.

The game

A game is a duel between two players, each one starting the game with a deck of 50 scrolls plus an additional 7 scroll bench that they can access at specific times during the game. Players don't know the scrolls of each other and they have access to all the 50 scrolls that make up their deck at any time during the game.

The game is played in turns with a priority scheme similar to many TCGs, where a player executes an action and the other player has a chance to react to it or pass. To summon scrolls players have to gather Aether, a type of energy that powers magic in the world of Alastria and is divided in 6 major domains. Air, Earth, Fire, Light, Void and Water. They do this by playing contraptions called "aether fluxes", specially powerful armillary spheres that allow channeling these energies into usable magic. Each scroll besides fluxes has a summoning cost that represents how much energy it requires and can be of different types, creatures, nimbles, conjurations or hexes. Some of these scrolls start as portals instead of immediately entering the game and have an associated number of turns before materializing.

(duel view, summoning creature confirmation)

Creatures are used to strike your opponent and guard yourself and can have different abilities: impetuous, berserk, flying or mastery. They can also be in different states: exhaust, paralysed, materializing, [in] portal or damaged. They can also have modifiers that change their original stats and actionable abilities called GIFTS. Additionally they can have maintenance costs. Every creature additionally has an "healing" ability that determines how many damage points they can "heal" per turn. The types of scrolls are divided into 2 different categories, materializations - scrolls that stay in game - and spells - scrolls that execute their effect and are placed in the players tomb. Certain effects can further remove a scroll by "forsaking" it into a special area.

A turn is divided into different phases: start phase, main phase, battle (strike, guard and clash), post phase and end phase. Every 3 turns a special phase is simultaneously given to both players, the Recall phase where players can retrieve 1 scroll from their "bench", or any aether flux they might want. Each player starts the game with 25 life points and the game only ends when a player's life total is reduced to 0 or less, or a player exhausts their 25 min total clock time. Players can play an aether flux per turn, on any turn, greatly speeding up the resource gathering part of the game.

(duel view)

The types of scrolls also dictate when they can be played:

Nimble spells - can be played anytime you have the necessary resources to pay their costs, valid targets if needed and you're the active player
Creatures / Conjuration / Hexes - can be played anytime you're in your "Main" or "Post" phases, have the necessary resources to pay their costs, valid targets if needed and you're the active player
Fluxes - can be played once per turn (both in yours and your opponent's) whenever you're the active player
Ambush Spells - *future keyword yet to be implemented - can be played in their normal situations or additionally during the "Clash" subphase of the battle phase
Scrolls GIFT abilities - when omitted they can be activated when in play and you have the necessary resources to pay their costs, valid targets if needed and you're the active player; in some situations they will only be actionable when they're in specific game areas (tome, tomb, forsaken) or when certain conditions are met

Solving the game

Obviously if the pool of scrolls doesn't expand then at some point it's probably safe to say that an AI agent/bot could solve the game, but if the pool is expanded regularly as it was intended from the start I believe the game will always be favouring human players capable of mastering it and dedicating effort to study and breaking the meta-game. The mixture of abilities, possible sequencing, interaction of different effects and depth a single game can create - after all it's 50 scrolls on each side, plus 7 recall scrolls, may prove too much for current models or bot strategies. Chess is pretty much solved through Stockfish and other models - even though a chess game also has a giant possibility space it's comparatively very shallow to what a normal TCG can create. I believe that this is a very serious advantage as it can provide a natural protection for human players that decide mastering the game - the fact that there's hidden information a bot can't access nor calculate, contrary to chess where there's perfect information, or even games such as FPS or RTS where though you don't always have perfect information, it's derivable, that is, calculable, from the current game state, plus there's no real advantage for being fast in clicking or selecting things which are things bots can usually also leverage in their favour - when paired with the no randomness aspect of the gameplay makes it in my eyes the perfect TCG for this era.

No Randomness, Drawing, Shuffling

Getting rid of randomness while keeping the game play interesting

While "randomness" is part of the charm of these sort of games, and part of its addictiveness, due to the dopamine hits, ultimately I believe you don't need it to be part of the game mechanics itself, because there's inherent randomness in playing any game against an unknown list of scrolls. If the list of possible scrolls to choose from is big enough, then randomness emerges organically out of it, you don't need to make the "actual" game be random or dominated by random events. The randomness that is interesting to me is that, a random puzzle of items that you have to figure out as you go and use your strategy and game knowledge to top your opponent's. When draw randomness is involved the games become dominated by luck. If you draw a sequence of cards that leads to a powerful start there's not much that your opponent can do - most of these games even have these archetypes, where decks are built based on having the potential to do the equivalent to "full-house/flush" draws and players bank on straight probabilities.

There's also obviously an amount of knowledge needed to make a decent deck with high-probability of gold fishing but ultimately the games are basically poker with extra steps, specially because you don't need to gold-fish if your opponent just has plain bad luck. On the other hand, if you can have 1000 options for scrolls to play and a deck can only have up to 50 scrolls, then there's randomness just by playing against an unknown deck (non perfect-information scenarios), and as more scrolls are added to the pool the more uncertainty there is and more this "organic" randomness is present.

In a way this game, ruleset and concepts try to find a middle ground between the static nature of chess and the randomness of card games.

So, no drawing steps, no drawing scrolls. The codex, also called tome or grimoire when referring to the initial list of 50 playable scrolls that make up a codex, is always accessible to both players but no one knows the scrolls each other has, this means there's always a lot of unknown unknowns, even though randomness in default game-play has been removed, it's not a perfect information game like chess, even when a known list is being played, just a couple of different scrolls, because they're always accessible, is, or can be, a completely different matchup.

(library codex editor view)

Making this work without randomness is more problematic if we would use the same resource systems as other games, where both players incrementally increase their "base resource" (mana, energy, magic points, power points, etc) on their own turns alone. It's kinda a given, perhaps because it's a natural way of balancing random draw games, that to balance out starting first, which is the most advantageous position you can hope for, you give an additional "bonus" to the non-starting player (this is verifiable because 100% of the people choose to start first, even though theoretically resource advantage is the most important aspect of these games, so this must mean that if they forego one draw to start first, that starting first is more valuable than drawing a resource).

But... if we remove draws from the game we have a worse problem because starting first is not handicapped by the opponent getting one more resource, so what is the solution? The solution is simple, like almost every time, what if we allow players to play their resources on each other's turns as well? Such a simple concept unlocked completely this game because now the advantage of the position is being the active turn player. To illustrate this, lets say you start the game, you play your first flux (resource), because it's a flux you keep priority and now you may play a spell or pass - either choice gives priority to your opponent. Now your opponent can actually also play a flux, which doesn't change priority, and now he also has a resource he can use to counter act.

This is already more balanced, even though the initial player has a certain advantage, he can be the first to play creatures, hexes, or conjurations, it's more balanced because now both players play at the same resource level independently of who started.

Nonetheless, a more interesting thing happens as well when we switch turns. Now the opponent will be the one with priority and playing his flux will put him at being the first to be able to play creatures, hexes or conjurations with 2 total cost.

When we switch turns again, now is the original player that gets the same but for 3, and then the opponent for 4, and so on. The advantage swings naturally with being the active player, which is kinda of how I always imagined a balanced game would look like.

Lastly, there's another effect that wasn't being pursued but ended up being a big upside of this approach - games are now much faster to develop. The starting player on his 4th turn (7th game/global turn) has access to 7 resources, the same as his opponent whereas in a normal symmetrical turn by turn game (all the TCGs I know of) he would be playing his 4th resource and the opponent would have 3. Obviously, since playing scrolls and activating abilities is what the game is about and requires resources this makes the games faster to play.

One interesting aspect of how I arrived at this design was that it was almost by pure chance. This final version can be considered, depending on how I count them, the 4th or 5th version of this game. The very first one was done in 2017. The objective from the beginning was to remove draws and shuffles but it took a while (because I was working regular web-dev jobs/gigs to pay bills) before I found this system and it was during a re-write into a new version, around the beginning of 2019 , that the solution appeared.

As I was re-writing the engine to a more robust version I would convert some parts of the old code into the new one. The rules for playing fluxes was in a different file and as I went to test if the conversion worked as expected (it was all manually tested at the time, I didn't have a proper test suite) I went to make sure that I could only play a flux on my active turn, but since the rule wasn't yet converted and included in the new codebase I was able to play the flux. Because there were a bunch more things I needed to test I kept going through the turns - specially because it also sped up playing with both "players" - to make sure those other things were properly converted. By the end of a few runs I came to the conclusion that it could be the answer to the lack of drawing steps - and that's how that idea became an important milestone on the development of the game, kind of a "this actually solves my biggest game-play issue with the game I intend to write".

(library codex editor - partial mobile view)

Randomness effects

After all this talk about how we don't want randomness to dictate the game you might be surprised to know that there are in fact random effects in the game. While this might look contradictory there's a reason why they make sense, and while the mechanism exists it's also not guaranteed that it's going to be explored further in new developments.

(scroll viewer - Void Stinger a creature with a GIFT that employs randomness)

The randomness that you might find in scroll effects is mostly related with the Void domain. We wanted it to be possible to attack the "codex", or "tome" of scrolls of an opponent itself. Not a particular scroll only, or by effects of naming. At the same time we also didn't want to break the imperfect information nature of the game, so what we ended up doing was having scrolls and effects that target the opponent's tome scrolls in a random way, to both allow attacking it but not automatically making its real contents known nor having to waste time memorising all possible scrolls and meta-game.

To see the difference of the effects, while it's not guaranteed that it won't ever create advantageous random choices, imagine a few turns into the game, you have 35 scrolls and one or two or even three get randomly removed, you still have 32 scrolls remaining. On regular card games, usually hands cap at 7 but some much less, so if I hit 1, 2 or 3 cards, suddenly it might just end the game. Like you have 5 cards after 2 turns, including one that is the reason you kept the original hand, and the other player plays something that targets one random card from yours. If it hits the one that was the reason you kept usually there's not much recourse. This mechanism is well understood and plays according to the general feeling of these games but the magnitude of the effect depends heavily on the type of game - in Aether Summon we believe that it will work just fine.

(json scroll definitions example on the left and programmatic unit tests for them on the right)

Chaos Brawls (Drafts)

Besides plain duels, where users come in with a pre-made deck of scrolls, players can also engage in drafts, called "Chaos Brawls", in which 8 players each bring 3 tomes (packs of 20 random scrolls) and take turns picking scrolls between them and passing the tomes until all 3 are opened and picked, leaving each player with 60 final scrolls. There's no dead scrolls, filler or fluxes in these tomes, just playable ones.

(chaos brawl draft view)

Randomness in Chaos Brawl Drafts

While the normal mode of play completely lacks randomness elements in the basic game-mechanics Chaos Brawls thrives on it. Nonetheless it's a different kind of randomness. As the theory of Chaos would put it, a slight variance in the initial parameters can lead to a drastically different outcome down the line. In Chaos Brawls Drafts (CBDs) you, and every other player, start from a random tome of scrolls and pick one scroll at a time, after which you pass the tome from which you picked your choice and receive one from another player and repeat this until you all picked 60 total scrolls, opening each 3 tomes.

While this is random and in fact, there is luck involved in what a player can open, a pod is made of 8 players, so you'll see at least 12 scrolls from the furthest initial player from you. The tomes are also balanced across domains and you don't have that many slack picks, which means, that naturally, finding the right spot on the table or when to force your choices is important. Each player should be able to find 3, somewhat open, domains to settle, unless they go down the wrong path during the picks. Besides this, and perhaps more importantly, this randomness is only related to what you open during the draft - the following games that you play with these decks will still not be random/draw/shuffle based - and if you read the "table" correctly you should find even during the draft an advantageous position.

In a pod there should be a total of around 60 scrolls of each domain (360 total single domain scrolls), plus anywhere from 30 to 90 multi-domain scrolls and 48 non-domain scrolls. All playable scrolls, no fluxes, so if we assume we need around 43 minimum scrolls for a codex, assuming 7 fluxes and excluding recall that can be any scroll, if each player gets 20 scrolls of each of 3 domains they'll have enough playables (even for recall). These percentages can also be changed in the algorithm that is responsible for randomising the contents of a tome upon "opening".

So while there's randomness, we think it's the sort of good randomness, the one that makes the puzzles more interesting and keeps them fresh while not benefitting any player significantly.

(duel partial mobile view)

Stretch Goals

Tournament scheduler (stretch goal)

The community is probably the most apt participant to decide what types of tournaments and game-play they want to pursue and because we believe in providing tools for that, the last part of the Aether Summon universe, and again a differentiating factor, is the tournament scheduler. Instead of only offering basic queues and matches, we will offer players the opportunity to set up their own tournaments and gauntlets. A tournament can be as small as a single match elimination between only two players and go up to hundreds of players spread between point based rounds qualifying to a chaos brawl top 8. Tournaments have a small opening fee that is charged to the organizer, and the organizer will be able to set prize pools, fees, style of rounds (single elimination, round qualifier for top 8/16/x, etc), restrictions and so on.

The idea is players will be able to create the type of experience they want. Want a restricted scroll list chaos brawl draft with multiple pods, where players actually play against the players in their draft table and then try to qualify in the two top spots of each table for the tournament top 8 finals? Go ahead. Want it to start at 00:20 UTM? 5 minute breaks between rounds, 160 players, automatic rounds, prize pool distributed incrementally to the top 80 players? Sure. Want to split qualifiers and finals into two days? There you go. Want it to be playground so anyone can use any scroll? No problem.

Of course this doesn't mean that there won't be official tournaments, simply that there won't be anything different that an administrator will be able to do in them, other than perhaps restrict it to certain players (like a ELO ranking masters tournament) or connect them to some other in-game stat that might be relevant for players. In terms of structure and options available a player will be able to start their own tournaments with the same structure if they so wish. The reason for this is simple, simple things, like a part of a community being from somewhere and having a timezone that is different and just want to have a sunday tournament after lunch. But if tournaments can only be set by "us", then this would be much harder to pull off, and probably wouldn't unless there was a big community to justify it. If players can solve this they will and, perhaps, better than a dedicated team of persons thinking about it from a completely different perspective - simply because they wouldn't be solving for the same type of concerns.

(tournaments schemas and user scrolls schemas, scrolls allow multidimensional locks already aiming for an advanced user marketplace)

Marketplace (stretch goal)

The natural value and probability of opening a certain scroll - from having an ever expanding collection of scrolls - and the intersection with the emergent meta-game is what makes this other objective - creating an advanced marketplace where players can sell, buy and borrow scrolls - a stretch goal. In a game were we tried to remove the game-play randomness we think this will lend itself very well as a way of players to trade the results of their winnings, in case they prefer that, or simply to have other ways of filling their collections.

The marketplace aims to put in the hands of the players, or community at large, those that would like to invest in the game or even trade inside the platform, the power to dictate the value of the items. Since there's a fully unblocked sandbox like mode where you can play with any existing scroll (playground) we don't feel that having a marktplace is problematic. Players can always choose to play the playground versions of events, matches and chaos brawl, that are either completely free or significantly cheaper than their other versions.

Roadmap

(landing page, when you're signed in)

Roadmap (in no particular order):

Adapt the existing deployment strategies to single VPS with a SQLite database
Introduce the "Ambush" ability/keyword, so creatures can be played as if they were nimble spells during the clash sub-phase of the battle phase and opening up more strategies for the combat phases
Improve the "codex" (deck) builder with more intuitive graphs and visual organisation to understand the codex contents (casting curve, division by types of scrolls, etc...)
Better scroll searching (it has simple text based search based on Regexes - since it runs on the client front-end) but improve it beyond by domain/type to make it easier to find the types of spells you need for completing the build you want, or researching options
Implement the ELO system using the existing ratings table and allow individual duels in the lobby to be opened with elo matching as an option
Additional scrolls (there's more than 1 thousand images ready to become actual scrolls)
Develop the lore of Aether Summon - there's a basic storyline that explains not only Alastria but also how summoners end there battling each other, how the domains came into being and what the Aether Fluxes are and why they work - there's still an enormous untapped potential in developing a coherent storyline for it
Tournament Scheduler
Marketplace
Formalize the websocket interface and add plain html endpoints w/ long-polling to the game, so that additional front-end clients (written in different languages) can be easily developed

(warroom lobby mobile view)

Thanks for reading.

This is a sum up of the philosophy behind Aether Summon. There's other details, again simple things, like creatures healing discrete damage points instead of in totality, antecipating creatures that have very high guard points, but because of the nature of the damage/healing system won't become "I Win" items, since they can be taken care of with plain strategical play and can't simply mow through the game relying on their oversized stats. Lots of small decisions like these were made in different parts, abilities, rules, overall game design so that cool, interesting unique effects, scrolls, can be created without subverting the game-play.

Sample code

If you're interested in seeing some real code I've wrote a blog post a few months ago about the architecture of the bot drafts. It's a totally contained example, slightly trimmed down and adapted, that you can run it by yourself if you want and show cases the state machine responsible for the drafts.

https://micaelnussbaumer.com/posts/creating-card-draft-bot-elixir/#before-bot-draft

Art & AI Usage

Initially I used paid for illustrations done by human artists but the costs of doing such rapidly grew over my financial means since the game was in development and was entirely developed and funded by myself. As an example for about 80 scroll images I payed more than $3k dollars (through upwork) in 2019.

It was also very difficult to find artists, at rates that I could support, that shared the same fantasy themes I enjoyed and thought appropriate for the game, while willing to bring forth that vision. At some point I tried AI generation and managed to create with it hundreds of images that were in my view very satisfactory. Yes, many problems getting accurate images too, from too many to too few fingers, limbs in awkward positions, wardrobe and anatomic malfunctions and so on but ultimately, due to their costs I was able to generate enough images - many of which are still to be incorporated into the game as new scrolls - in the styles, colour schemes, and flavours I wanted to to populate the Aether Summon universe.

I replaced many of those initially paid for images with AI Generated ones but some were still kept. In the repository that is going to be open-sourced those images (as I hold a license to use them as I please in the game) are part of the repository as well, and they're identifiable by their scroll-definitions. Scrolls that use human-made images will have an "author" key in their json definition that includes the name and a link to the author's page (when they provided it, some didn't). Because all image assets for the scrolls are easily changeable (just replace the current versions with a same named file as the scroll it refers to) you can also change any and all of those images if you deem appropriate. For instance the scroll flux images (not the icons) were all made by an artist with whom at the time I collaborated for a big chunk of the assets.

For the human-made art still present keep in mind that unfair usage, or usage outside of the game is not permissible.

The code itself was all human written, although I don't have a problem with AI generated code when properly supervised. In fact, once the repository is public source I won't have a problem in directing some agents to try and help evolving it - I think that the fact that the code itself makes use of properly typed schemas, is abstracted in useful ways, has plenty of examples, a comprehensive test-suite, along with the way the engine itself is written will make working with Agents on the code base a smooth process but until then - and for the foundational aspects of the game - I prefer(ed) to write myself the code.

Copyright & Project Licensing

AGPL (GNU Affero General Public License v3.0) https://choosealicense.com/licenses/agpl-3.0/

The terms of the license will be word-by-word exactly as that. The only difference is the copyright notice that will be:

Aether Summon - A non-random turn based strategy trading card game where players build decks and duel each other using scrolls powered by aether fluxes to summon magical fantasy creatures, interdimensional portals and casting spells.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License version 3 as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with this program. If not, see https://www.gnu.org/licenses/.

This licensing model allows you to change the source code (and any ancillary files, such as graphical assets, names, the game rules engine, etc) in any way you want, develop it for your own purposes, including as commercial applications, share or charge for its distribution with the only requirement being that it's shared under the same License and references the original in any relevant place. Under AGPL online streaming, including providing a platform for playing the game, falls under the definition of distribution.

There are no associated costs at all, even for commercial usage, as long as the license is respected - this is - other than for private usage the source code of your own variant needs to be open-source too - this means - any additions/changes/improvements to the base source-code made by you, along with the source-code, need to also be provided to anyone who asks for it.

Why this licensing and not a more permissive one, such as MIT or Unlicense?

This campaign aims to use crowdfunding to back the delivery of this code to the world at large, nonetheless, in my view, the one who wrote the code and also a professional web-developer, and having spent years developing and improving this game up to this point, investing not only time but also in different stages my own money - I believe it is worth much more than the funding goal (3000€) - as an example around 2019 when I started getting serious about the game I spent more than $3k just hiring artists to make illustrations for the game - and because of that, together with my desire to provide it as open-source, a license that obliges others that want to use the source-code for their own ends to contribute back their improvements, changes and additions is the only one that makes sense.

This makes it so that anyone will benefit of those future changes too.

Some examples, non-exhaustive, of what you can do and what you need to also publish as open source when you build or incorporate the licensed code, in the format X) Example X-Responsibilities follows:

1) You have a network based service that provides players the chance to play different games, you incorporate Aether Summon in the suite of games you offer without any change to the source code other than stylistic, text display or graphical assets. Players click a link (or by whatever other means) and are directed to your own hosted version of the game.

1-Responsibilities) Including the License mention, copyright holder & access to a free to download links to the original source code. Your own platform code is considered part of an "aggregate" and not subject to this license terms so can be kept entirely private.

2) Same situation as 1) but instead you have a chatroom in your platform that allows players to link together and start a game in one of the many games you offer, through a request. For this to work you need to add/modify the original code so that it can receive that request and then fire the duel (or duel settings page confirmation, etc).

2-Responsibilities) Same as 1-Responsibilities but also; you need to open-source in full the changes done to the original code to support that functionality - you don't need to open-source your platform source-code that does the request, but you need to open-source the, e.g., endpoint that handles such request as that is a change to the source-code licensed under these terms.

3) Same situation as 1) but instead you create a chatroom directly inside the game, so that players when they're in the Game's Warroom can directly chat and start duels with others.

3-Responsibilities) Same as 1-Responsibilities but also; you need to open-source in full the chatroom and any other changes done to support it inside the game.

4) You add paypal as a payment provider inside the game.

4-Responsibilities) Same as 1-Responsibilities but you need to open-source the paypal integration and any other changes done to support it inside the game

5) You want to charge a different value for the gold coins acquired through Stripe

5-Responsibilities) Same as 1-Responsibilities, since the value change is in Stripe's product definitions (payment links) themselves you don't need to open source anything else

6) You want to change the displayed game text, colors, styling or even the image/flavour assets for a scroll or other parts of the game, without modifying the source-code

6-Responsibilities) Same as 1-Responsibilities, you don't need to open-source these changes as they all can be applied independently from you publishing or not your source-code - e.g. you change the image for scroll "Replenish", or you change the display name of the domains to "Metal", "Wood", "Earth", "Fire", "Stone", "Water" without doing changes to the source-code (aka, modding). Probably would be cool if you shared your mod as open-source but you're not forced to.

7) Using the previous last example in 6-Responsibilities, you change the domains to those, but also change the engine rules, so that , e.g. "Metal" aether is gathered in some other way, or has additional rules, or you change them in the source-code itself replacing the references to those domains to the new ones

7)-Responsibilties) You need to open-source your version of the source-code

8) You charge players a fee to play the game on your hosted servers

8-Responsibilities) Same as 1-Responsibilities, as long as the payment mechanism is external to the distributed open-source, e.g. you charge a payment outside the interface and then provide a password that users need to use BEFORE they access the game (not from inside the game), for instance through a redirect or something

These are just some examples to make it more understandable what is the scope and my intention by releasing the game under this license. In all of them you still need to keep the original copyright notice, license, display them where appropriate, and provide a link to the full source code of the game.

▶ Vidéos (0)

Pas encore de vidéo pour ce jeu.

Commentaires (0)

Connecte-toi pour commenter ou répondre.

Pas encore de commentaire. Lance la discussion.