One Hour One Life Forums

I have no problem with people arguing about the direction of the game.

My problem is with people questioning my motives.

I'm not making the changes that I'm making out of laziness or greed or for fraudulent reasons.

The changes that I've been making are WAY more difficult than just piling new content on top of a broken game would be.  I could have been putting out 100-objects-per-week updates for the past 8 weeks, and we'd have 1500 things in the game.  But we'd have a laggy server, one giant mega city in the center of the map, instant murder with no evidence left behind, crashes post-update when people forget to disable custom server, etc.

Instead, I've been making all of these less-visible changes that often involve a lot of programming and refactoring and thinking.  For example, I'm currently rethinking the way that object decay and tool use is implemented, and this has involved a few days of programming.

In the midst of all this programming work, I've still been getting some kind of content update out every week.

But I imagine that it will be a few more weeks of this kind of necessary programming work before the 100-objects-a-week updates become a regular thing.  I'm getting pretty close to that point, as the list of programming tasks gets shorter and shorter.

Along with programming, I've also been tweaking the existing content, which is what everyone is all upset about.  But that part has to be GOOD.  800+ objects.... that part is a full game in and of itself already.  How many unique objects are in Minecraft?

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:

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...

Yes, this is coming in the future.

My idea was some kind of rabbit hutch....

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...

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.

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....

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).

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.

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.

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.

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.