Online Retro Zombie Shooter - wkk.py

Indeed, my guess is that you get this error after you stopped the game and waited a bit, am I right?

I don’t really understand what you mean by “above BGE’s ticks”. One thing for sure, things can happen outside of the ticks. Just look at any process on your computer: they don’t stop, waiting for your Python script to finish.

Indeed, it is a per-thread singleton if I remember correctly (maybe read that in some doc… not sure)

Python modules being imported once is only an effect of the Python import system caching module queries. Say you do import abc for the first time, it will first look inside the dictionnary sys.modules for a key named abc: if it doesn’t exists, actually parse and import the file from disk/whatever, and add the entry to sys.modules. Next time it will look up inside the dictionnary, sys.module['abc'] = <module abc> is already defined, so use that instead of re-importing everything.

Also pouring your own data inside third-party modules is a very bad practice :stuck_out_tongue:

Why not making your own module file and do that there? Anyway.

Well, I thought I would need a dedicated server too, turns out that some free hosting services actually do the trick, see Heroku, am pretty happy with it, even though it is not direct TCP/UDP.


Thinking back on your “stuff happens between ticks”, yes, things can exist outside of one tick.

A game logic tick is merely just the point where the full Blender Player application comes inside the part of its mainloop where it will call every script that needs to be called.

Because your script is only part of one iteration, you might feel like you are “stuck inside one tick”, but that’s only the BGE that makes you think that, and the way we interact with it.

Bit of advice to break out of this: Define your own singletons or whatever, and either use Python Components, or Python Modules (still using Logic Bricks).

Python Modules have the advantage of executing the function of a module, which means that your file main body will be executed only once, but your function will be triggered on each tick. You will be able to store global states like this, and finally be “out of the ticks” :stuck_out_tongue:

To be fair the way logic must be defined in the BGE always bothered me, and I’ve been looking at a lot of different solutions. The way I am doing it for this game seems to the best I found so far, in my opinion of course. Maybe some things to improve, but oh well :slight_smile:

Time for an update:

  • Fixed the bug on Windows, the game now correctly launches.
  • Fixed mist issue, thank you @BluePrintRandom: Turns out UPBGE caches mist and world values by default on each material, so I turned it off and everything worked as expect.

And I finally started to port some of the input code from BGEz into this game.

I couldn’t for the life of me find a way to setup the game repository to be able to edit both the game and the framework, hence why I dropped using BGEz. Although the only thing that I really wanted from the framework was the input system. So I ported the relevant part, it is a bit lighter but still not very light.

Progress on this merge request.

The idea is to allow you to write down your own mappings into a file, but I won’t go into to much detail tonight, unless someone has a specific question.

To do:

  • Finish input port

Really once that is done, we should be able to move around on the server together :slight_smile:

Then I’ll need to make the game an actual game, not just cubes moving around.

This is actually what I do. I was having trouble thinking of how to explain the problem that I was having, so I tried to use a simple example. Hopefully I don’t give people bad ideas. :grinning: The only time I ever modified the bge module was to add gampad constants so that I could treat gampad keybinds the same as keyboard binds.

The third version of my game uses a free rabbitMq server for networking. I decided I need something that I have more control over sense I don’t really know what I’m doing. That way I can try stuff, make mistakes, fix things and such. For instance, maybe I’ll need to run the server within the bge or maybe not. I’m planing on developing it on a RaspberryPi so I’ll have complete freedom to experiment. Hopefully the pi can run Upbge. Once I know a little more of what I want then I’ll figure out a way to deploy it. Honestly, my game is terrible so it doesn’t really matter how I do it.
Anyways I’ll quite hijacking your thread and let you get back to your :skull_and_crossbones: zombies! :face_vomiting:

No worries, I don’t see any other places to discuss such issues, and as far as I know there aren’t many online projects using the BGE, so if anything can be cleared here I am really happy :slight_smile:

Fair point, in my case I forgot about running UPBGE on a server for now. For this project the server is a pure NodeJS server that knows nothing about the geometry of the levels/entities, it just relays positions and events. I use a very naive data check to see if an entity behaves weirdly, but it is far from fool-proof (I would actually enjoy someone trying to hack the thing, would be fun I guess!)


Time for an update!

Input system have been implemented! The player is able to move around, all good. I will just add a bunch more inputs and a small config file system tonight, shouldn’t take too long, and starting tomorrow people will be able to move on the server!! Happy happy.

Disclaimer though: I haven’t yet written position interpolation on the clients, I think I will keep that for later. Right now it means that you will see people “lagging”, but this is only because while your framerate is 60Hz, the server updates are coming at 10Hz (it is not a powerful server…)

Just know that this is normal, Battlefield 3 used to run its servers at 10Hz as well, and it is only after a very late update in BF4 that they added support for higher frequencies. The big ones did it, so I guess I can be cheap as well :stuck_out_tongue:

1 Like

On the other hand if anyone wants to write the entity interpolation, “merge requests are welcome” :wink:

Build Update!

If you sync yourselves to join at the same time you should be able to move around on my server :wink:

So far you can only move and fall… Also if movements look choppy it is only because the server is sending updates 6 times slower than your usual 60fps. It would require some smoothing on the client to make it look nice, but right now is the time for me to sleep :stuck_out_tongue:

Don’t be afraid to ask about anything, I would be happy to share my methods and plans for this online mini-game, as there is more to come!

Next up:

  • Look at the zombie merge request for the server
  • Use the zombie assets on the clients

I can also see plenty of small tweaks, like allowing to choose your character color to show online, display usernames, allow you to pick a username… So much to do, so few hands :slight_smile:

I did a quick parse of some of your code. I’d like to make you aware that I have not been able to use pip in conjunction with UpBge 0.2.4 Debian. It gives an error about ssh or ssl or such. The internets seem to think I should recompile python. I am warning you that your game may not install on Linux. It might just be my computer tho.

I am on Ubuntu 16.04 and everything was fine so far, tested on Windows 10 on my roommate’s machine and it worked as well, so I can’t explain your issue.

I am using UPBGE 0.2.4 found on UPBGE’s website, I know some people tried to compile latest master from their repository and some things failed, so maybe that…

Thank you for the feedback!

Update time!

The orientation are both uploaded and downloaded, so you should see when someone is looking at you!

I also merged the initial zombie movement patch, right now it is rather naive, zombies all move way too fast and keep missing their target, the sight of it is funny :slight_smile:

I don’t really know what to do next, few options:

  • Make a loading screen for the first launch, instead of a black screen Done!
  • Add entity interpolation
  • Move player using forces/speed instead of applying movement
  • Add weapon basic system

In the long run I will need to do a bit more things, but the few above are what can be done short term.
Anyone having an opinion? :stuck_out_tongue:

Latest Release

Added a loading screen, it is bad, but it does its job of a loading screen :stuck_out_tongue:

This can be improved later, but now you won’t just see a black screen!

1 Like

Guess it’s just my computer then.
I would like to respectfully suggest that if your intention regarding bootstrapping is for the establishment of norms suitable for long term development, then you may want to consider a standalone installer-updater-launcher, such as is used amongst professional online games. It should be possible using a Python to executable converter. This way the consumer would not need to have either Blender or Python installed. You could potentially download the standalone version of UpBge strait from its website and pip-it-all into the new copy. Or you could try to compile-it-all into a standalone that fits everything together before hand. Depending on your preference for distributing compiled binaries verses juggling dependences. Truly between the horns. Regardless, by providing an installer-updater-launcher, you protect the consumer from concepts such as version control and virtual wtvrs. I seriously considered doing as such with pyGitHub, but I have found github to be obstinately archaic.

1 Like

To release builds packing the standalone player as well as the prebuilt dependencies would be the way to go indeed: configuring some CI to auto build on tags/releases or whatnot, for each platform.

But because the original scope was to publish this game as an entry to the BGMC, I wanted to keep things “simple”, just by having a CI outputting the bootstrap for everyone to use the blends directly (which was part of the rules for the contest).

Yes, this is not the best way for an actual product, but it is good enough for now and for the sake of keeping publishing the blend files without the actual standalone engine alongside it :slight_smile:

But when you look at it, the current bootstrapper can already be replaced by something else, as the actual game only requires that the correct libraries are available in its Python environment, which can be set up one way or the other (currently by running a “front game” that sets things up using your UPBGE install).

I won’t be thinking about making a proper launcher/wizard for some time now, as I am solely at the development stage, and that the system looks like it will support a distribution enhancement later.

I still find weird that it fails on you machine only, had a bunch of people try already and everything seemed to roll fine. If you want to try you could download the executable distributed here (for Debian-based dists):
https://download.upbge.org/download/release/linux64/UPBGEv0.2.4b2.79Linux64.tar.xz

oops lolz :grin:

The stable UpBge dose the same thing. May be its a difference between Debian and Umbuntu. May be its just my computer. If it works for every one else then don’t worry about it, I’m not.

Nice install progress bar, btw. It gave me a laugh.

1 Like

Time for some new updates!

  • Player is moving using forces instead of teleporting itself forward
    • This makes it look like player positions are being interpolated on other clients, which is nice.
  • Tweaked some server parameters

I was looking at what to do next, I have been trying to rewrite my binary message packing on the server, I am at attempt 2 now. The library I use while it does the job, is a bit too much of a mess to use (struct).

But today I found a new library, called python-struct, which mimics the way the Python library works.
I feel stupid not finding this before, because now I want to actually replace the old lib by this one, but it means I will have to break the whole protocol code and redo it using the new lib. Not a big issue, just a bunch of work that I needed to be sure would be worth it.

So, after looking through it, it will be worth it, as currently implementing a new message for the protocol is taking me too long, and I don’t like what I currently have to write for it (see what I mean… erk).

I have also been thinking about how to properly handle zombies on the server side, as I said, right now the server doesn’t handle physics at all, it just receives and send back positions.

Zombies are currently moved by just adding vectors togethers on the server, but they currently have no idea of collision or whatnot, they just move toward the same point: [0, 0, 0], which is weird on clients.

But I recently found a port of Bullet for Javascript environments: Ammo.js.
This is actually awesome, but I fear that this will require some big design decisions:

  • How to sync client and server hitboxes?
  • How to run the simulation without taking the whole process? Sub-processing (=rpc, etc…)?
  • How much should the server check for simulation differences?
  • Can I run the simulation at 10Hz on the server instead of 60Hz like the clients (BGE)?

So that has been running in the back of my mind for this weekend now, but first next step will be to refactorize the message packing/unpacking!

Phew.

1 Like

Update time:

Finally done with the new encoding/decoding part, phew.

I actually am really glad, as it is much more easier to work with now, the code might look less verbose, but in this case it is actually better: it is simplier. Structs are data stored inline, and the code now perfectly reflects that. Also went a bit overboard with the typings, but it will now catch most mistakes.

Actually asked for help on StackOverflow, and someone answered almost right away, did not expect that.
The question and its answer: https://stackoverflow.com/a/55002429/7983255

So, with that out of the way, I am left picking a new objective. Boy do I hate to commit.

  • Try hard Ammo.js?
  • Implement basic client firing feature (raycast + new protocol message for it)

I think I am going to go with the latter. I can think of more things, but in this case this is no good, let’s keep it dumb and add the pew pew.

Steps for pew pew:

  • Fire a ray on client to hit target, fetch id, send event to server
  • Add a new message to transport the firing event
  • Manage entity health and disposal on death server-side

Let’s get rolling.

(By the way remember that If anyone has any suggestion or question, I am all ears!)

Update time:

Finally added the firing on the clients.

It took me rather long because I kept falling in rabbit holes…

  • Design the bare message on the server: hit_id, weapon_id, origin_vector, impact_vector
  • “So, if I need a weapon id, I need to define them somehow?”
  • Design item management on server, hit wall with design, skipping.
  • Design weapon system on client: same issue that with the server, skip.
  • Hardcode a test weapon and simple system to use/fire it.
  • Add some sounds.

And here we are.

So far the firing is not uploaded to the server yet, but you should be able to hear the effects that I added on the client. It is very basic, but it looks like a good base to keep building upon.

Next task I am working on is refactoring the client message system to mimic the one on the server. Right now I hardcoded the upload of the player position, but as I will add more events on the clients to send, I need the system to be more flexible.

More to come!

1 Like

im so excited that this new service platform even supports Python this is great for blender games, are u using a free account i went over to the website and it says a free account is also usable :thinking:

Fred/K.S

Heroku supports Python indeed, but not the Python you are used to in the BGE :slight_smile:

In this case I am hosting a NodeJS application (javascript) using a free account.

I don’t really know what are the limitations of such free accounts, but in this case I just need the server to run, display a few pages and handle WebSocket connections, which Heroku lets me do.

1 Like

Update time!

The server finally supports broadcasting clients firing!
So if you connect with buddies, you will see them shoot!

On the other hand, I did not expect it but because players are “living entities”, it is possible to team kill…

But because I did not handle that, you will still be able to play, although your entity won’t be broadcasted anymore but you will see lasers coming out of nowhere, very weird ahah.

There are a few issues now, such as players levitating for some reason, laser events arriving in batch too, and because I didn’t make any UI it is pretty hard to aim right now…

Oh well, next:

  1. Fix server crash
  2. Fix the teamkill
  3. Fix player position
  4. Add UI?
1 Like