Forking Shader 7 into 7 & 8
Forking Shaders
www.tinyurl.com/BOMB-CODE
Shader 7 will be the base of shader 8.
Reasoning? We are __NOT__ finished with the work
I wanted to do for shader #7 , but this looks
really cool and seems like it could be useful.
I know if visual is only accessable by turning on the
correct debug flags, it will just get burried and
forgotten about. I know from exprience.
So the visuals we currently have for shader #7
we are going to STICK with. The rest of the
work we had planned will be done in shader #8
by copying everything we have, pasting it into
shader #8 , and then diverging to two pieces
of shader code from one another.
Once we fork the two shaders , we need to remember
to make the current rendering method in shader 7
the PRODUCTION METHOD. Right now the render for
shader 7 you see in this video is from a
DEBUG BLOCK of code.
Heroku won't be free for much longer, so we might
want to halt shader 8 work until we have successfully
deployed our project to google app engine.
There is also a thing called "render.com"...
But... I am betting AGAINST render.com one it's
shitty name alone. Like, how am I supposed to
google for stuff with a generic name like that?
I am not saying "RENDER.com" is bad. Just that
"discoverability" has a __HUGE__ impact on success.
If I assume that what I am doing is awesome as fuck,
which I do think that, then the reason I only have
31 subscribers is because of discoverability problems.
That or... No one knows what the fuck I am doing because
my videos are so concise that they don't advertise
"Hey Guys I am making an MMO from Scratch In JavaScript!"
I am trying to plug that message at the beginning of
new videos however. But it will probably be 2 months
before new videos where I am doing that are released.
This 2 months delay might hurt my ability to quickly
pivot and react to feedback.
Reminds me of "The beer problem" in the book...
"The Seventh System" ... Is that what it is called?
"Understanding Systems Thinking" maybe?
Here is the beer problem :
https://readingraphics.com/understanding-systems-thinking-the-beer-game/
-KanjiCoder
Shader 7 will be the base of shader 8.
Reasoning? We are __NOT__ finished with the work
I wanted to do for shader #7 , but this looks
really cool and seems like it could be useful.
I know if visual is only accessable by turning on the
correct debug flags, it will just get burried and
forgotten about. I know from exprience.
So the visuals we currently have for shader #7
we are going to STICK with. The rest of the
work we had planned will be done in shader #8
by copying everything we have, pasting it into
shader #8 , and then diverging to two pieces
of shader code from one another.
Once we fork the two shaders , we need to remember
to make the current rendering method in shader 7
the PRODUCTION METHOD. Right now the render for
shader 7 you see in this video is from a
DEBUG BLOCK of code.
Heroku won't be free for much longer, so we might
want to halt shader 8 work until we have successfully
deployed our project to google app engine.
There is also a thing called "render.com"...
But... I am betting AGAINST render.com one it's
shitty name alone. Like, how am I supposed to
google for stuff with a generic name like that?
I am not saying "RENDER.com" is bad. Just that
"discoverability" has a __HUGE__ impact on success.
If I assume that what I am doing is awesome as fuck,
which I do think that, then the reason I only have
31 subscribers is because of discoverability problems.
That or... No one knows what the fuck I am doing because
my videos are so concise that they don't advertise
"Hey Guys I am making an MMO from Scratch In JavaScript!"
I am trying to plug that message at the beginning of
new videos however. But it will probably be 2 months
before new videos where I am doing that are released.
This 2 months delay might hurt my ability to quickly
pivot and react to feedback.
Reminds me of "The beer problem" in the book...
"The Seventh System" ... Is that what it is called?
"Understanding Systems Thinking" maybe?
Here is the beer problem :
https://readingraphics.com/understanding-systems-thinking-the-beer-game/
-KanjiCoder
Comments
Post a Comment