Skip to content
New issue

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

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

Already on GitHub? # to your account

More complete Player example #76

Open
Kenoshen opened this issue May 2, 2024 · 3 comments
Open

More complete Player example #76

Kenoshen opened this issue May 2, 2024 · 3 comments

Comments

@Kenoshen
Copy link
Member

Kenoshen commented May 2, 2024

It would be nice if the player class was fleshed out a bit more with things like multiple animations, sound effects, keyboard and gamepad controls, etc. So when you start up a new project you are not starting (almost) from scratch with the player class.

Maybe go so far as to have multiple player classes for different types of games (platform, topdown, etc)

@MondayHopscotch
Copy link
Member

I wonder if there's a clean way to have slightly different templates for different styles of games. Maybe in branches? Not sure how you'd keep that stuff in sync. Maybe we could do something like have this base 'template' project, and have some other small repos that have all the starter code for various types of games. So you make a repo from this template and 'select' your genre and it clones down all the genre specific starter stuff from that other repo. It would keep this repo clean and generic, while also allowing us a super quick jumping off point. I'll have to think on this for a while.

@Kenoshen
Copy link
Member Author

Kenoshen commented May 9, 2024

Ya, trying to manage the different flavors of game in a single repo seems complex whether they all live on the same branch, different branches, forks. Yuck. But using separate repos seems like it might be even worse since any "generic" update to the template would have to be done in both places as well. But maybe "generic" updates would be better handled in util libraries instead of directly in the project itself. So that way you don't have to update the code in each genre project, you just update the libraries that the genre projects depend on?

@MondayHopscotch
Copy link
Member

Yeah, the current process, which I think I like is basicaly:

  1. Use the flixel-utils repo
  2. if changes are needed, make a branch (named after the jam, such as ld55, or whatever)
  3. After the jam is done, we have a nice clean set of commits for things we wanted to change and can clean things up and merge them into master for the next jam

But yes, I'm also still thinking of a good way to give us jumping off points for different genres.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants