a multiplayer game of parenting and civilization building
You are not logged in.
I am glad to hear that it hasn't been a complete loss at least. Hopefully over the course of the games life, it will garner more popularity. I have definitely had my doubts and i think that's at the core of most complaints. Everyone has doubts, even you i'm sure.
I definitely have doubts. More than doubts. I have certainty.
I know the game is not as good as it can be. It was boring 8 weeks ago, and it is getting less boring, but it's a hard design problem to solve.
People "stopped playing" many weeks ago, which is why I'm working myself to death trying to improve it.
Being born in a mega-village that already has everything is boring, because what you do doesn't matter. There are no wrong choices, there is no tension, there is no dramatic arc. Do what you want... who cares?
Check out this video:
https://www.youtube.com/watch?v=-WylITUECR4
As I watched that.... my certainty grew and grew. That's definitely not the game that I ever wanted to make.
The fact that my game was like that several weeks ago was an accident on my part.
I'm not knocking the creator of 2HOL. It's great to see mods that explore all the different options. And I also get that many people like a game with no challenge where you just do whatever you want. Minecraft creative mode is hugely popular, obviously. But I never played creative mode....
OHOL will never be a game where civilization and progress is easy, assuming that I can solve these design problems.
Your legacy will be hard-won.
I didn't want him artificially inflating the stats with bots, that is all.
Bots are welcome, but not if you're using them to live 14,000 lives in a few days. That is a DOS attack, because it creates false statistics that are supposed to be real and reliable. His review was falsely at the top of the list, so I removed it. He did not play 500+ hours. His bots did, 24-7 on all 15 servers.
Turnip, I guess you didn't read the comment that I was responding to. I will repeat it here for you:
I hope you invest all the money you made in some failing business and lose it all. Maybe invest in your own game.
If you don't see something wrong with that, what is wrong with you, Turnip?
I am not being "rude" by expressing displeasure over these kinds of comments.
It is a natural human reaction to having someone wish that your whole life's work fails. These kinds of comments displease me.
Also, my response was not worded in rude way. I did not use rude language. I simply explained my position.
I have been working on this game for three years. That is a fact. There is nothing rude about that fact.
If the commenter was claiming that I'm attempting to defraud people and run off with a bunch of money, that commenter is committing libel. I shouldn't just stand by quietly while my "customers" lie about me....
For the record, after taxes, this game has brought in about $50K for each year that I have worked on it. For a family of 5, that puts us slightly above the poverty line...
I get it. There is no reason for you to improve this game, no, REVIVE this game because you made your fortune and now you can be done, you can keep making it harder for players until nobody plays then you won't need to finish the game and thus your work is done your money is made.
I hope you invest all the money you made in some failing business and lose it all. Maybe invest in your own game.
What is wrong with you?
How much money do you think I've made?
I've been working on this game for THREE YEARS.
I have at least two more years to go.
The game has been out for only 8 weeks. I've been putting out weekly updates the whole time, along with answering 50+ emails a day personally, along with posting in the forums and participating in Discord, along with optimizing the servers and fixing every bug that has been discovered.
I have a wife and three children. I am 40 years old.
I have been making games for 14 years.
Don't feel sorry for me. I chose this life.
But also understand that this game means EVERYTHING to me....
Say "hi" to Notch for me...
Yes, this is coming in the future.
My idea was some kind of rabbit hutch....
You're right!
I forgot about the saplings. That's an unintentional leak. Will fix.
Also, shovel is worn by moving dung... so there!
Requiring a finite resource like worms to make compost made it finite. Am i under the wrong impression that sheep manure is infinite? Do they only poop once? If manure is infinite, then isn't compost and by extension soil, infinite?
Awesome news!
Whoa there, cowboy...
Is dung the only ingredient needed for compost?
And when is dung emitted? After a sheep eats...
Yes, compost no longer requires the exhaustible earthworm, but are the other ingredients infinite?
Actually, there's irony here, because there is still one backdoor path to infinite soil, but it uses the earthworm after all... a long, slow, and fragile path...
Some people say, "Hey, the trailer promised that I could leave a legacy, and now I can't!"
If everything that you make lasts forever, and thus the world is filled to the brim with the stuff made by others, how exactly is your contribution meaningful to anyone?
What legacy is there in a forever-wall if there are walls everywhere?
Isn't building a wall that lasts 5 lifetimes, and then having your great, great, great, great, great, great, great, great, great, great, great, great, great, great grandchild care about that wall enough to repair it when it finally cracks even MORE meaningful than a forever wall?
Old things are meaningful BECAUSE things decay. If nothing decayed, there would be no old things, because everything would be old.
And stone walls currently last forever, and even become old walls.... sounds like a meaningful legacy to me. Same with bell towers, which take 18 generations to build.
The people who see these things are seeing something really special.
Thus, the legacy opportunities in the game are deeper and more meaningful now than they have ever been.
My intent was never to make a roleplaying game where you get to make up what you want to do in the game and pretend to be a king or whatever.
I'm trying to make a game where a village NEEDS a king for real, gameplay reasons, because leadership is the only way to succeed in the complex, multi-person task of keeping a village going.
You don't care for your baby in this game because you're roleplaying mother. You care for your baby because it's your only chance at a future after your own death.
If a village was going to war against another before, it was simply because it was an entertaining thing to do.
I want villages to go to war FOR REAL based on true gameplay reasons. Resource shortages, fertility issues, etc.
Where is trade in the game? That is what I want. Real trade, not role-playing trade. But there is no reason to trade if food is infinite and everything you make lasts forever.
I do have grand plans for this game, but it will take a lot of experimentation to get there. When we get there, if I can do it, it will be the most rich and complex and meaningful game you have ever played. But you won't be role playing. You won't need to.
Also, I'm not at all saying that I haven't made loads of mistakes.
I've made TONS of mistakes with this game. Obviously, monoliths weren't supposed to be buildable from scratch in 1.5 hours. Obviously, putting Eves in a R=1000 circle isn't going to work long-term. Obvious now.
I will keep making mistakes.
Soil is still finite...
Yes, new Eve spawning isn't live yet. It will go live in about an hour.
It's not a "problem" for me to release an update that "breaks" things. That is what every update will do, every week, for the next two years. I will keep breaking the game over and over and over.
A multi-player game is like a leg that keeps healing crooked. You have to rebreak the leg to get it to heal straight. That process is painful but necessary. The "healing crooked" is players getting used to playing a broken game. Exploits calcify into reflexes. Players become skilled at playing the broken version, and they have to re-learn the fixed version.
A game where every tool lasts forever is ALREADY broken. Having things wear out is a (partial) fix. Letting your repair everything with one easy trick just lets you get back to your comfortable, previously broken state, where every tool effectively lasts forever, and no one needs to make tools in an established village anymore.
A game where the entire traversable area filled with endless civilizational clutter is already broken. Monoliths that clear the whole world (at least once), plus abandoned map culling, plus better Eve placement, is the fix.
The only constant in this game will be change.
And I'm not going to make cautious, timid changes. I'm going to make bold, sweeping changes.
Two years from now, you will barely recognize One Hour One Life. There probably won't even be carrots anymore by then....
The problem that I have here is that many player complaints come from a place of misinformation.
Immediately after the update, people said, "There are no villages! See, the decay update ruined everything!" But the reality was that the servers were crashing. The lack of villages had nothing to do with decay, but instead was due to the crashes causing everyone to start from scratch ever 30 minutes or so.
Here's a few things I don't understand:
1. Almost all of the time-based decay is currently set to 2+ full lifetimes. You make clothes, you wear them your whole life, your grand children and great grandchildren wear them. Then some stranger in the distant future finds that they wear out. The walls crack in 5 lifetimes. If you make these things, their decay will be someone else's problem.
2. Even the dreaded baskets take a full lifetime to decay. If you make a basket, you will never see it decay.
If it's tedious to make them in the first place (or if you are that future stranger who finds the previous generation's work wearing out, and must make new), then what exactly do you want to be doing with your life in the game? It's a game about making stuff.
3. All of the use-based tool breakages is currently set to 20 (or 40 for the ax). That's a lot of shorn sheep, or chiseled stone, or... whatever. Probably more than a lifetime of usage for everything but the hoe. Do you really want to never blacksmith again?
I was just born into the biggest, most advanced-looking village I've ever seen. Stone walls everywhere, multiple bell towers. How did they do that?
For those of you who have played 100s of hours and are "suddenly" finding the game to be tedious, there's also the chance that you are just getting bored at this point, and a worn-out basket didn't really ruin everything for you. I know that the game can get tedious over the long haul, and that's what I'm working to fix.
Yes, all of this stuff will be tweaked and tuned into the future. I'm tweaking and tuning it now.
But the rash "the game is ruined now" proclamations are getting a little old at this point. I've heard these same things, to greater or lesser degrees, week after week, whenever I changed things. Getting rid of infinite carrots eight weeks ago didn't ruin the game. Making stuff wear out last week didn't ruin the game.
I'd say the game is way better now than it has ever been in almost every measurable way.
If you don't believe me, the whole history is right there in github. Roll back the client and the server and data 8 weeks and see how "fun" it was back then. No bears, no desert, no gold, no dyed stuff, only two wild foods, no monuments, no horses, no baby names, no stone walls, no locks. Oh wait, even worse! Server lag at 40+ players, loads of bugs that are now fixed. There have been 22 released updates since launch.
Sometimes I feel like pushing a little "time machine" update just to give people a taste of what the game was like at launch....
Alternatively we could still be using rabbit skin pouches to fill our cars' radiators, but that's kinda ugly to me.
Well, I imagine that the final game will have quite a bit of this....
I mean, will you really want to build an injection-molding machine for plastic just to have a water jug to use with your car for aesthetic reasons? You would probably just use the rabbit pouch if it worked the same...
There is a category system in the transition engine that auto-generates transitions for similar objects.
For example, there's a "small wood chopper" category that contains both the ax and the hatchet. Both can make kindling out of a bunch of things. By using the "small wood chopper" meta-object to define transitions, then we only need to define them each once, not twice.
BUT, under the hood, the engine is auto-generating the actual transitions for us. So the server doesn't know about categories when it checks if hatchet + branch does something, since that transition actually exists.
The idea here is to build as much as possible ON TOP of (A + B = C + D) as a core abstraction.
That is this game's equivalent of the 1x1 meter block (Minecraft's core abstraction).
You can do everything imaginable with just atoms, but some things (like building a bridge) would be tedious to do atom-by-atom.
Can A + B = C + D represent everything? It sure can.
But we can also build some tools on top of it to ease the content-creation process.
This entire forum is built on HTML, after all, but very little of it was generated by hand.
That said, there are some things, like containment, which could be handled by the core abstraction, but which are clearly, provably, intractable.
If we have just 10 small containable object types and a container with 12 slots (like the cart), then we have 1,000,000,000,000 objects that we'd need to represent, along with 20x as many transitions for adding and removing objects. Clearly, we can't do that.
But 140 auto-generated transitions to handle all the different states of shears on all the different states of a moving sheep? Why not?
The core server logic, the thing that's churning away day and night, then becomes super simple. Literally checking for A + B when you try to use A on B.
The complexity lies in the helper-code that auto-generates various transitions for various reasons. But that code only runs once, at startup, and its results are easy to examine and test in isolation (you can actually examine the generated transitions visually in the editor if you really want to).
Zed, this has been suggested...
But it would be another hack, and also not particularly simple to implement.
a + b = c + d is an elegant design, but there is no place for object permanency in this paradigm. So the very concept of limited number of uses doesn't fit in, and should be scrapped if you're going to be faithful to the original vision.
How would a berry bush work in this context?
There are four options:
1. Berry bush is infinite and always gives a berry
2. Berry bush gives one berry and then becomes empty forever.
3. Berry bush gives one berry, but then leverages the decay system (a reasonable modification to A + B = C + D where A is a timespan instead of an object---that has been in my model since the very beginning) to grow another berry after 30 seconds or whatever.
4. Berry bush is actually 7 hand-made objects, and taking a berry is a transition that takes you to the next more-empty bush, eventually getting you to the empty bush.
I originally envisioned that all "multi-use" things would be simulated using 4. I got kinda sick of duplicating objects by hand, though, so I wrote a piece of code to do this for me. Thus, the underlying model of A + B = C + D is still preserved by the way that "useCounts" are currently implemented. There are 7 berry bushes in the game, in fact.
Yeah, randomization also makes for drama and more interesting stories. Known quantities do not.
"I used my ax 19 times and then made a new one before the old one broke. Then I used the new ax 19 times and made a new one right before it broke." That's not a very interesting story.
"I had three backup axes, and this one time, they all broke after one chop each, by chance, and then I was stuck making a stone hatchet again to bootstrap my forge with kindling." That is a much more interesting story.
Poker is a way better spectation event than chess.
I do, in general, like randomness in the games that I play.
I do not, in general, put randomness in the games that I make.
These systems could be combined somehow....
I mean, I still need fixed, non-random usages for things like berry bushes and carrot rows. A bush that looks like it contains 7 berries should give you 7 berries (though it could be argued that the bushes should have a random number of berries to begin with).
But 40 uses for the ax seems like a lot of dummy objects, and is beyond the scope of what that system was intended to support.
Maybe there can be 4 uses for the ax, and then a random chance of advancing to the next usage. For the berry bush, this random chance would be 1 (picking a berry always picks a berry). For an ax, this could be 1/10, meaning that you could use the ax 10 times, on average, before it would advance to the next usage state. And, with the worst luck in the world, you could still use the ax 4 times.
However there is some hidden information: wells, tools breaking, and even decay time. These are all variable states which are not visible to the player and therefore pollute one's ability to make a decision. Please don't move further in that direction.
All the breaking tools show wear marks half-way through their lives.
I'm still experimenting with this, and I may add more wear marks to make it even more clear. Kinda like picking carrots. Hidden information made visible through sprite changes.
The well is a special case where there is no visible change at all. But well.... it's a well, folks! A deep hole in the ground.
As for decay times, I'm not sure how that could be fixed in a sensible way. It does make sense that a baby sheep takes some time to grow up, right? Or that a plant takes time to grow?
I suppose there could be a UI that gives you an ETA when you mouse over something.
Also, I tested running the transition-generation loops twice, and it does seem to fix the problems with the shovel and the shears.
This is probably one of those things that I can deal with if it ever becomes a serious performance problem. Right now, the server is using something like 16 MB of RAM to host 100 players...
Something else I just thought about:
In terms of the core representation, which is currently a unique integer ID for each "unique" object state...
Like maybe the ax is ID 503, and it has 40 uses, which are auto-added at start-up above all existing IDs, so maybe we get 1021, 1022, 1023, ... 1061 for the various use stages of the ax.
If the ax was instead a single ID with an extra property (or a whole raft of properties) that went along with it, we'd essentially have
503,1
503,2
503,3
...
503,40
I don't see how this is fundamentally different from, or really any way better than, 1021, 1022, etc. We're essentially just shifting the bits into a different field, but the bits are still there. We need them.
The same logic is needed too... transitions must pay attention to the value that goes along with 503 and decrement it. Or a transition can know that a 1022 becomes a 1021. It's the same logic, just in a different place.
The only thing that's "wasted" in the hack approach is memory space, because extra transitions are generated, and also extra dummy objects. We're essentially trading RAM for code complexity.
Each transition occupies 45 bytes or so. We can store 2 million of them in 100 MiB of RAM.
Objects use quite a bit more space, 320 static bytes, and then some dynamic bytes depending on the nature of the objects (an array of sprites, the object description, etc).
Still, extra objects are not subject to the same combinatoric explosion as transitions, so there won't be as many of them. 40 axes, etc.
Also, given that these "dummy" objects are identical copies of their parent, there may some space savings by simply keeping a pointer to the parent instead of a fully copy.
But none of this changes what's happening on the map or in the protocol. In fact, assuming that we don't exhaust the 32-bit integer space with dummy objects, the current implementation is the most efficient in that regard.
Instead of passing around or storing pairs of integers for each object, we are passing around a single integer that fully represents that object.
KucheKlizma, object properties doesn't solve this problem.
You would still need to figure out which property is preserved during the transition and which one is discarded.
ThoreWare, just adding name-value pairs to objects does nothing unless the underlying engine does something with those names and values. Even use counters requires specialized code. It's not just gotten "for free" by adding an object property system.
So, yes, as you say, it would need to be added to the transition engine. But how does the transition engine make use of these properties? If A + B = C + D, but A has some property (salt_content=20), how does that change A + B = C + D? The simplest thing would be to add a threshold specification for the transition to apply. A + B = C + D only applies if salt_content of A is > 15. Oh, but wouldn't we also want the salt_content property to transfer into C or D as well? There'd need to be some interface for specifying how the input properties are routed to the outputs.
If you have the timestamp that the object was created at, you could make the probability of breakage a function of the object's age. That would solve the problem of breaking on first use.
Yes, I thought about this.
That is a relatively simple server-side solution, though it requires tracking of this creation time as the object is moved around (picked up, put down, put in container, etc.) If all that code is changed, might as well be tracking a use counter directly, right?
Also, it's not clear when an object counts as being "created." Some things get modified, and as far as the server is concerned, they are new objects. Like the shovel of dung. It's a different object than the shovel. It works differently than the shovel (it cannot be used to dig up a rock.... it can only be used to dump the dung). So we'd need to know that the dung shovel isn't a "new" object, and we'd need to preserve the old creation timestamp (of the shovel) through this transition.
Potjeh, what variable properties to you envision being necessary?
Thoreware, yes it is a hack.
The core abstraction in this game is (a + b = c + d) crafting. That's what makes all the deep interactions possible, makes crafting learnable through observation, and so on. It's the beating heart of the game, and this model can cover almost everything you can think of.
However, it runs aground in several situations. Containers are one, so I added containers. Multi-use objects are another. The pickable berry bush is the most basic example of this.
A "property system" sounds really complicated to me. It sounds like a siren song that promises to simulate everything. It's not really needed for most things, and my YAGNI instinct warns me against it. Like, if a fire extinguisher puts out a fire, I'm tempted to define a "smothering" property, and give the extinguisher that property, and then maybe also add a fire blanket with a smaller quantity of that property (smothering=2 instead of 4), but getting the blanket wet will push smothering up to 3. But YAGNI. Just have the fire extinguisher put out the fire. You don't need to code a whole system for this.
I've seen people go down this path, with over-specialization of the code, and it becomes a mess anyway. It IS a mess, there's no way around that, but you need to decide where to put the mess. I think that the mess should usually be in the data.
Except in some rare situations where the data solution becomes intractable. Containers are one example of this. Object use counters may be another.
I implemented a bunch of things years ago without internal object HP in mind.
So tracking object HP through a bunch of different code systems would require very deep changes that would likely take me at least a week to implement.
The database would need to change, the map would need to change, container tracking would need to change, etc. This code is complicated. Changing it in a deep way is hard and error-prone.
Also, when a tool changes to a different object through use (like the shovel full of dung), the code needs to handle that case specially (oh, this isn't a brand new shovel full of dung).
The container code is general-purpose and doesn't work for the specific purpose of a berry bush. You don't want people sticking things into the bush (like stones or dead rabbits). Also, there are other things, like the draining pond, which is really nothing like a container. So I think that the current system works great for those things (auto-generating pond_5, pond_4, etc., and drawing different sprites for each).
It makes way less sense to leverage this system for something with 40 uses like an ax.
Tool breakage is currently implemented with a use counter. An ax has 40 uses, for example. After chopping 40 trees, it breaks.
This works well and makes sense.
However, the implementation is complicated and causing some bugs. First of all, this use count has to "follow" the ax object everywhere it goes. On the ground, into a basket, in you hand, into a basket in a cart, etc. For some objects that get transformed during use (like a shovel, which becomes a shovel full of dung), it gets even more complicated, as the number of uses remaining has to transfer between objects (a dung shovel is a different object with a different name and different sprites).
This is currently implemented by automatically making a bunch of unique dummy objects for each multi-use object. Auto-generation of ax_1, ax_2, ax_3, ax_4, .... ax_40. These actually exist in the game engine as distinct objects with distinct IDs, though they are automatically generated from the ax. Thus, an ax_15 can exist on the map, or get picked up, or put in a cart, etc, and always be an ax_15.
The problem comes in the transition engine, where we have stuff like
ax + tree = ax + firewoodWe now have 40 extra ax objects floating around, and that means we need to auto-generate 40 transitions like this:
ax_40 + tree = ax_39 + firewood
ax_39 + tree = ax_38 + firewood
ax_38 + tree = ax_37 + firewood
...So now we have 40 extra transitions to track and manage. Complicated, but it works.
The bigger problem arises when we want to use a useCount object on another useCount object. For example, a shovel can be used 20 times, and be used to dig up a berry bush, which can be used 7 times as you pick the berries. So we have these generated objects:
shovel_1, shovel_2, shovel_3, ... shovel_20
bush_1, bush_2, ... bush_7But if each of those shovels needs to be used on each of those berry bushes, we suddenly get a pretty bad explosion of 140 generated transitions:
shovel_ 2 + bush_7 = shovel_1 + dug_bush
shovel_ 3 + bush_7 = shovel_2 + dug_bush
shovel_ 4 + bush_7 = shovel_3 + dug_bush
....
shovel_ 2 + bush_6 = shovel_1 + dug_bush
shovel_ 3 + bush_6 = shovel_2 + dug_bush
shovel_ 4 + bush_6 = shovel_3 + dug_bushThe game engine currently does NOT generate such double-useCount transitions correctly, because it doesn't run through the generation process twice. The code could be fixed, but the problem of an explosion in complexity still remains. Lots of extra generated objects and transitions, a more crowded object address space, and so on. If a 100-use object (someday) is ever used on a 100-use target, we're looking at 10,000 generated transitions.
The other option is to track the use count separately from the object ID. So, all axes would have the same ID, but there would be this extra counter that would travel along with it. That's a pretty deep change, since this counter would have to be tracked in the map database, in container slots, in the player (for what they are holding), in the protocol, etc.
The client would need to know about the use counter in some cases as well (for example, berry bushes are drawn with fewer and fewer berries as they are used up). Thus, it seems like separate objects make sense in some cases (like a berry bush or a draining pond).
But the question is this: are separate objects the best way to track and represent tools wearing out with use?
Maybe tools wearing out should work differently than berry bushes getting picked and ponds getting drained and pie bites getting eaten.
What if every tool simply had a small chance of breaking with each use? This is UncleGus' method in his mod.
If we want an ax to have 40 uses, on average, we give it a 1/40 chance of breaking with each use. Some axes break sooner, others later, but on average, they break after 40 uses.
We no longer need to track anything along with the ax, nor do we have to have separate states or dummy objects for the ax. An ax is an ax, with some chance of breaking, always. No extra objects to generate.
And for the cases where we NEED to generate extra objects (like the berry bush getting picked), we can still do that.
But when a tool gets used on a berry bush, we don't have an explosion of generated transitions. Just one transition for that tool per generated bush (bush_7, bush_6, bush_5, etc.)
Now, the problem with randomized tool breakage.... is that it's random!
Sometimes, very rarely, a tool will break on its first usage. Sometimes, equally rarely, a tool will last twice as long as the average. But having a "good" tool like this does not mean it will continue being good in the future. It has the same chance of breaking on the next use as any other tool.
This doesn't exactly match how things work in real life, and it creates a weird feeling. None of the rest of the game is random. There's a sort of press-your-luck gambling feel. Chopping one more tree, hoping to get lucky...
But it is oh-so-simple. Simple to implement, test, maintain, and tweak. No bugs due to complexity or unexpected side-effects.
Is there a way to prevent a tool from breaking on its first few uses? Not without some kind of extra tracking per-item. If we're tracking that anyway, might as well track a full use count.
Fastspring's privacy policy is here: https://fastspring.com/privacy/ Paging through it I notice that they sell information for their "Ecommerce Network". So you are right to be concerned.
I don't see anything there about them selling information. The "Ecommerce Engine" is the payment processing system. That is the system that I'm using to process your payments.
In terms of "partners," I'm an example of one of these partners. They process payments for me, and I have access to all of the information that they collect. I can see your name and address, for example.
As far as I'm aware, they are not selling your information or using it for any other purpose other than to prevent fraud.
They are taking 8% of every sale. They are making plenty of money. They don't need to sell your information to make money.