As you may recall from #1, this column was meant to be a development blog of sorts. A notepad to scribble down ideas.
That’s the intent. It never quite works that way when you publish something.
If I were to *truly* share the development process, it’d look like this:
add items players can equip and switch between units
what kind of items? armors and weapons like RPGs?
DOESN’T FIT THEME. better: hats. eggoas are round, hats go well on round things
units should carry several items = let eggoas stack hats. visually obvious and appropriately stupid
hats crafted with exploration rewards. what to call them? shards. carrots. sharrots. dumb name. come back and change later
if exploration kills units, players might keep unit count low on certain unit types and spam explorations with these and these only
solution: add timer. run tests.
tests show it’s a bad solution. add tiers of sharrots instead. better tier = better hats
eggoa stats need to have dual purposes. pick a stat for hat effectiveness. pick a stat for number of hats an eggoa can carry. what to do with remaining two?
want to include global hot potato items. how should these fit in?
And so on, and so forth. Endless stream of consciousness notes. Ideas drawn out, then discarded. Tweaking numbers until the numbers fit, then realise there’s a better way, and start over.
There’s a lot of chaff to wade through to get to the good parts, especially when you want the whole system to be cohesive — and we do!
Setting a commitment to clean up these rough ideas once a week felt like a good idea to stay accountable. One post a week? Can’t be that hard!
But then, funny things happen. Write ideas, present them nicely, and it all starts to be too rigid. Concepts become harder to move on from once expectations are set — even to oneself.
Which is not what we want.
Additionally, you real snail fans know how the snail machine works. Small games, one by one. Iterative concepts, building on each other. Adding an experimental feature or two each time, then refining it in the crucible of the Ethereum mainnet.
Nothing like playing with real ETH to push you to make things airtight!
This hasn’t stopped with Eggforce. In fact, it’s more necessary than ever. A more complex game requires greater care to make sure it doesn’t break.
Since Eggforce was announced, I released SnailTroi (and its little brother SnailNumber).
In apparence, SnailTroi is a take on “daily ROI” games, and/or the spiritual successor of SnailTree.
Behind the scenes, SnailTroi lets us test interactions between contracts: your referral link activates only if you own a certain number of snails in SnailThrone.
Many new features will be necessary for Eggforce, not the least of which being: contract upgradability.
Which has to be implemented the right way: it can’t just be the owner having full power to change the contract, else this defeats the point of decentralization.
(To be honest, the state of the DApp ecosystem proves I could get away with it. But as a matter of principle, as well as longterm health, this isn’t what we want!)
So we’ve got to think voting. We’ve got to think time periods, we’ve got to think about the best way to allocate voting rights, we’ve got to think safeguards, consider the risk of capture inherent to any model, balance it appropriately.
To do this right, it’ll take at least another DApp first.
You will know about this mystery DApp soon, but let’s loop back to the topic at hand: it’s better to focus entirely on getting one task done, than switching back and forth.
EWW as a formalized, proper weekly thing adds too much “multitasking” to the process.
Got to walk before you can run!
In conclusion, Eggforce weekly writeups will continue.
Only, in this much more informal manner.
Less presentation and less focus on the final game. More of a timestamp of current thoughts. Always about eggs.
(And hey, if you want to know more — you can always hop on Discord and have a chat there!)
Until next time, snels!