Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle multiple "Scenes" - Wiki Improvement #209

Open
ryanadean opened this issue Dec 2, 2019 · 4 comments
Open

How to handle multiple "Scenes" - Wiki Improvement #209

ryanadean opened this issue Dec 2, 2019 · 4 comments

Comments

@ryanadean
Copy link

Loving the library. I made a shift from Godot to this for the simple reason that learning 2+ more languages (gdscript, godot's glsl-esque shading language) and/or using their compiled implementations ended up slowing development down, and causing more headaches than it solved.

With that said, one area that I am failing to see much documentation on, which I think is a pretty fundamental concept in game design is handling "scene" switching, though pixel tries not to be heavy handed in implementation approach, A simple pattern for these basic operations may not be a bad thing.

@faiface
Copy link
Owner

faiface commented Dec 2, 2019

Hey, that's great to hear! I'd like to also bring Ebiten to your consideration of libraries because it's more actively maintained and has support for more platforms (mobile and web in particular). However, if you're happy with Pixel, I love it :)

Regarding your question, yeah, you're correct. As I'm currently more focused on other projects and school, I'm not sure I have the time to write a full wiki article, however, a simple pattern would look like this:

type Scene interface {
	Loop(w *pixelgl.Window) string // returns the name of the next scene
}

scenes := map[string]Scene{
	"menu": MenuScene,
	"game": GameScene,
	...
}

currentScene := "menu"
for !w.Closed() {
	currentScene = scenes[currentScene].Loop(w)
	w.Update()
}

Of course, this would be improved into something more sophisticated over time. The main reason Pixel doesn't have this built-in and that there is no wiki article is because I'm not sure a single pattern would fit most games. But, I may be completely wrong on this one, so if you know a better pattern that would work for most games, let me know!

@rishavs
Copy link

rishavs commented Dec 22, 2019

I would recommend using scene-Object-component system like unity and other game engines do. Here is a nice tut on doing it with go-sdl . I am sure something similar can be used in a pixel project.

@steelx
Copy link

steelx commented Jan 4, 2020

@faiface Thanks for making Pixel. I switched from Ebiten to Pixel. I thought this is more active and better. So far I have no issues with Pixel.
Few things I like more about Pixel are:

  • Pixel uses base Go packages. makes it easy to use.
  • pixel Vec, Rect
  • Additional option of canvas render
  • Pixel examples. I learn how to load tilemaps, learned to add Animation frames from examples given
  • A good Wiki.

BEST part: Easy to debug with GoLand

But yes, go community lacks basic guides. I did not had any Game Dev background, but learning process is a big task at the moment.

Hope you or some experts in Go gaming share more guides and update wiki :)

I have just written a small guide with Pixel. just sharing my learning.

***This guys is making tutorials on Pixelgl
https://dbriemann.github.io/blog/label-making-a-game.html

@bunyk
Copy link

bunyk commented Feb 26, 2023

Interesting how this pattern would look like if scenes would need to send additional data to each other. For example, menu scene maybe would want to send selected game map (level) and difficulty level to game scene. Then game scene would want to send score to game end scene.

That's easy in dynamically typed languages, but what here? Coming from web/microservices background, I'm thinking to keep string, but put all that in JSON like:

{
    "scene": "game",
    "params": {
        "difficulty": 1,
        ....
    }
}

But it does not feel right to marshall and parse JSON in every frame. Maybe interface{} for payload, and type assertions when initializing scene would work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants