Pysoy Development

Tags: computer graphics, game, game engine, google, programming, pysoy, summer, technology

In this blogpost, I would like to describe the engine from a game developer’s perspective and as a general introduction to the organization and the engine itself.

What exactly does copyleftgames do?

They maintain and license games!

They maintain gaming softwares under copyleft licenses (mostly GNU AGPLv3, I guess). And I’m planning to work on Pysoy, a cloud game engine. The games are intended to run on the server and playable on multiple devices. Well, pysoy along with playerd (a service for abstacting input devices and user data) and lightmelody ( a network library for cloud games) would facilitate gaming on a wide variety of devices to which pysoy is ported to.

How do I make pysoy games?

Currently, developing games directly is pretty difficult. You will have to work more on the engine than your game itself to do so.

Get a linux machine. Download the engine (libsoy and pysoy) , build and install it. Once, installed you can import the the soy module and use it.

I won’t be discussing the installation process or any programming details here. This blogpost is an introduction to the engine itself.

A simple scene can be written in ~40 lines of code.

Understanding soy package

I would like to give an introduction some on essential submodules and classes in soy module. For further details you can always look into pydocs associated with each module/class name.

To get help on any module/class, you type python3 -c “import soy; help(soy.)” in your command window.

First, the Client. Clients in pysoy are intended to manage window creation, define context and data state of the object e.t.c. Currenty, the controllers are proposed to be managed by playerd and audio will soon be integrated as a texture to the body itself. Client instances are created locally with _soy.Client_object.

Other essential submodules of the soy package includes,

Atoms, as the name suggests are the building blocks. The data types that helps the other submodules. Atoms include Color, Position, Size, Rotation, Vector and many other essential classes.

Bodies are the objects in a scene. Matter that’s made up of atoms. They render to the scene, intercact, collide with each other. Sphere and Boxes are the obvious ones. Billboards and portals are examples of complicated bodies. Camera and Light are also considered as bodies_ (Why? You will soon understand).

Scenes are where the bodies are present. It would contain geometry, viewpoint, texture, lighting, and shading information as a description of the virtual scene as in the real world. Room is the one that’s commonly used. Depending on the gameplay, scenes can be created. Typical examples include Room, Landscape and Space.

Materials govern the appearance of bodies in a scene. Materials define how the object looks and what properties can it have. Examples include Wireframed, Textured and Colored.

Texturing is the application of a type of surface to a 3D image. Heightmaps, Cubemaps, Bumpmaps are some trivial examples. SVGs can also be mapped to a material as a texture. Future iterations of the engine would include Audio as a texture.

Widgets are the tricky ones, they define the rendering areas. Containers, Canvas and Projectors are few examples. Perhaps, Projector is the one that’s frequently used. It is used to “Project” the output of the camera to the screen. Widow objects can also be created from the Widgets submodule. They automatically create Client instances. comes

Fields effect the scenes. They manipulate the bodies inside that scene. Examples include Buoyancy, Wind e.t.c.

Joints connect bodies. They are typically used to create complex structures from primitive bodies. The anchor point of a joint is associated with that scene. Ball and Socket, Pivot e.t.c. are some examples.

Hope this post helped you in understanding how the rendering engine works. The next post would discuss the same from a development perspective.