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

Add Haxe Game Development #1573

Merged
merged 7 commits into from
Sep 25, 2019
Merged

Add Haxe Game Development #1573

merged 7 commits into from
Sep 25, 2019

Conversation

Dvergar
Copy link
Contributor

@Dvergar Dvergar commented May 28, 2019

https://github.com/dvergar/awesome-haxe-gamedev

This is a list of resources for game development in the haxe language.

PR Review 1 : #1563 (comment)
PR Review 2 : #1538 (comment)

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

Requirements for your pull request

  • Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
  • You have to review at least 2 other open pull requests.
    Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
  • You have read and understood the instructions for creating a list.
  • This pull request has a title in the format Add Name of List.
    • Add Swift
    • Add Software Architecture
    • Update readme.md
    • Add Awesome Swift
    • Add swift
    • Adding Swift
    • Added Swift
  • Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.
    • - [iOS](…) - Mobile operating system for Apple phones and tablets.
    • - [Framer](…) - Prototyping interactive UI designs.
    • - [iOS](…) - Resources and tools for iOS development.
    • - [Framer](…)
    • - [Framer](…) - prototyping interactive UI designs
  • Your entry should be added at the bottom of the appropriate category.
  • The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

  • Has been around for at least 30 days.
    That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
  • Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
  • Includes a succinct description of the project/theme at the top of the readme. (Example)
    • Mobile operating system for Apple phones and tablets.
    • Prototyping interactive UI designs.
    • Resources and tools for iOS development.
    • Awesome Framer packages and tools.
  • It's the result of hard work and the best I could possibly produce.
    If you have not put in considerable effort into your list, your pull request will be immediately closed.
  • The heading title of your list should be in the following format: # Awesome Name of List
    • # Awesome Swift
    • # Awesome Web Typography
    • # awesome-swift
    • #
  • Non-generated Markdown file in a GitHub repo.
  • The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
  • Not a duplicate. Please search for existing submissions.
  • Only has awesome items. Awesome lists are curations of the best, not everything.
  • Includes a project logo/illustration whenever possible.
    • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
    • The image should link to the project website or any relevant website.
    • The image should be high-DPI. Set it to maximum half the width of the original image.
  • Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
  • Includes the Awesome badge.
    • Should be placed on the right side of the readme heading.
      • Can be placed centered if the list has a centered graphics header.
    • Should link back to this list.
  • Has a Table of Contents section.
    • Should be named Contents, not Table of Contents.
    • Should be the first section in the list.
    • Should only have one level of nested lists, preferably none.
  • Has an appropriate license.
    • That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
    • WTFPL and Unlicense are not acceptable licenses.
    • If you use a license badge, it should be SVG, not PNG.
    • To verify that you've read all the guidelines, please add comment with just the word unicorn.
  • Has contribution guidelines.
    • The file should be named contributing.md. Casing is up to you.
  • Has consistent formatting and proper spelling/grammar.
    • The link and description are separated by a dash.
      Example: - [AVA](…) - JavaScript test runner.
    • The description starts with an uppercase character and ends with a period.
    • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
  • Doesn't include a Travis badge.
    You can still use Travis for list linting, but the badge has no value in the readme.
  • Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

@sindresorhus
Copy link
Owner

Thanks for making an Awesome list! 🙌

It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

@missmatsuko
Copy link

missmatsuko commented Jun 8, 2019

Some missing items:

  • Name of the PR should be "Add Awesome Haxe Gamedev" "Add Haxe Gamedev"
  • The description in the README should be a succinct description of the project/theme. So describe what Haxe is rather than saying it's a list of Haxe Gamedev resources.
  • To verify that you've read all the guidelines, please add comment with just the word unicorn.
  • The URL in the code change is incorrect. It links to the Minecraft list.
  • The title in the code change should be "Awesome Haxe Gamedev" "Add Haxe Gamedev"

The list doesn't follow the formatting specified in the PR template, but maybe a table is OK?

@Dvergar
Copy link
Contributor Author

Dvergar commented Jun 10, 2019

  • Name of the PR should be "Add Awesome Haxe Gamedev"

The guidelines says This pull request has a title in the format "Add Name of List". and while my list is indeed called "Awesome Haxe Gamedev", examples in the guidelines seem to omit the "Awesome" word.

  • The description in the README should be a succinct description of the project/theme. So describe what Haxe is rather than saying it's a list of Haxe Gamedev resources.

Updated.

  • The URL in the code change is incorrect. It links to the Minecraft list.

Damn it, just changed it.

  • The title in the code change should be "Awesome Haxe Gamedev"

I don't get this one.

@missmatsuko
Copy link

The guidelines says This pull request has a title in the format "Add Name of List". and while my list is indeed called "Awesome Haxe Gamedev", examples in the guidelines seem to omit the "Awesome" word.

Sorry, I didn't mean to include "Awesome" in my comment. Based on the examples in the instructions, I think "name of list" refers to the part that comes after "Awesome".

What I meant to say was, the name of the list is inconsistent between the list repo's README, the PR, and the commit to the list:

  • PR: "Haxe game development"
  • Repo's README: "Haxe Gamedev"
  • Commit: "Haxe Game Development"

So pick either "Gamedev" or "Gamer Development" instead of using both.
I think it's supposed to be title-cased in all these as well.

@Dvergar Dvergar changed the title Add Haxe game development Add Haxe Game Development Jun 10, 2019
@Dvergar
Copy link
Contributor Author

Dvergar commented Jun 10, 2019

Ok went for "Haxe Game Development" for those three.

@Dvergar
Copy link
Contributor Author

Dvergar commented Jun 11, 2019

unicorn

readme.md Outdated Show resolved Hide resolved
@zoidyzoidzoid zoidyzoidzoid mentioned this pull request Jul 4, 2019
@sindresorhus
Copy link
Owner

The image should link to the project website or any relevant website.


The image should be high-DPI. Set it to maximum half the width of the original image.


The description of Haxe in your readme should be slightly more descriptive than just:

A curated list game development resources for Haxe, the cross-platform toolkit.

Explain why it's awesome for game development. Also linkify the word Haxe to its website.

@Dvergar
Copy link
Contributor Author

Dvergar commented Jul 12, 2019

@sindresorhus
Copy link
Owner

Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

There are still inconsistencies. Like yes and Yes.

Not clear what hum means.


Don't include useless stuff, for example:

_ | HaxeFlixel | Built-in.
-- | -- | --

It has absolutely no information.

@rafaskb
Copy link
Contributor

rafaskb commented Aug 10, 2019

This is a good list with precious resources, but I find it somewhat confusing to read through, its format is very different than most awesome lists, including the root one.

  • Banner image should be centered or full width.
  • Inconsistency between list's title and repo name (Awesome Haxe Game Development vs awesome-haxe-gamedev)
  • Too many references everywhere about Haxe3 resources, when the list is about "game development resources for the new Haxe 4".
  • All these tables make the list very hard to read. Most of the columns could be converted to icons at the end of each description, while others could be removed entirely, like Doc in Game Engines.
  • Too many references to unmaintained resources. Awesome lists should be a curated collection of the best of the bests, not a list of everything available.

These are mostly formatting issues, but the content of the list seems good! I'm a big fan of Haxe, so I hope to see this list improved in the future. 😄

rafaskb added a commit to rafaskb/awesome that referenced this pull request Aug 10, 2019
https://github.com/rafaskb/awesome-libgdx#readme

LibGDX is a powerful game framework in Java, similar to the one used by Minecraft. This list is a curated collection of resources, add-ons, and guides to help LibGDX developers make awesome games.

-----

✅ By submitting this pull request I confirm I've read and complied with the below requirements 🖖
✅ Review at least 2 other open pull requests
✅ - PR Review 1: sindresorhus#1589 (comment)
✅ - PR Review 2: sindresorhus#1573 (comment)
✅ Pull request's title follows the requested format.
✅ Include a short description about the project/theme of the list.
✅ Your entry should be added at the bottom of the appropriate category.
✅ Your list has been around for at least 30 days.
✅ Run awesome-lint and fix the reported issues. (Other than the false positives.)
✅ The repo name of your list should be in lowercase slug format.
✅ The heading title of your list should be in title case format.
✅ Non-generated Markdown file in a GitHub repo.
✅ The repo should have awesome-list & awesome as GitHub topics.
✅ Not a duplicate. Please search for existing submissions.
✅ Only has awesome items. Awesome lists are curations of the best, not everything.
✅ Includes a project logo/illustration whenever possible.
✅ Entries have a description.
✅ Includes the Awesome badge.
✅ Has a Table of Contents section.
✅ Has an appropriate license. (CC0)
✅ Has contribution guidelines.
✅ Has consistent formatting and proper spelling/grammar.
✅ Doesn't include a Travis badge.
✅ Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme.
@rafaskb rafaskb mentioned this pull request Aug 10, 2019
@Dvergar
Copy link
Contributor Author

Dvergar commented Aug 29, 2019

Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

There are still inconsistencies. Like yes and Yes.

Fixed all of these.

Not clear what hum means.

Changed it to "small".

Don't include useless stuff, for example:

_ | HaxeFlixel | Built-in.
-- | -- | --

It has absolutely no information.

Agreed, updated.

  • Banner image should be centered or full width.

I think I read that a specific resolution was needed and that half that size had to be set.

  • Inconsistency between list's title and repo name (Awesome Haxe Game Development vs awesome-haxe-gamedev)

We already discussed it earlier.

  • Too many references everywhere about Haxe3 resources, when the list is about "game development resources for the new Haxe 4".

Haxe 4 was a little bit in some python2 vs python3 situation so i felt it was needed to be aware of the situation library-wise.

  • All these tables make the list very hard to read. Most of the columns could be converted to icons at the end of each description, while others could be removed entirely, like Doc in Game Engines.

The idea was actually the opposite, readability. If a new layout is really required i can change it but is it really ? I felt like "doc" was actually a relevant information.

  • Too many references to unmaintained resources. Awesome lists should be a curated collection of the best of the bests, not a list of everything available.

I'm not listing everything, for some really niche categories i dig a bit further, but my requirements for listing something is, my own experience, the popularity of the library, freshness and legacy when it's relevant. My list isn't supposed to be static, i'm updating it, i give some libraries a chance and if it's abandoned, it's removed. "Unmaintained" for me just means that it has been a big library and that it's relevant for study purpose.

@sindresorhus
Copy link
Owner

Fixed all of these.

No, there are still more. For example, haxe should be Haxe. haxe3 should be Haxe 3.


I felt like "doc" was actually a relevant information.

There should be no Doc column as if an entry says No there, it should not be included. If it has no docs, it's definitely not awesome.

And if you don't have the Doc column, there's really no point in using a table for those entries, as you only have two columns, and then a list would be more readable.


The description starts with an uppercase character and ends with a period.

This is not consistently followed.


Armory is an open-source 3D game engine with full Blender integration.

Don't mention the library name in the description. This could be:

An open-source 3D game engine with full Blender integration.

Same applies to many other descriptions.


I think I read that a specific resolution was needed and that half that size had to be set.

You don't have to "think you read". The requirements are right at the top of this thread:

Either centered, fullwidth, or placed at the top-right of the readme.

So in this case, center it (while still having it half width, of course).


I agree with the other commenter. Haxe 3 is not the purpose of this list. If you want to mention Haxe 3 resources, I think you should create a separate Markdown file for that. It could have the same structure and categories, but only Haxe 3 stuff.


Generally, I think this list needs more work.

@Dvergar
Copy link
Contributor Author

Dvergar commented Sep 24, 2019

  • Removed the Haxe 3 references.
  • Removed the "doc" column and undocumented libraries.
  • Fixed descriptions : casing + period.
  • Removed redundant library names.
  • Centered the banner

I kept the table but i'm willing to change the layout if necessary.

@sindresorhus sindresorhus merged commit e778477 into sindresorhus:master Sep 25, 2019
@sindresorhus
Copy link
Owner

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

Successfully merging this pull request may close these issues.

6 participants