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

Organization #7

Open
Sogolumbo opened this issue Apr 16, 2021 · 8 comments
Open

Organization #7

Sogolumbo opened this issue Apr 16, 2021 · 8 comments

Comments

@Sogolumbo
Copy link
Contributor

Sogolumbo commented Apr 16, 2021

Let's organize ourselves better. Currently we are both coding but we are

  1. working on the same problems and
  2. not easily able to merge because we both don't have a nice commit history or feature branches.

Also let's put thoughts and TODOs into issues instead of #TODO comments.

@bydariogamer
Copy link
Owner

I will add everything in issues from now on. You can also join the pygame community server if you want to read some players opinions (most of them will not give us feedback here sadly).

@Sogolumbo
Copy link
Contributor Author

Please make sure to put your changes in separate commits based on their topic and consider feature branches whenever there will be some experimenting to do (e.g. stars).

@bydariogamer
Copy link
Owner

Okey... I will do a 'map generation' branch so you can PR anything there (I will probably accept as long as it doesn't lag the game or introduces bugs) and I will make a new 'aesthetic' branch for some minor changes like stars, the ground animation I plan to do and any other idea that comes with that.

@bydariogamer
Copy link
Owner

You can use dt = clock.tick(BASE_FPS) to get the time since last tick, instead of using the current system. (Yea, pygame.time.Clock.tick is a function that controls time and has a return).

@Sogolumbo
Copy link
Contributor Author

I know about that. But it seems to me like there's not really an advantage in using that one over the clock.

When I decided to choose the clock I was not confident that the tick function would return reliable results (the documentation said it was less accurate than some other function).
Now I am much more confident but I don't think there's any need to change it.

@Sogolumbo
Copy link
Contributor Author

I didn't want you to add feature branches for my pull requests. I wanted them so that your commits would be better sorted and easier for me to merge into my fork.

@Sogolumbo
Copy link
Contributor Author

As far a I know the concept of a dev branch is to make no commits straight in the master branch and only merge into the master from the dev branch.
The commit "fixed highscores" in the master branch raises problems because it's not compatible with the code in your dev branch. Either the code in that code needs to be merged into the dev branch or it needs to be overriden by the changes coming from the dev branch.
Otherwise there will be merge conflicts in every new merge and pull request

@bydariogamer
Copy link
Owner

I think it will de overrode by dev. It was a bad idea to commit to main directly, sorry...

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

No branches or pull requests

2 participants