a multiplayer game of parenting and civilization building
You are not logged in.
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.
Also, ALL MAC USERS:
You must DL v58b manually. If you try to run your old client, it will break when it tries to install the v60 update.
Several Mac-specific issues have been fixed.
First, a bug that prevented people from clicking to move after typing to speak (particularly if what they typed contained the letter E) has been resolved. This was a strange bug resulting from weird keyboard codes being returned by certain Macs. I'm not sure why the wrong keyboard codes are being generated, but I've implemented a work-around.
Modern Macs have a huge problem with Apple's new Sandboxing scheme. Apps that aren't signed through Apple are run in a random location where they can't find their files. To work around this, the game asks you to find the game folder at first startup if it can't find its data files.
But, on certain macs, even this process wasn't working (apparently, System Events isn't always running like it is supposed to be, so it can't display dialog boxes). I'm now using the Finder to display dialog boxes instead, which should always be running.
Finally, Sandboxing was also interfering with the update process on some Macs. I think that Macs can cache applications somehow, where even if the application is overwritten, an old version of it will keep running. So, after downloading an updated App, the new app wasn't running on re-launch.
The work-around (which will hopefully work) is to give the new App a new name each time... a brand new App bundle. So, instead of them all being called OneLife.app, they are now OneLife_v60.app. When v61 comes out, it will be OneLife_v61.app.
HOWEVER, this work-around has the side-effect of leaving a "vacant" app behind with the old name. Apparently, an App can't fully delete itself. This should be obvious, because the ghost app left behind has no One Life icon. The new one that has been installed will have the correct icon. The old one won't be runnable, and will have 0 size. Just delete it as you see fit.
Also, due to permission issues, getting all of this to work means you need to download the whole bundle for v58 again manually, which I have called v58b for the Mac.
So, it's a bit of a pain, but it must be done. Grab v58b from your original download page. But only Mac folks need to do this.
If you're on a Mac, please let me know if you're still having issues.