Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orpheon]

What would be the first things to rewrite?

Yeah, I know a working server with a quote that walks around is great, I mean before that.

Does someone have a working concept for the collision detection and response? (copying the current one is not going to work)

Would we want to profit to restructure certain very bad things in the current version that are just to deep and grown to remove properly?
(UDP?)

And before you say "No one will be able to do this"; the more concept we put down, the easier for someone who will try.

[NAGN]

it won't be easy for anyone to do so just because you make a basic checklist
here's a basic checklist if you want

[ ] write a basic server program independent of game maker, which handles collisions properly but does not need to graphically render the game
[ ] finally move over the entire engine into a (preferably open source) engine which cuts it's ties from game maker entirely
[ ] rewrite the netcoding to be in a more quake-like udp snapshot system, and ditch the old tcp system in favor of a more lossy, but less bandwidth intensive and latency inducing way. This would require compensention for important packets, along with some sort of client-sided prediction coupled with lag compensention. None of this is necessarily, but it is preferred.


In that order respectively would smooth the transition

A basic server would not be hard to do, what would be difficult is getting the game to behave the way it does currently. Getting someone to do all this, or even the team to do this is difficult as very little of us have much experience outside of game maker and doens't have enough time

that's pretty much it

[Dokurider]

Well, if you guys go with Python, you are in luck as I know Python and might be able to lend a hand.

[Phantom Brave]

It's not going to happen. That's what NAGN's been trying to say.

[Orpheon]

[ ] rewrite the netcoding to be in a more quake-like udp snapshot system, and ditch the old tcp system in favor of a more lossy, but less bandwidth intensive and latency inducing way.

First of all, thanks.

Second, what do you mean with "snapshot system"? Please explain.

[NAGN]

in quake 3, the networking system basically works like this:

Everything is disposable. The only thing important is making sure that the clients get the most current game state, and they get it as fast as possible.


This opens up alot of new possibilities. Firstly, there's the movement away from tcp into udp, which is very fast and doesn't require port forwarding in some cases (socket punching) though that's irrelevent tbh to the whole decision as a whole

Basically when a missed packet is missed in the current system, tcp must freeze the socket, ask the server to resend the packet, and then unfreezes the socket. That's very slow and induces alot of latency.

In a udp based system we wouldn't need to pause for everything. If something is missed last frame, such as the position of a player, it doesn't really matter. The next frame will be updated so quickly that you won't even notice the brief decync. This makes the game artificially much much smoother

[Orpheon]

in quake 3, the networking system basically works like this:

Everything is disposable. The only thing important is making sure that the clients get the most current game state, and they get it as fast as possible.


This opens up alot of new possibilities. Firstly, there's the movement away from tcp into udp, which is very fast and doesn't require port forwarding in some cases (socket punching) though that's irrelevent tbh to the whole decision as a whole

Basically when a missed packet is missed in the current system, tcp must freeze the socket, ask the server to resend the packet, and then unfreezes the socket. That's very slow and induces alot of latency.

In a udp based system we wouldn't need to pause for everything. If something is missed last frame, such as the position of a player, it doesn't really matter. The next frame will be updated so quickly that you won't even notice the brief decync. This makes the game artificially much much smoother

I know what UDP is. My question was what kind of structure needs changing to achieve this:

Everything is disposable

, because I can't really imagine how we should change what.

[NAGN]

simple: we don't compensate packets

[Orpheon]

simple: we don't compensate packets

I fell very dumb, but what do you mean by that? Do we not expect packets, and just take those that appear? Do we try to guess how the game will go, and just take any packet that chances our way, without really expecting any?

What?

[NAGN]

Send snapshots of the current game state

if anything's lost, it'll be in the next update so it doesn't matter

:I

[Orpheon]

Send snapshots of the current game state

if anything's lost, it'll be in the next update so it doesn't matter

:I

Oh.

Ok.

[notajf]

Well, I was working on this. I'm just not sure how to design it. I was basically copying the Game Maker design (objects with events, speeds and sprites, and steps), but perhaps a different design is a good idea. Hmm.

[notajf]

A design I just thought of, which is probably better than what I thought of before, for objects.
Objects do not necessarily have properties. However, some have x and y, for instance.
A plain GameObject doesn't actually do anything. It can be extended to provide movement and drawing however. But as the base GameObject doesn't have any default behaviour, it means objects that are invisible don't unnecessarily waste space.

An object can register itself for the draw event so it is drawn, and provide a method to be called. It provides a z-index for sorting.
Similarly, an object can register for the begin step, step and end step events (similarly to game maker).
So, something like this:

Code: [Select]

class GameObject:
    """
    Class all game objects inherit from.
    """
    
    def __init__(self, environment):
        self.environment = environment

class MyFancyObject(GameObject):
    """
    A fancy game object!
    """

    def __init__(self, environment, x=0, y=0):
        GameObject.__init__(self, environment)
        self.x, self.y = x, y
        self.sprite = load_sprite("lol.png")
        self.environment.register_event("draw", self.draw, zindex=20)
        self.environment.register_event("step", self.step)

    def step(self):
        self.x += 2
        self.y += 3

    def draw(self, canvas):
        canvas.draw(self.sprite, self.x-self.enviroment.viewport[0], self.y-self.enviroment.viewport[1])

This isn't that different from the game maker coding style, which would make porting easier.

[Orpheon]

(click to show/hide)

Code: [Select]

import sys, os, time, random, pygame, math, socket
from pygame.locals import *
from load_image import load_image

pygame.init()

# This is to replace the gmk "all" and also to update everything.
global globalGameObjectList
globalGameObjectList = []


# All drawing should be done on the globalSurface object
global globalWindow, globalScreen

globalWindow = pygame.display.set_mode((1280, 1024))
globalSurface = pygame.display.get_surface()


global globalXview, globalYview, globalWview, globalHview

globalXview, globalYview = 0, 0
globalWview = 800
globalHview = 600


class GameObject(pygame.sprite.Sprite):

def __init__(self, xpos, ypos):

pygame.sprite.Sprite.__init__(self)

self.x = xpos
self.y = ypos

self.hspeed = 0
self.vspeed = 0

self.sprite = 0

globalGameObjectList.append(self)


def BeginStep(self):

pass


def Step(self):

pass


def EndStep(self):

self.x += self.hspeed
self.y += self.vspeed

def Draw(self):

globalSurface.blit(self.sprite, (self.rect.topleft[0]-globalXview, self.rect.topleft[1]-globalYview))



class MapObject(GameObject):

def __init__(self):

GameObject.__init__(self, 0, 0)

self.sprite, self.rect = load_image('Sprites/Maps/MapTesting2.png')



class Character(GameObject):

def __init__(self):

GameObject.__init__(self, 200, 200)

self.sprite, self.rect = load_image('Sprites/Characters/Scout/Red/ScoutRedS_fr1.png')

self.rect.center = (self.x, self.y)


def Step(self):

self.y += 2
self.rect.center = (self.x, self.y)



gameMap = MapObject()

global globalMyself
globalMyself = Character()

while True:

print globalXview

for a in range(len(globalGameObjectList)):

globalGameObjectList[a].BeginStep()

for a in range(len(globalGameObjectList)):

globalGameObjectList[a].Step()

for a in range(len(globalGameObjectList)):

globalGameObjectList[a].EndStep()

globalXview = globalMyself.x-globalWview/2
globalYview = globalMyself.y-globalHview/2

globalSurface.fill((255, 255, 255))

for a in range(len(globalGameObjectList)):

globalGameObjectList[a].Draw()

pygame.display.flip()

Though I'm wondering what would be a better language, C++ or Python.

Both have their Pros and Cons, and I'm really unsure which I should stick to.

Question Libraries, Python has Pygame, and for C++ the best option would probably be SFML (although SFML also exists for Python).


Also I'm a bit unsure as to how to manage sprites. Loading them from a file at creation is probably pretty inefficent, so we'll probably need a sprite manager or something that loads all images in memory and then just gives the images away.


And no, multiplayer doesn't have to be in from the start. Coding everything in the Character object + coding maps + coding all the weapons and classes is already a big thing that can be done (almost) completely independently of networking.

[MedO]

I just randomly noticed that there is a LUA wrapper for Game Maker, unsurprisingly called gmlua. It can apparently call into GML functions by using the dark magic of GMAPI, so a relatively tight integration between LUA and GML is possible. However, GMAPI only works with GM up to version 8.0 and doesn't seem very active, so if we did use it, we might not be able to switch to GM 8.1. GMAPI is LGPL licensed, so we could always do the porting ourselves, but I don't really feel like taking on yet another GM extension projekt at the moment.

On the upside, having coroutines could dramatically simplify the netcode. If I understand them correctly (I never actually used coroutines yet), they would allow writing netcode almost as if the calls were blocking. That is, you could have a function receiveOrYield(socket, size) that will only return once the requested ammount has been read, and in the meantime it wouldn't block the thread, but allow the game to continue running. It would also improve the possibilities of script-based modding. And if done well, the game logic might be translated to LUA bit by bit, until we only have the bare "engine" in GML, which could then be recreated in a different host language to migrate completely away from Game Maker.

I didn't spend any time actually planning this so there might be glaring flaws. Just putting it here as an idea. I still won't have time to do this kind of thing for a while now.