Print

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

[Orpheon]

Here's the current source. Help is needed.

We've agreed on Python 2.7 as a main language.

Progress so far:

Hmm, let me just sum everything up.

The advantages of PyGG2:

• Python is a "real" programming language, unlike GML. This gives us a better chance to market the game to for example get it featured on steam. AKA more users.
• Python is free, unlike GML. This means that everyone can contribute code without having to "buy" Game Maker. AKA more contributors
• PyGG2 will have better performance than GG2, simply because Python is way faster than GML and the programmer is free to optimize in any way he wants. AKA more speed and less lag
• Because Python's object system is better designed for large systems than GML's and we have full control over the system it is easier to keep the code clean and maintain the game. AKA less bugs
• Because Python is faster and allows for more complex systems than GML it is easier to implement lag compensation. AKA less lag
• PyGG2 is built up from the ground allowing us to revise previous not-so-wise design decisions (major one: UDP vs TCP). AKA less lag, less bugs
• Because Python runs on every major platform, and so will PyGG2, PyGG2 can be run on Windows, Linux and Mac. AKA more users
• And by far the most important one, because PyGG2 runs on every major platform and we can run the game engine without the graphics engine in PyGG2 (we couldn't do this in GML due to the way GML works) we can run dedicated servers. AKA A HELL OF A LOT LESS LAG

The disadvantages of PyGG2:

• It takes a lot of time to develop, but Orpheon and I are working on it

Posting so I can follow, but AJF and Orph, is python easy to learn if you've had minimal Javascript, batch, and GML programming experience?

Differences between Python and GML:

(click to show/hide)

1. Indentation is important.

In GML an if loop can be all of the following:

Code: [Select]

if a==0
{
    doSomething()
}

Code: [Select]

if a==0 {doSomething()}

Code: [Select]

if a=0 doSomething()etc...

In Python there is mostly 1 valid way:

Code: [Select]

if a==0:
    doSomething()- '==' is necessary, contrarily to GML.
- How much stuff is in the if loop is determined by the indentation.

With that last sentence I mean:

Code: [Select]

if a==0:
    a = 1# This is inside the if loop

    b = 1# This too

print a, b# This isn'tAll of this is also valid for while loops.



2. Variables aren't declared.

GML 'var' does not exist in python. Variables are automatically deleted after every script, I think. Except for all the self variables (Read more in point 4).



3. Functions, not scripts.

In Python you can't simply write stuff in a script. You make a function, with 'def':

Code: [Select]

def Multiplier(a, b):
    c = a*b
    return cInside the brackets you specify the number of arguments as well as the variable they should be put into.



4. Classes in Python are a bit different from objects in GML, but overall very similar:

There are no built-in variables like x or y in a default Python class.
You define such a class by:

Code: [Select]

class MyClass():

    self.x = 0
    self.y = 0

    def Move(self, newX, newY):# New 'Method'. Function inside a class

        self.x = newX
        self.y = newY


class1 = MyClass()# Make an Instance of MyClass

a, b = 1, 1

while True:# Infinite while loop, obviously

    class1.Move(a, b)# Notice we don't give anything for the "self" variable.

    a += 1
    b += 1

Classes have a default 'constructor' event, the same thing as the GMK 'Create'. The name of this is '__init__'.
So:

Code: [Select]

class MyClass():
    def __init__(self):
        self.x = 0
        ...
Inheritance of course works. Just put inside of the class brackets the names of the classes you want to inherit from.

Code: [Select]

class MyClass():

    def __init__(self):
        self.x = 0
        self.y = 0


class MyClass2(MyClass):# Inherit everything from MyClass, in this case the self.x and self.y

    def Move(self, newX, newY):# New 'Method'. Function inside a class

        self.x = newX
        self.y = newY


class1 = MyClass2()# Make an Instance of MyClass

a, b = 1, 1

while True:# Infinite while loop, obviously

    class1.Move(a, b)# Notice we don't give anything for the "self" variable.

    print class1.x, class1.y

    a += 1
    b += 1


5. Python has infinitely better lists.

Forget ds_list. Here come real lists.

Code: [Select]

myList = []
myList[0] = 1
# myList == [1]

myList.append(2)
myList.append("Hello!")
# myList == [1, 2, "Hello!"]

myList.append([4, 5, 6])
# myList == [1, 2, "Hello!", [4, 5, 6]]

for a in myList:

    print a

I think that like covers most of the basics.


Old post:

Previous discussions:
I ported GG2 to Mac successfully!
Gang Garrison Dedicated Server (in Python)
Medo's try with JGang (and a C++ engine, if you read the thread)
Recent request about a console-based dedicated server that kinda spiralled into a discussion about this
Ajf's main thread about this (Beta tester forums)

Those are only those I just found now, I probably missed a few.


Important quotes from those discussions I followed:

(click to show/hide)

I'll skip pages and ask

Why

Why rewrite GG2 in another language?

Cross-platform (Mac, Linux, Android maybe). Not being reliant on Game Maker. Not needing a stupid GPL linking exception. Greater openness as you won't need commercial software to work on it. More efficient, less laggy multiplayer (better server architecture). Not needing stupid DLL extensions to do stuff. Actually working bgm on Linux. etc...

I'm not trying to shoot this down or anything, and it would be cool if it did happen, but this has been brought up very often in the history of this project, almost from the very beginning. Several people started projects for this (including me, twice) but nobody ever got close to completion. And doing it becomes more difficult since the game constantly grows larger, while on the other hand there is less reason for it, since gmksplitter removed (or at least reduced) one of the big drawbacks of Game Maker.

I'm just trying to say, don't underestimate the work involved.

I don't think the devs are up to redo all their years of work.

minus beta testing, map making, tweaks, bugfixes and fapping, it wouldn't take more than a week.

I understand. I think, for that reason, if I do this, I should plan it out thoroughly in advance.

Also, set a list of goals. For instance, my personal first goal is "working client and server where player can join as red querly and move around, visible to other players". That alone requires quite a bit of code, but is the important first step.

Meh. If I can get there in a not-too-long period of thime, this yet-another-rewrite project might go somewhere.

Start with the server, it would be easiest to test and if you ever decide to give up, you're still left with a functioning non-gml server

What reason do you want to use python for? Of course any language is probably better than gm, but I would think we would want to choose a language that is both development-friendly and also beneficial. Other than being faster, Python doesn't have much over what we have now.

Python is both development-friendly and beneficial. Java is neither.

I think we should use Pygame.

That's my thoughts too.

I guess it depends where we would like to go with it.

I feel like Java would be our best bet, since we can easily port it to other platforms, but C++ probably has good points.

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.

I'm taking a Python independent studies course at school, so I basically have 55 minutes every day I could use to build a dedicated server (and present it as my final project).

Although, I'm not looking into doing this on my own.

Hm well I believe it was planned to use Box2D as the central library as a start

Since Box2D is written in C++, you are expected to be experienced in C++ programming. Box2D should not be your first C++ programming project. You should be comfortable with compiling, linking, and debugging.

So we agree on C++?

Or has someone tried to port it?

I understand. I think, for that reason, if I do this, I should plan it out thoroughly in advance.

Also, set a list of goals. For instance, my personal first goal is "working client and server where player can join as red querly and move around, visible to other players". That alone requires quite a bit of code, but is the important first step.

Meh. If I can get there in a not-too-long period of thime, this yet-another-rewrite project might go somewhere.

Start with the server, it would be easiest to test and if you ever decide to give up, you're still left with a functioning non-gml server

What reason do you want to use python for? Of course any language is probably better than gm, but I would think we would want to choose a language that is both development-friendly and also beneficial. Other than being faster, Python doesn't have much over what we have now.

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

An idea about collisions:

Using masks to check would probably be too slow, so I thought we could do it like this.

Map Wallmasks would be passed at compile time in a special script that checks each pixels and creates a rect there if it is black/opaque/whatever.

This also allows us to scale the maps, which is not easy to do otherwise. Now we just have to scale the surface before drawing.

The string of rects would then be saved and embedded into the .png or even kept as separate file.

It can then be loaded without much problems and without much lag, and suddenly you have rects to collide with instead of masks.
(which, if you only check the rects in the area around the Character, is much faster)



My problem is this:

Code: [Select]

import os
import glob

import pygame
from load_image import load_image

from pygame.locals import *

surface = pygame.Surface()

path = 'Maps/'
for infile in glob.glob( os.path.join(path, '*_wm.png') ):

image, rect = load_image(infile)

# Loop through all the pixels and create a rect per black pixel

for a in range(0, ???)There is no built-in function of pygame.Image to determine it's size, so I either have to guess a very large number or get creative.
Ideas?

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.

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.

I can help for Python.

Actually, I even already started. Though I probably won't be able to compete with 55 min every day of vindi, I could help.

Also, it's much easier to start from the beginning, ignore the networking, make ctf and all the classes work (wihout the HUDs first), and then just add stuff.

The collision system could get a little complicated, people on the #pygame channel recommended me to use rects for collision (also with the wallmask), and not mask.

Speaking of which, what library are we using? Pygame, or something else?

[Mr.L]

We (I and Nagn) will take interest and participate in such a project.

We were deciding on C++ with the 2dbox engine
srry L.
NOTE THAT YOU'RE GOING TO HAVE TO INSTALL PYSFML. SINCE THIS IS AN UNSTABLE LIBRARIES, EASY TO DISTRIBUTE WAYS TO INSTALL IT IS NOT AVAILIBLE (atm).
Installers should come soon! But they're not here yet
HOW TO RUN PyGG2 ON WINDOWS

1) INSTALLING PYTHON 2.7

Download Python 2.7

Install it to "C:\Python27".
Go to "controlpanel>System>Advanced>Environment Variables".

In the "System Variables" box, click on "Path", then click "Edit".
In the "Variable Value" box, add to the end: ";C:\Python27;C:\MinGW\bin".
Click OK, then OK again in the system menu.

2) INSTALLING PIL, PySFML AND MINGW

Download and install PIL
Download and install PySFML
Download and install MinGW

3) INSTALLING PYGG2 AND BITMAP EXTENSION

Download and unzip: PyGG2

Move the folder to My Documents and rename it to "PyGG2".

Go to command prompt (start>accessories>command prompt) and type "cd " (with a space after cd).
drag the PyGG2 folder into the command prompt window and press enter.

Type in "python make.py build" and press enter.

After it is finished, exit command prompt.

4) MAKING PyGG2.bat

Go to notepad (start>accessories>notepad).

Type the following, but change <USER> to your computer's username.

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testclient (for launching the client)


Click file>save, and in the "File Name" box, type "PyGG2client.bat", and set the "Save as Type" box to "All Files".
Save it wherever you like.

Create another notepad file

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testserver (for launching the server)

Click file>save, and in the "File Name" box, type "PyGG2server.bat", and set the "Save as Type" box to "All Files".

And you're done! Whenever you want to run PyGG2 client, you just have to open PyGG2client.bat, but make sure to run PyGG2server.bat first
If you want to update PyGG2, just repeat delete the PyGG2 folder in My documents and repeat step 3.


-Orpheon: Updated it a bit-

[Vindicator]

Orpheon, if you would like to gather some people to work with python, I could help out.

[Orpheon]

@Vindicator: Would you also be available for C++? I'm not saying we have to do that, I'm just asking whether you could.

@NAGN and L: Same thing. Could you guys imagine doing it in Python?

[Super Sgt. Brown]

People, before doing teams and what-not, you should agree on which language you're going to use.

Either use C++ or Python. Not both, darn it. 

[Derpduck]

This would be a good oppertunity to learn some other languages

[Orpheon]

People, before doing teams and what-not, you should agree on which language you're going to use.

Either use C++ or Python. Not both, darn it.  

To know what language we use, we need to know who can work on it in what language.
That's the main factor in the choosing of the language.

Personally, I think I vote for Python. I know it much better than C++, and prefer it.

Also, if Flaw every re-appears, I think he'll prefer Python too.


Next question: Do we all agree on the library pygame?
Or are there other propositions?

[la granja animale]

basically speaking, this thread is all about a plan to rewrite the gg2 engine into another language?

[trog]

basically speaking, this thread is all about a plan to rewrite the gg2 engine into another language?

It's not like that's the thread title or anything...

[Mr.L]

The pythons that's ok too though I want to work on C++, but I'm mediocre at both so no real preferences.

Isn't pygame the python sdl library?

[Orpheon]

The pythons that's ok too though I want to work on C++, but I'm mediocre at both so no real preferences.

Isn't pygame the python sdl library?

Ok, great.

And yes, it is.

[Mr.L]

I love you Orpheon.

[Maxaxle]

I don't mean to be rude, but what's the upshot of this? Faster compiling? Stability? Fewer glitches?

[Mr.L]

Well for starters it will be much more portable os wise and it will use a more powerful language.

[Saniblues]

Game Maker has to translate gml to a programming language the computer actually supports since gml isn't an accepted language on any operating system. I don't remember the exact order, or how many times it has to be translated for that matter, but the point is that with say, Java, you only have to do it once before reaching machine language.

Think of it like trying to translate Arabic to Japanese, then Korean, then Spanish before translating it to English. It'd be easier to just translate it from Spanish to English.

Java is universally accepted on most operating systems, so you can have it on multiple computers, even handheld devices if you want to get your hands dirty. It'd probably run faster too. C++ is in the same boat, which one is the better choice depends on the people making it. Rendering speed is debatable, but we'd be able to freely use vector graphics without having to worry about people with weaker vista computers since vectors in Game Maker is awful for some reason.