rust-gamedev / rust-gamedev.github.io Goto Github PK
View Code? Open in Web Editor NEWThe repository for https://gamedev.rs
Home Page: https://gamedev.rs
License: Apache License 2.0
The repository for https://gamedev.rs
Home Page: https://gamedev.rs
License: Apache License 2.0
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #336)
The soft deadline for all section PRs is 2021.01.06
Current structure/status (I'll try to keep this updated):
Final steps:
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter on Monday, so a soft deadline for all section PRs is Saturday.
Current structure/status (I'll try to keep this updated):
Final steps:
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #336)
The soft deadline for all section PRs is 2020.12.03.
Current structure/status (I'll try to keep this updated):
Final steps:
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter on 2020.09.07, so a soft deadline for all section PRs is 2020.09.05.
Current structure/status (I'll try to keep this updated):
Final steps:
The articles are getting long and are organized in multiple sections. It is probably worth having a table of contents at the top or on the side. Example for this week:
I know that there's an open PR for the start of an ecosystem guide, but since this is one of our goals before the next meeting I wanted to have a general discussion and get people's thoughts about the subject without totally clogging up the review of kvark's specific PR.
The general subject of this issue is anything related to the gamedev-wg doing an ecosystem guide.
Assuming that we do make an ecosystem guide, I feel compelled to ask: What format should such a guide take?
Combined, these two items make me want to back up and ask: Do we make an ecosystem guide at all?
My conclusion from these facts: Either we have to change the charter at least a bit (not an action to be taken lightly!!) or we can't have an ecosystem guide that is usefully different from AreWeGameYet, and we probably shouldn't do a separate guide at all. Instead, we should just direct people to work on AreWeGameYet.
Thoughts on this? Or thoughts on anything else about the subject of an Ecosystem Guide?
I propose publishing the first newsletter on September 2. After its release, I'm going to strip it down to a bare-bones template (like it's done in embedded WG, for example) and add it to the repo so we can start working in the second newsletter.
In #9 (comment) I've partly mentioned how the collective newsletter creation process could be organized, at what publishing dates we are aiming, etc. This workflow question is closely linked to the creation of the next newsletter and it needs to be discussed and documented (in README, I guess), so I'm going add this to the PR too.
Related to #2 ("Newsletter")
Hi, I think there is a typo in the link to the "Library & Tooling Updates" section of the table of contents.
https://rust-gamedev.github.io/posts/newsletter-010/#library--tooling-updates
Where it should be:
https://rust-gamedev.github.io/posts/newsletter-010/#library-tooling-updates
Hey everyone! We're starting to change out the lead editor of the newsletter each month, so that the workload isn't so much each month. This month, it's me! I'm Forest, or AngelOnFira. I also edit the weekly blogs for Veloren, co-host the Rust Gamedev Podcast, and run the monthly Rust Gamedev meetup.
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #336)
The deadline for all section PRs is 2021.03.04 2021.03.06.
Review will take place on 2021.03.07
Release will be done on 2021.03.08
Only one image (<300kb) or GIF (<2.5mb) before the text. With an optional caption and a mandatory alt text.
All the (rendered) text should be under 1000 characters (including spaces and punctuation) and under 6 paragraphs (without any subsections, etc).
No bold/italic/etc formatting - only links and one plain list without nesting per section.
Third-person perspective.
80 chars per MD line and no other markdownlint warnings on CI.
Only the following simple templates are allowed:
For games/apps/libs:
# [Gamename]
![alt text](img)
_optional image label_
[Gamename] ([GitHub], [Discord], [Twitter]) by [@nickname]
is ... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
For articles/videos/etc:
# [Articlename]
![alt text](img)
_optional image label_
[@nickname] published an [article] about ...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
CONTRIBUTING.md
isn't updated for this yet.
(I'll try to keep this updated)
If you have your own project that you want to write about, just make a comment on this issue!
Final steps:
Editors: @ozkriff @17cupsofcoffee @AngelOnFira
We don't have a policy regarding job offer posts yet and there was some negative feedback about the job ads in previous newsletter issues.
from the WG channel on Discord:
aclysma: I have mixed feelings about a hiring post being the first thing on the newsletter
ozkriff: why? seems like important information to me: opportunities to work on graphics stuff using Rust/wgpu are quite rare atm
aclysma: commercial entities have a natural advantage over non-commercial in marketing.. and the focus being on their company hiring someone instead of how their company is pushing rust game development forward seems more to serve their company's interests than the communities interest
I'm certainly not saying a hiring post has no value to the community or that it shouldn't be included, I'd just rather see the top spot go to something that's in service to the community rather than the other way around
If it was a video of some cool new features with an oh-btw-we're-hiring blurb at the end (i.e. the focus being on showing something new and interesting) then my opinion would probably be different
ozkriff: Will it be better if i swap the hiring section with london talks?
aclysma: I think it would
or pick a game update to move up
XAMPPRocky: I also agree with moving the job offer down, reading it, it felt like a ad to me.
So I propose adding an optional first-level "Jobs" section (between "Requests for Contribution" and "Bonus"). Any thoughts/opinions/objections? :)
Minima's _base.scss
file resets the margin of the <hr>
tag to zero:
rust-gamedev.github.io/_sass/minima/_base.scss
Lines 4 to 7 in 8dab245
And it results in that Markdown's horizontal line ------
sticks to the next line uncomfortably close:
With this brute-force patch:
$ git diff _sass/
diff --git a/_sass/minima/_base.scss b/_sass/minima/_base.scss
index db7d5a1..cac4ba7 100644
--- a/_sass/minima/_base.scss
+++ b/_sass/minima/_base.scss
@@ -37,6 +37,7 @@ body {
h1, h2, h3, h4, h5, h6,
p, blockquote, pre,
ul, ol, dl, figure,
+hr,
%vertical-rhythm {
margin-bottom: $spacing-unit / 2;
}
it looks much better to me:
But I'm note sure if that's the correct way of doing it.
@ozkriff: Given that Mun posts updates just about every month, might it be a good idea to move the logo into
static
and reuse it between posts, like we do for Amethyst?
Given that Mun posts updates just about every month, might it be a good idea to move the logo into static and reuse it between posts, like we do for Amethyst?
@17cupsofcoffee well, we're not that much consistent about that logo :)
$ find content static -name amethyst-logo.png content/posts/newsletter-013/amethyst-logo.png content/posts/newsletter-009/amethyst-logo.png content/posts/newsletter-004/amethyst-logo.png content/posts/newsletter-008/amethyst-logo.png content/posts/newsletter-010/amethyst-logo.png content/posts/newsletter-006/amethyst-logo.png static/amethyst-logo.png $ g grep amethyst-logo.png content/posts/newsletter-001/index.md:![amethyst logo](/amethyst-logo.png) content/posts/newsletter-002/index.md:![amethyst logo](/amethyst-logo.png) content/posts/newsletter-003/index.md:![amethyst logo](/amethyst-logo.png) content/posts/newsletter-004/index.md:![Amethyst logo](amethyst-logo.png) content/posts/newsletter-006/index.md:[![Amethyst logo](amethyst-logo.png)][Amethyst] content/posts/newsletter-008/index.md:[![Amethyst logo](amethyst-logo.png)][amethyst] content/posts/newsletter-009/index.md:[![Amethyst logo](amethyst-logo.png)][amethyst] content/posts/newsletter-010/index.md:[![Amethyst logo](amethyst-logo.png)][amethyst] content/posts/newsletter-013/index.md:![logo](amethyst-logo.png)
and I'm still not sure how I feel about using static for reusing images - i don't like that it breaks normal markdown previews. Maybe we should try creating a special directory inside
content
and use relative paths there? something like![amethyst logo](../../shared/amethyst-logo.png)Relative paths up aren't that cool too, but it seems like a lesser evil to me.
(comments from #292)
Editors: @ozkriff, @AngelOnFira, and @17cupsofcoffee
Another month has gone by, so it's time to put together the Rust Gamedev newsletter with September news!
If you want to help writing the newsletter:
source
branch (example: #336)
As with the last few newsletters, we're trying to delegate the writing workload where we can - to quote @AngelOnFira from a few months ago:
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
The soft deadline for all section PRs is the 5th of October. PRs will usually be accepted as long as they are ready before the newsletter's release, but the earlier the better :)
Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]
![alt text](img)
_optional image label_
[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_
[Game name]: http://example.com
Articles/blog posts/videos/etc:
### [Article name]
![alt text](img)
_optional image label_
[@nickname] published an [article] about...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
[Article name]: http://example.com
Below is a list of our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhastive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!
Final steps:
The newsletter survived its first year so I hope this site is here to stay. it's time to finally rent a "real" domain, I guess.
This question has been raised a few times on WG's discord, but I don't recall any specific decisions/conclusions from them.
The best free URL that comes to my mind is https://game-dev.rs - what do you think?
Somewhat related to rust-gamedev/arewegameyet#261 ("Make .rs domain primary?")
(Bikeshedding time)
The current draft of the newsletter is titled as "This Month in Rust GameDev #1 - August 2019". At least @Lokathor (and @AlexEne?) aren't happy with this, so I'm creating this issue to document the discussion and decide if we want to change the title.
Discussion so far (from the newsletter PR):
<...> Let's call it the September issue, just being released a little early this time around since it's the first one.
Why? I've called it "This Month in Rust GameDev #1 - August 2019" because it describes what happened during August.
Isn't that how newsletters are named usually? https://amethyst.rs/posts/activity-report-july-2019 by @erlend-sh, for example, is called "Activity Report - July 2019" and tells about July's events but is released at the beginning of the next month.
I suppose, in publishing "the Tuesday paper" is the newspaper that was released Tuesday morning, not that's released after Tuesday describing Tuesday.
(another monthly newsletter naming precedent from TiKV and from rustsim)
@Lokathor Hmm, calling it a September newsletter still feels a little bit wrong to me, but I'm not a native speaker, so I've I created a small poll in Discourse
wg-gamedev
channel and will change the naming scheme if an alternative will be chosen:
^ Btw, the third option is to not mention a month in the title at all (like embedded, CLI, and some other WGs do), but it has its own cons.
Poll results so far are
and this question doesn't look like a PR blocker to me (because it's a draft and can be renamed before publishing), which is why I propose merging this PR (so other people can send PRs with content) and creating a separate issue about the title.
<...>
From and "gamedev-wg" Discord chat:
Here's the thing: it's not a newsletter that's purely about august events
like, a lot of events will happen and then only sometimes you'll get updates about "what's been happening recently"
like, if an event was in July but didn't get attention, would you deny it a place in a newsletter issue once the article did get written? that's silly
hmm, that's what the "Bonus" section is for
I guess really it's just how normal publishing works for newspapers and magazines and things like that: you call the September Issue the one that comes out at the start of September, you call the Thursday Paper the one that you get Thursday morning, and so on
And then usually you talk about what's happening recently but sometimes you talk about older stuff too
it's not a critical issue
so once we have a newsletter we can just put it out
Related to #2 ("Newsletter")
Atm, the twitter preview is quite boring:
It may be worth to investigate additional meta tags a little to make it look nicer:
https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary
We need a way to communicate status, news and other things.
The first idea I have is a site like https://rustwasm.github.io/ or any of the other wgs
Editors: @AngelOnFira, @17cupsofcoffee, and @ozkriff
Another month has gone by, so it's time to put together the Rust Gamedev newsletter for August!
If you want to help writing the newsletter:
source
branch (example: #336)
As with the last few newsletters, we're trying to delegate the writing workload where we can - to quote @AngelOnFira from a few months ago:
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
The soft deadline for all section PRs is the 5th of September. PRs will usually be accepted as long as they are ready before the newsletter's release, but the earlier the better :)
Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]
![alt text](img)
_optional image label_
[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_
[Game name]: http://example.com
Articles/blog posts/videos/etc:
### [Article name]
![alt text](img)
_optional image label_
[@nickname] published an [article] about...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
[Article name]: http://example.com
Below is a list of our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhastive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!
Final steps:
Same as rust-gamedev/arewegameyet#289
It was mentioned on https://github.com/rust-gamedev/wg/issues/10 that we might want to have an introduction post talking about what the WG has been up to so far. Figured it might be a good idea to start a discussion on what that might look like ๐
Some ideas/thoughts:
Editors: @17cupsofcoffee, @AngelOnFira, and @ozkriff
Another month has gone by, so it's time to put together the Rust Gamedev newsletter for July! (hey that kinda rhymed this month)
If you want to help writing the newsletter:
source
branch (example: #336)
As with the last few newsletters, we're trying to delegate the writing workload where we can - to quote @AngelOnFira from a few months ago:
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
The soft deadline for all section PRs is the 7th of August. PRs will usually be accepted as long as they are ready before the newsletter's release, but the earlier the better :)
Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]
![alt text](img)
_optional image label_
[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_
[Game name]: http://example.com
Articles/blog posts/videos/etc:
### [Article name]
![alt text](img)
_optional image label_
[@nickname] published an [article] about...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
[Article name]: http://example.com
Below is a list of our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhastive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!
Final steps:
I'm hoping to publish the newsletter on 2019.03.03.
The newsletter will be published on 2019.03.04.
The newsletter will be published on 2019.03.05 for sure.
If you want to help writing the newsletter:
source
branch (example: #49)
Current status/structure (I'll try to keep this updated):
TODOs:
Editors: @17cupsofcoffee, @ozkriff and @AngelOnFira
Another month has gone by, so it's time to put together the Rust Gamedev newsletter for April!
If you want to help writing the newsletter:
source
branch (example: #336)
As with the last few newsletters, we're trying to delegate the writing workload where we can - to quote @AngelOnFira from a few months ago:
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
The soft deadline for all section PRs is the 6th of May. PRs will usually be accepted as long as they are ready before the newsletter's release, but the earlier the better :)
Review and release will take place around the 8th of May.
Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]
![alt text](img)
_optional image label_
[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_
[Game name]: http://example.com
Articles/blog posts/videos/etc:
### [Article name]
![alt text](img)
_optional image label_
[@nickname] published an [article] about...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
[Article name]: http://example.com
CONTRIBUTING.md
isn't updated for this yet.
Below is a list of our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhastive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!
Final steps:
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter on 2020.10.06, so the soft deadline for all section PRs is 2020.10.04.
The newsletter will be published on 2020.10.07.
Current structure/status (I'll try to keep this updated):
Final steps:
So, I'm struggling with editing and releasing the newsletter in its current format and workflow - it takes something like 40 to 50 pure hours every month to collect all the news, talk with all the people, prepare the plan and coordination issue, review/edit/merge PRs, write what's left, prepare the final draft, and publish it.
Thus, it'd be cool to reduce the bus factor and delegate the editing/merging responsibilities. But it doesn't seem like delegating the editing responsibilities as-is will work well - most of the contributors are struggling to follow the guidelines from CONTRIBUTING.md and there's only one person who regularly helps woth incoming PRs reviews.
As I see it, there're two ways to solve this:
I still believe that for a collective and periodic project of this scale consistency is extremely important, so I concentrated my thoughts on the second option and this is what I come up with:
The lead editor is rotated from the pool every month and is responsible for:
Non-lead editors help with PRs reviews and can edit and merge correct/fixed PRs themselves - if something is off in the merged PRs the lead editor can still fix it during the preparation of the final draft.
The requirements for merging a PR are reduced to something like:
# [Gamename]
![alt text](img)
_optional image label_
[Gamename] ([GitHub], [Discord], [Twitter]) by [@nickname]
is ... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
# [Articlename]
![alt text](img)
_optional image label_
[@nickname] published an [article] about ...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
Atm, @17cupsofcoffee and @AngelOnFira agreed to join the editors team.
If there're no objections, I'd like to try the new rules and workflow starting with the current newsletter: the coordination issue for the 18th newsletter will be created this evening.
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter on 2020.08.03/04, so a soft deadline for all section PRs is Saturday (2020.08.01).
Current structure/status (I'll try to keep this updated):
Final steps:
Quoting from #4:
@ozkriff:
Maybe the background shouldn't be blue? Or the emojis should be removed/changed. It looks a little bit weird with red emojis without an outline of my system's font:@17cupsofcoffee:
Hm, yeah, that's unfortunate - on Windows 10 they have nice black borders:If we can't rely on them looking vaguely consistent across platforms, they should probably be removed/replaced. I only really put them there because I was jealous of the WASM WG's hard-hat Ferris :p
I'm not particularly attached to the blue either, picking out color schemes has never really been my strong suit. As long as whatever we choose passes the Chrome accessibility audit, I'm happy.
@zicklag:
I think you should be able to make the display consistant if you provide a downloadable font and set that as the font-family. That way every system uses the same icons instead of each one using its system default.Also, there might be a way to extract the SVG from a font and put SVG icons in there instead.
While trying to make a better way to show youtube videos, there was a discussion in #71. It was discussed that it is ideal to stay purely with markdown so that we can see what files look like directly from Github.
It would be nice to have content such as images and gifs be displayed in a bit of a cleaner way in the end product. A big one is centering images, as well as spacing around content. I think this can be done purely through CSS. I think it will really make the newsletter more presentable. I would love to hear other opinions!
Are we sure want to use Jekyll generator? I'm ok if we decide to stay with it, but want to make sure that it was seriously considered.
My only functional issue with Jekyll so far is that it requires to store posts and assets (images) in separate directories. That's not a critical thing, but it's a site of Rust working group and it seems a little bit weird to me not to use excellent rusty tools when we can.
Sorry for raising this a little bit too late when the first post is already published, but I'm a little bit worried that it will be difficult to migrate (if we finally decide to) after a few more posts.
Zola seems to work fine for another working group's site - https://github.com/rust-embedded/blog and also for @17cupsofcoffee's (https://seventeencups.net) and my (https://ozkriff.games) blogs.
Feel free to suggest sections about any March rust gamedev news and updates!
If you want to help writing the newsletter:
source
branch (example: #336)
Quoting @AngelOnFira from the last month's coordination issue:
<...>
We're going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end 100 This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it free free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list smile
The soft deadline for all section PRs is 2021.04.06.
Review and Release will take place on 2021.04~~.08~~ .09 .10.
Only one image (<300kb) or GIF (<2.5mb) before the text. With an optional caption and a mandatory alt text.
All the (rendered) text should be under 1000 characters (including spaces and punctuation) and under 6 paragraphs (without any subsections, etc).
No bold/italic/etc formatting - only links and one plain list without nesting per section (multiple lists are allowed if your project consists of multiple parts that aren't independent enough for their own sections).
Third-person perspective.
80 chars per MD line and no other markdownlint warnings on CI.
Only the following simple templates are allowed:
For games/apps/libs:
### [Gamename]
![alt text](img)
_optional image label_
[Gamename] ([GitHub], [Discord], [Twitter]) by [@nickname]
is ... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
For articles/videos/etc:
### [Articlename]
![alt text](img)
_optional image label_
[@nickname] published an [article] about ...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
CONTRIBUTING.md
isn't updated for this yet.
If you have your own project that you want to write about, just make a comment on this issue!
(I'll try to keep this updated)
Final steps:
Editors: @ozkriff @17cupsofcoffee @AngelOnFira
Feel free to suggest sections.
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter in the beginning of the next week, so a soft deadline for all section PRs is Sunday.
Current structure/status (I'll try to keep this updated):
Final steps:
It would be great to start a (monthly?) newsletter for summarizing what interesting stuff happens in the rust gamedev ecosystem.
Examples of newsletters from other rust WGs:
Related to rust-gamedev/wg#10 ("Create a rust-gamedev.github.io site")
Currently, a line-length
lint is enabled and set to 80 chars. In #638 @Keavon proposed to get rid of it:
@Keavon: this be a good place to propose we get rid of the nonsensical linter requirement for a line length limit in markdown files? It's seriously quite a pain and provides no benefit.
@17cupsofcoffee: I'm not particularly attached to the line length limit (and if we do keep it, it might make sense to bump it up to 120 characters or something like that), but will see what the other maintainers think.
@Keavon: Since 120 characters is shorter than a paragraph, that wouldn't really be an improvement. Let's stick to proposing no limit.
I don't agree that the current limit is nonsensical - it's an ancient question with no universally right answer that fits for all projects. In my personal experience, lengthy versioned and collectively reviewed/edited Markdown files with no line limit were quite annoying. Also, following to semantic line wrapping seems to ease the downsides of strict line limits a lot. Lots of similar projects (the official Rust blog, Veloren blog, etc) seem to come to the same conclusion.
So I'd prefer to keep the limit (as it simplifies versioning, reviewing, and collective editing) but if there're a lot of contributors who hate it then it might be worth considering switching it off (or raising the limit to 100 or 120 chars).
What do you think?
There are more and more rust engines popping up and the Library & Tooling Updates category is getting quite full, mixing big fully-featured engines with small purpose-build libraries. Have you considered splitting it into 2 categories - one for engines, another for tools and small libraries?
Editors: @AngelOnFira, @17cupsofcoffee, and @ozkriff
Another month has gone by, so it's time to put together the Rust Gamedev newsletter for May!
If you want to help writing the newsletter:
source
branch (example: #336)
As with the last few newsletters, we're trying to delegate the writing workload where we can - to quote @AngelOnFira from a few months ago:
We're also going to be transitioning to having authors or volunteers write about their own content, rather than the editing team doing it all at the end ๐ฏ This means if you want to see your work in the newsletter, you have to write it yourself! If you're not able to write about your work, feel free to comment and I can assign it ๐ free. We're working on taking some of the load off the editing team where we can with this. Best to keep this sustainable!
Also, we want to make sure contributing to the newsletter feels open to anyone who wants to write a section about their project. If you have anything you can write about, just add a comment to this issue and I'll add it to the todo list ๐
The soft deadline for all section PRs is the 6th of June. PRs will usually be accepted as long as they are ready before the newsletter's release, but the earlier the better :)
Review and release will take place around the 8th of June.
Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]
![alt text](img)
_optional image label_
[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_
[Game name]: http://example.com
Articles/blog posts/videos/etc:
### [Article name]
![alt text](img)
_optional image label_
[@nickname] published an [article] about...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
[Article name]: http://example.com
Below is a list of our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhaustive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!
Final steps:
See getzola/zola#1442 (comment)
Basically I get this error when trying to build with Zola 0.14.1 on both Windows 10 and WSL2:
Error: Failed to render section '[...]\rust-gamedev.github.io\content\_index.md'
Reason: Failed to render 'index.html'
Reason: Variable `config.default_language` not found in context while rendering 'index.html'
Even though the "default_language" is clearly present in config.toml:
title = "Rust GameDev WG"
description = "Stay up to date with the progress and recent developments in the Rust Game Development Working Group."
base_url = "https://gamedev.rs/"
default_language = "en"
compile_sass = true
highlight_code = true
generate_feed = true
feed_filename = "rss.xml"
...
I'm not sure if this is a Zola issue, or an issue with the newsletter, so I'm opening it on both issue trackers.
Update: changing config.default_language
to lang
in index.html seems to fixes the issue.
If you want to help writing the newsletter:
source
branch (example: #75)
Feel free to suggest sections.
Current structure/status (I'll try to keep this updated):
Final steps:
I've published my game : Le Train Dispatcher
http://athorus.itch.io/ltd
I would be glad and proud if you could talk about this game in your next newsletter. I did not yet promote it. I'm looking for contributors.
If you need some information or materials, let me know if I can help you.
Feel free to comment my work, even though it is not nice, I need that to improve the game.
Thanks for your works.
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #336)
The deadline for all section PRs is 2021.02.03.
Only one image (<300kb) or GIF (<2.5mb) before the text. With an optional caption and a mandatory alt text.
All the (rendered) text should be under 1000 characters (including spaces and punctuation) and under 6 paragraphs (without any subsections, etc).
No bold/italic/etc formatting - only links and one plain list without nesting per section.
Third-person perspective.
80 chars per MD line and no other markdownlint warnings on CI.
Only the following simple templates are allowed:
For games/apps/libs:
# [Gamename]
![alt text](img)
_optional image label_
[Gamename] ([GitHub], [Discord], [Twitter]) by [@nickname]
is ... {short project description in one sentence}.
{An overview of the recent updates with links to more details}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
For articles/videos/etc:
# [Articlename]
![alt text](img)
_optional image label_
[@nickname] published an [article] about ...
{overview what the resource is about}.
_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_
{md links block}
CONTRIBUTING.md
isn't updated for this yet.
(I'll try to keep this updated)
Final steps:
Editors: @ozkriff @17cupsofcoffee @AngelOnFira
I noticed while working on the most recent newsletter that the size of the repo is starting to get a bit unwieldy - a fresh clone is 800MB (half of which is the index, half of which is the actual files).
Not only does this make it more of a pain for people to contribute, there is a hard 1GB limit on published GitHub Pages sites which we're eventually going to hit. The index wouldn't factor into that though (I hope...), so I don't think we're in imminent danger.
In general, Git is just not a good solution for storing lots of binary content, and I think we'll need to deal with this eventually if the newsletter is going to stick around long term (which I hope it does!)
Some potential fixes could be:
Fix | Pros | Cons |
---|---|---|
Stop accepting GIFs (they take up the majority of the repo's space) | Only a policy change, not a technical one. | Would only slow down the issue, not fix it. |
Move to a different hosting solution with a higher size cap (Netlify?) | Wouldn't need changes to the site or to the workflow. | Doesn't solve the repo size issue long term. |
Host images externally (maybe on a CDN?) | Wouldn't need changes to the site, minimal change to the workflow. | Might make it more difficult for people to submit images. |
Move away from Git-based hosting altogether | Might be easier to edit the site through a CMS instead of markdown. | Would require us to rethink the whole contribution workflow. |
Something else I've not thought of? | ??? | ??? |
Don't think we need to deal with this immediately, but just wanted to start the conversation sooner rather than later ๐
@jeffvandyke:
I just came from Newsletter #1 - very nice! I think some folks (including me) would appreciate a email subscription option like This Week In Rust does (twitter and reddit updates don't show up in my inbox). Perhaps whatever email service they use could be adopted for rust-gamedev?@17cupsofcoffee:
They apparently use MailChimp for this - their free plan only allows up to 2000 subscribers, however, and they already surpassed that in 2016, so they must be on one of the paid ones.I think this is definitely a good idea, but we'd need to either find a service with a more generous free plan and/or figure out a plan for how it'd be paid for.
@phaazon:
That makes me think I should really have an RSS stream on my websiteโฆ I need to check how to do that.
(Extracted from #2)
https://rustgamedev.com/episodes Saw this and was surprised that it wasn't included in the newsletter already, then realized it was brand new. Haven't actually listened to it yet though, so maybe it's not good. XD Will listen to it and see how it is.
Feel free to suggest sections!
If you want to help writing the newsletter:
source
branch (example: #75)
The soft deadline for all section PRs is 2020.11.04.
Current structure/status (I'll try to keep this updated):
Final steps:
Feel free to suggest sections.
If you want to help writing the newsletter:
source
branch (example: #75)
I'm hoping to release this newsletter in the middle of the next week, so a soft deadline for all section PRs is Wednesday.
Ok, now I'm hoping to have a final fraft on Sunday and publish it on Monday.
Current structure/status (I'll try to keep this updated):
Final steps:
Related to #30 ("CI: Add markdownlint check")
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.