engo

Engo is an open-source 2D game engine written in Go.

1,744

136

1,744

View on GitHub

Top Related Projects

ebiten

10,770

Ebitengine - A dead simple 2D game engine for Go

pixel

4,448

A hand-crafted 2D game library in Go

raylib-go

1,540

Go bindings for raylib, a simple and easy-to-use library to enjoy videogames programming.

Quick Overview

Engo is an open-source 2D game engine written in Go. It provides a simple and efficient framework for developing cross-platform games, leveraging the power and simplicity of the Go programming language. Engo is designed to be lightweight and easy to use, making it suitable for both beginners and experienced game developers.

Pros

Cross-platform support (Windows, macOS, Linux, and Web)
Built-in ECS (Entity Component System) architecture for efficient game development
Good documentation and examples for getting started
Active community and ongoing development

Cons

Limited 3D support (primarily focused on 2D games)
Smaller ecosystem compared to more established game engines
Steeper learning curve for developers not familiar with Go
Less extensive tooling and editor support compared to larger game engines

Code Examples

Creating a basic game scene:

type MainScene struct {
    engo.World
}

func (*MainScene) Preload() {}

func (*MainScene) Setup(u engo.Updater) {
    w := u.(*engo.World)
    engo.Input.RegisterButton("jump", engo.KeySpace)
}

func (*MainScene) Type() string { return "MainScene" }

func main() {
    opts := engo.RunOptions{
        Title:  "My Game",
        Width:  800,
        Height: 600,
    }
    engo.Run(opts, &MainScene{})
}

Adding a sprite to the game:

type SpriteSystem struct {
    world *ecs.World
}

func (s *SpriteSystem) New(w *ecs.World) {
    s.world = w
    texture, _ := common.LoadedSprite("assets/sprite.png")
    entity := s.world.CreateEntity()
    entity.AddComponent(&common.RenderComponent{
        Drawable: texture,
        Scale:    engo.Point{X: 1, Y: 1},
    })
    entity.AddComponent(&common.SpaceComponent{
        Position: engo.Point{X: 100, Y: 100},
        Width:    texture.Width(),
        Height:   texture.Height(),
    })
}

func (s *SpriteSystem) Update(dt float32) {}

func (s *SpriteSystem) Remove(ecs.BasicEntity) {}

Handling user input:

type InputSystem struct {
    world *ecs.World
}

func (s *InputSystem) New(w *ecs.World) {
    s.world = w
}

func (s *InputSystem) Update(dt float32) {
    if engo.Input.Button("jump").JustPressed() {
        // Handle jump action
    }
}

func (s *InputSystem) Remove(ecs.BasicEntity) {}

Getting Started

To start using Engo, follow these steps:

Install Go (version 1.16 or later)
Install Engo:
```
go get -u github.com/EngoEngine/engo
```
Create a new Go file (e.g., main.go) and import Engo:
```
import "github.com/EngoEngine/engo"
```
Implement a basic scene and run the game (see the first code example above)
Build and run your game:
```
go build
./your_game_executable
```

For more detailed instructions and examples, refer to the official Engo documentation.

Competitor Comparisons

ebiten

10,770

Ebitengine - A dead simple 2D game engine for Go

Pros of Ebiten

More active development and larger community support
Better performance, especially for mobile platforms
Simpler API, making it easier for beginners to get started

Cons of Ebiten

Less built-in functionality compared to Engo's ECS architecture
Limited to 2D game development, while Engo supports both 2D and 3D

Code Comparison

Ebiten example:

type Game struct{}

func (g *Game) Update() error {
    // Update game logic
    return nil
}

func (g *Game) Draw(screen *ebiten.Image) {
    // Draw game elements
}

Engo example:

type MyScene struct {
    engo.World
}

func (*MyScene) Preload() {
    // Load resources
}

func (*MyScene) Setup(u engo.Updater) {
    // Initialize systems and entities
}

Ebiten focuses on a simple game loop with Update and Draw methods, while Engo uses an Entity-Component-System architecture with more structured scene management. Ebiten's approach is more straightforward for simple games, but Engo's ECS design can be beneficial for larger, more complex projects.

pixel

4,448

A hand-crafted 2D game library in Go

Pros of Pixel

Simpler API and easier learning curve for beginners
More lightweight and focused on 2D graphics
Better performance for simple 2D games

Cons of Pixel

Less comprehensive feature set compared to Engo
Lacks built-in ECS (Entity Component System)
Fewer community-contributed extensions and plugins

Code Comparison

Pixel:

win, err := pixelgl.NewWindow(pixelgl.WindowConfig{
    Title:  "Pixel Rocks!",
    Bounds: pixel.R(0, 0, 1024, 768),
})

Engo:

opts := engo.RunOptions{
    Title:  "Engo Game",
    Width:  1024,
    Height: 768,
}
engo.Run(opts, &myScene{})

Both Pixel and Engo are Go-based game development libraries, but they cater to different needs. Pixel is more focused on 2D graphics and provides a simpler API, making it easier for beginners to get started. It offers better performance for simple 2D games but lacks some advanced features.

Engo, on the other hand, provides a more comprehensive game development framework with built-in ECS and a wider range of features. It's better suited for larger, more complex games but may have a steeper learning curve.

The code comparison shows the difference in setting up a window. Pixel's approach is more straightforward, while Engo's setup involves creating a scene and using the RunOptions struct.

oak

1,541

A pure Go game engine

Pros of oak

More active development with recent updates and commits
Extensive documentation and examples available
Built-in support for collision detection and resolution

Cons of oak

Less flexible entity-component system compared to engo
Steeper learning curve for beginners
Limited cross-platform support (primarily focused on desktop)

Code Comparison

oak:

func (g *Game) Init() {
    oak.Add("scene",
        entities.NewPlayer(),
        entities.NewEnemy(),
    )
}

engo:

func (g *Game) Setup(w *ecs.World) {
    engo.Input.RegisterButton("jump", engo.KeySpace)
    w.AddSystem(&systems.RenderSystem{})
    w.AddSystem(&systems.PlayerSystem{})
}

Both oak and engo are game engines written in Go, but they have different approaches to game development. oak provides a more opinionated structure with built-in features like collision detection, while engo offers a more flexible entity-component system. oak has more recent development activity and extensive documentation, making it potentially easier for newcomers to get started. However, engo's flexibility may be preferred by developers who want more control over their game architecture. The code comparison shows how scene setup differs between the two engines, with oak using a more straightforward approach and engo utilizing a more modular system setup.

raylib-go

1,540

Go bindings for raylib, a simple and easy-to-use library to enjoy videogames programming.

Pros of raylib-go

More comprehensive and feature-rich, offering a wider range of graphics and audio capabilities
Better performance due to its C-based backend
Larger community and more frequent updates

Cons of raylib-go

Steeper learning curve, especially for developers new to game development
Less idiomatic Go code, as it's a wrapper around a C library
Potentially more complex setup due to C dependencies

Code Comparison

engo:

systems := &engo.World{
    ComponentSystem: &engo.ComponentSystem{},
    RenderSystem:    &engo.RenderSystem{},
}
engo.Run(engo.RunOptions{
    Title:  "My Game",
    Width:  800,
    Height: 600,
}, systems)

raylib-go:

rl.InitWindow(800, 600, "My Game")
defer rl.CloseWindow()

for !rl.WindowShouldClose() {
    rl.BeginDrawing()
    rl.ClearBackground(rl.RayWhite)
    rl.DrawText("Hello, World!", 190, 200, 20, rl.Black)
    rl.EndDrawing()
}

Both libraries provide game development capabilities in Go, but raylib-go offers a more comprehensive set of features at the cost of complexity, while engo provides a simpler, more Go-idiomatic approach with potentially less performance.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Engo

A cross-platform game engine written in Go following an interpretation of the Entity Component System paradigm. Engo is currently compilable for Mac OSX, Linux and Windows. With the release of Go 1.4, supporting Android and the inception of iOS compatibility, mobile has been be added as a release target. Web support (wasm) is also available.

v1.0 is now available! To celebrate, there will be a game jam coming soon to celebrate the release, start actually building things and hopefully find any issues. Updates for this will come soon.

Getting in touch / Contributing

We have a gitter chat for people to join who want to further discuss engo. We are happy to discuss bugs, feature requests and would love to hear about the projects you are building!

Getting Started

Theory: `common` vs `engo`

There are currently two major important packages within this repository: github.com/EngoEngine/engo and github.com/EngoEngine/engo/common.

The top level engo package contains the functionality of creating windows, starting the game, creating an OpenGL context and handling input. It is designed to be used with Systems designed as per github.com/EngoEngine/ecs specifications. The common package contains our ECS implementations of common game development Systems like a RenderSystem or CameraSystem.

Practice: Getting it to Run

First, you have to install some dependencies:
If you're running on Debian/Ubuntu: sudo apt-get install libasound2-dev libglu1-mesa-dev freeglut3-dev mesa-common-dev xorg-dev libgl1-mesa-dev git-all
If you're running on Windows you'll need a gcc compiler that the go tool can use and have gcc.exe in your PATH environmental variable. We recommend Mingw since it has been tested. You'll also need git installed, we recommend getting it from The official Git site
If you're on OSX, you will also need Git. You can find instructions here. You can also use homebrew to install git as well. Open an issue if you have any issues
Then, you can go get it: go get -u github.com/EngoEngine/engo
You may also want to get the dependencies of platform specific builds, so that build tools like godef can use them: go get -u -tags js ./... go get -u -tags android ./...
Now, you have two choices:
Visit our website, which hosts a full-blown tutorial series on how to create your own game, and on top of that, has some conceptual explanations;
Check out some demos in our demos folder.
Finally, if you run into problems, if you've encountered a bug, or want to request a feature, feel free to shoot us a DM or create an issue.

Breaking Changes Since v1.0

Engo is always undergoing a lot of optimizations and constantly gets new features. However, this sometimes means things break. In order to make transitioning easier for you, we have a list of those changes, with the most recent being at the top. If you run into any problems, please contact us at gitter.

TMXObject Width and Height is in pixels, and can be fractional. This has changed from an int to a float64.
TMXTileset now uses a Spritesheet instead of a Texture. This helps keep track of the guid better and allows the gid to not start at zero and have skips in it, as well as for borders and spacing in the tile sheet.
TMX Level's objects have all been rolled into Object rather than have separate things like "PolyLineObject". This is to be consistent with the TMX format.
The Shader interface now has a SetCamera(*CameraSystem) method. This method allows shaders to automatically update the camera system as it changes, such as between scenes or when the camera system is added.
The domain engo.io has expired. Now use github.com/EngoEngine/engo as the import path, and the site can be located at engoengine.github.io

Roadmap to v1.1

A list of issues for v1.1 can be found here. There's always room for improvement! Feel free to submit proposals, open issues, and let us know how we can improve!

History

Engo, originally known as Engi was written by ajhager as a general purpose Go game engine. With a desire to build it into an "ECS" game engine, it was forked to github.com/paked/engi. After passing through several iterations, it was decided that the project would be rebranded and rereleased as Engo on its own GitHub organization.

Credits

Thank you to everyone who has worked on, or with Engo. None of this would be possible without you, and your help has been truly amazing.

ajhager: Building the original engi, which engo was based off of
paked: Adding ECS element, project maintenance and management
Newbrict: Font rendering, TMX support
EtienneBruines: Rewriting the OpenGL code, maintenance and helping redesign the API
otraore: Adding in GopherJS support, maintenance
Everyone else who has submitted PRs or issues over the years, to any iteration of the project

These are 3rd party projects that have made engo possible.

The original engi game engine which engo was based off of (BSD license)
Oto, a low-level cross-platform library to play sound. The AudioSystem uses this and is based on the audio package used in Ebiten.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Code Examples

Getting Started

Competitor Comparisons

Pros of Ebiten

Cons of Ebiten

Code Comparison

Pros of Pixel

Cons of Pixel

Code Comparison

Pros of oak

Cons of oak

Code Comparison

Pros of raylib-go

Cons of raylib-go

Code Comparison

Convert designs to code with AI

README

Engo

Getting in touch / Contributing

Getting Started

Theory: common vs engo

Practice: Getting it to Run

Breaking Changes Since v1.0

Roadmap to v1.1

History

Credits

Top Related Projects

Convert designs to code with AI

Theory: `common` vs `engo`