a multiplayer game of parenting and civilization building
You are not logged in.
After a pretty insane launch week, I'm trying to get my life back on track. I do have a family (spouse and three kids). And as you all probably know, I am a one-person team.
SO...
My usual work hours are 8am - 2pm PST Monday through Friday. Yes, I only work 6 hours a day, but that is 6 hours of 100% productivity. I'm not surfing the web during that time or reading Reddit. I get up at 7am every day, so I really do start working at 8am.
Going forward, I will break up my time as follows:
8am - Noon (4 hours) Content creation
Noon - 1pm (1 hour) Programming
1pm - 2pm (1 hour) Community interaction (tech support, forums, email, Discord)
There haven't been too many tech support emails so far, but each one takes quite a bit of time. Rest assured that I will get to yours as soon as possible, usually within a day or two.
But I will NOT be working on the weekends, at all. If you need tech support on the weekend, your request will have to wait until Monday.
There are also a lot of smart and friendly people in the forums and on Discord who may be able to help you when I'm not around.
Weekly content updates will be pushed by the end of my work day every Thursday. You can keep track of what I'm working on in the live-dev-changes channel on Discord. But keep in mind that those changes aren't live in the game until I push them out.
Well, you can't mouse over someone in real life to learn their name.
I think it's cool that people are naming their babies. And those babies can tell other people their name upon meeting.
Also, if mothers can "officially" name babies, some babies will be named dickhead just for lols.
Signs of some kind are coming in the future, as are grave stones.
But like in real life, if a grave isn't marked by someone who witnessed the death, then it remains an unknown grave.
This is a great thread!
I'll be looking at all these things in more detail in the coming weeks.
I checked, and as far I can tell, your REAL password to this forum is NEVER sent in the clear. I could be wrong about this, but...
When you sign up, a temporary random password is sent to you via email. But you're meant to change that immediately, and not use it elsewhere.
Once you set your real password, it will not be emailed to you. Right?
Okay, there was a bug in the instructions. The "ln" lines for the server referenced OneLifeDa7 by mistake. It should be OneLifeData7.
Please look at the latest version here:
https://github.com/jasonrohrer/OneLife/ … dNotes.txt
If you run pullAndBuildLatest, it will fetch the older version of this document for now (until I post a new binary release).
Yeah, it only works if there are no mothers to have you as a baby in the next life.
Your death location should be remembered if you're ever Eve again, though.
Eve is an edge case that only happens if there's no other choice. Thus, you should be born as a baby 95% of the time.
That is an excellent point!
Like minecraft realms, there will hopefully, eventually, be businesses that pop up to offer this as a monthly service.
I'm pretty sure you could run 10 or more separate servers on just one $5 linode. The resources used by the server are SO tiny, and if you limit the pop on each server (their private, so yeah), you could really pack a lot into one Linode.
If you figure this out, you might be an early mover in this space...
Okay, I just tried the pullAndBuildTest script on Linode, and it works fine.
It does fail to build the game client (can't find OpenGL headers), but then it goes on to build the server.
So... that's pretty great that the script makes it so easy. Cool!
(This script was meant to help people build a test environment to look for bugs long ago, not to help them setup their own server).
SO.... not sure why yours isn't working.
The very last step on my script was this:
g++ -Wall -Wwrite-strings -Wchar-subscripts -Wparentheses -g -DLINUX -O0 -I../.. -o OneLifeServer server.o map.o ../gameSource/transitionBank.o ../gameSource/categoryBank.o ../gameSource/objectBank.o ../gameSource/animationBank.o ../gameSource/ageControl.o ../gameSource/folderCache.o ../gameSource/SoundUsage.o ../commonSource/fractalNoise.o kissdb.o lifeLog.o foodLog.o backup.o triggers.o dbCommon.o playerStats.o failureLog.o ../../minorGems/io/linux/TypeIOLinux.o ../../minorGems/util/stringUtils.o ../../minorGems/util/StringBufferOutputStream.o ../../minorGems/io/file/linux/PathLinux.o ../../minorGems/system/unix/TimeUnix.o ../../minorGems/system/linux/ThreadLinux.o ../../minorGems/system/linux/MutexLockLinux.o ../../minorGems/util/TranslationManager.o ../../minorGems/network/linux/SocketLinux.o ../../minorGems/network/linux/HostAddressLinux.o ../../minorGems/network/linux/SocketClientLinux.o ../../minorGems/network/linux/SocketServerLinux.o ../../minorGems/network/linux/SocketPollLinux.o ../../minorGems/network/NetworkFunctionLocks.o ../../minorGems/network/LookupThread.o ../../minorGems/network/web/WebRequest.o ../../minorGems/network/web/URLUtils.o ../../minorGems/util/SettingsManager.o ../../minorGems/system/FinishedSignalThread.o ../../minorGems/crypto/hashes/sha1.o ../../minorGems/formats/encodingUtils.o ../../minorGems/io/file/unix/DirectoryUnix.o ../../minorGems/util/log/Log.o ../../minorGems/util/log/AppLog.o ../../minorGems/util/log/FileLog.o ../../minorGems/util/log/PrintLog.o ../../minorGems/util/printUtils.o ../../minorGems/game/doublePair.o ../../minorGems/util/StringTree.o -lpthreadThat's where it builds the OneLifeServer executable.
Does your run look different?
On Linode, the networking is so fast that running this whole process over and over is really quick. So put it in a different test directory and run it again....
I was able to save the non-error output to file like this:
./pullAndBuildTestSystem.sh > out.txtCan you do that and email it to me?
Oh, are you running on Linode?
The test environment is meant for desktop linux.
Perhaps the build failed part-way through when it tried to build the graphical parts (the game client) on Linode?
I'll try running it on my linode and see what happens.
So can you find your OneLife/server folder?
What's in there? Can you post the directory listing?
Reminder: the most popular games in the world are not on Steam.
LOL, Hearthstone, Overwatch, Fortnite, Minecraft.
I'm hoping to make a game that's SO GOOD that it won't matter that it's not on Steam.
Dig it with a shovel. The steel shovel.
Yes, the garbage pit is one of the most high-tech items in the game.
I'm crying with laughter as I type this.
Also, there's currently a bug with rabbit bones, where you can't pick them up once they're on the ground. Will fix!
Yeah... yeah... you're right.
This game isn't about playing with friends. You're right about the alienation issue too, with cliques of people who are on voice chat, but who never speak/chat in the game. A bunch of silent, well-organized people who seem to be telepathic.
I agree that it would make the game worse, probably.
Yeah, I've heard that milkweed has become pretty darn scarce in some parts.
Don't pick it unless it's fruiting, people.
Maybe grab some food and head WAY OUT into greener pastures to start a new branch of civilization out there?
Very strange...
And you ran pullAndBuildTestSystem.sh without error?
There are some additional instructions in:
OneLife/documentation/EditorAndServerBuildNotes.txt
That explains how to connect your clients, etc.
Yes, same proc-gen map. If you mess around in the source, I think you can change the seed though. You could also change various parameters that control map scale and density, etc.
The server saves the live map into various .db database files. As long as those files aren't removed, the map is persistent forever.
Still thinking about this.
I'm leaning toward making a "wish" interface where you can essentially just suggest a code-word (like apple) and then when you're born, it gives preference to sticking you with a mother who also used the same code word.
If she's ineligible (like, already has too many babies, or is on birth cool-down), then your wish won't be granted.
There's also an issue with being on different servers.
Thus, anyone who makes this kind of wish will be forced onto the currently-least-populated server, instead of the normal load balancing.
Not sure about the slow berry picking. Sounds like lag, maybe?
There is a bug where you will bounce forever trying to do something. But it sounds like you came out of it if you waited long enough?
Yikes about the passwords in the clear. I will look into it.
Yes, this has been fixed.
v58b contains a new updater that sets the executable permission properly.
What a mess!
Yes, good point. I think deleting your old v58 folder is necessary because of the sandboxing still looking there.
Github forks are a great idea!
Sorry for the trouble... I don't have a dual-head setup to test on here, so it's really something I've never looked into.
Have you tried building from source?
Can you test something for me in the source version?
Find minorGems/graphics/openGL/ScreenGL_SDL.cpp
Line 661 is currently:
flags = SDL_OPENGL;
Change it to:
flags = SDL_OPENGL | SDL_NOFRAME;
Recompile, and then launch the game in windowed mode to see what happens. You might also want to adjust screenWidth and screenHeight to match your target monitor, and turn useLargestWindow off (all in the settings folder).
Woah, that's really weird.
I'm assuming that this is some weird interaction between Windows 10 notifications and fullscreen mode. There's probably no way for me to fix it.
I will be looking into a "fullscreen window" mode in the future, though, and that might help.
Nice work, Inferis.
Well, it will break again for you later today, because I'm going to post a fix server-side so that + signs work in emails correctly. Thus your %2B thing won't work anymore!
When you find it stops working, just switch back to the +
Hmm... any chance you moved the game out of its folder? It needs to be run from inside its folder, not from a shortcut elsewhere.
If that doesn't work, have you tried windowed mode? Go into the settings folder and put a "0" in the file fullscreen.ini
Protein, you're on Dvorak too, right?
See.... typing "." works because that's where a QWERTY "E" key is located, so it releases the "stuck" E key from earlier.
The key press and key release events were being reported incorrectly by MacOS with Dvorak keyboards. Not sure why.
The presses were Dvorak, but the release events were QWERTY.