194 karma · joined April 23, 2015
Former CTO at https://stitch.money
Hobbyist game developer: http://ncthbrt.itch.io/
For example we have configured our implementation of OpenID Connect to use PKCE for retrieving an authorization code, and then when calling the token endpoint, requires that the the client authenticate using a client_assertion JWT (as detailed in https://tools.ietf.org/html/rfc7523#section-2.2)
Also a lot of useful 3d content creation software is Windows only, or only supports CUDA acceleration, so implicitly rules out Mac from being a first class citizen (e.g. substance painter)
Obviously not every game is the same, or needs fancy tooling. But Windows feels like it just works for game dev.
Think it's a mistake to consider GraphQL as a drop-in replacement for REST, writing a vanilla GraphQL server is indeed quite arduous as there is a lot of important concerns like auth that you don't get out the box.
But if you're just wanting to expose your database in a controlled and secure manner, with a smattering of business logic, think some of the technologies that have evolved around GraphQL like Hasura and PostGraphile can make it a joy to use.
Think the wonder is that the schema definition language/schema introspection wasn't just tacked on at the end (unlike REST w/ Swagger and OpenAPI) so all these tools have developed around the tech. There is also a bit less of an object relational mismatch than in REST.
But what about corporate taxes, what about things like the game engine getting a cut (often an additional 5%), etc?
Apple Developers end up getting a slice of a slice.
That 30% is large enough to make whole business models unviable. You need 30% more sales or raise prices commensurately. That's a lot.
You'll probably have to spend more on customer acquisition to achieve those numbers as well as you start to eat into the long tail of customers. This eats into profits.
The cut probably also impacts the quality of experience, particularly for things like freemium games, as you need to monetize more aggressively to make up for the Apple tax.
I actually think that unless your company is massive or has a lot of expertise in GraphQL already, using it for private APIs may not be the best idea, as it could be a sign of certain internal dysfunctions or communication problems within or between engineering teams.
----
An example, however of the kind of filtering I was referring to, and why I still think it would be non trivial to do, even in something like ASP.NET, is the following: https://www.gatsbyjs.org/docs/graphql-reference/#filter. This of course isn't something you get out the box in GraphQL either, but the structure of the system made this (relatively) easy to do.
Of course you could add something like OData to your REST API which would definitely be a valid alternative, but that also would have its own warts, and is subject to similar criticisms as GQL.
As someone who is building a public facing GraphQL API, I would disagree with this. Directives make it easy to add policies to types and fields in the schema itself, making it amenable to easy review.
A restful API also has the problem that if you want fine grained auth, you'll need to remember to add the policy to each controller or endpoint, so not that different.
The typed nature of GraphQL offers a way of extending and enriching behavior of your API in a very neat, cross cutting way.
For example we recently built a filtering system that introspected over collection types at startup to generate filter input types. We then built middleware that converted filter inputs into query plans for evaluation.
I previously worked at another company that offers a public REST API for public transport. Public transport info is quite a rich interconnected data set. Despite efforts to ensure that filtering was fairly generic, there was a lot of adhoc code that needed to be written to handle filtering. The code grew exponentially more complex as more filters were added. Maybe this system could have been architected in a better way, but the nature of REST doesn't make that exactly easy to do.
Bottom line is that I feel for public APIs, that there is a lot of demand for flexibility, and eventually a public facing RESTful API will grow to match or even exceed that of a GraphQL API in complexity.
Would highly suggest adding more visuals and some way of very easily playing with runnable demos. Games are inherently audiovisual artifacts, so the lack of audiovisuals on the site is a bit of a negative signal.
Possibly to the engine's detriment (though a cottage industry of add-ons in the assert store has helped bridge the most serious gaps)
For instance there is still the mention of lodging Form ADV Part 2A Brochure with the SEC. If you have not done so, this may be in fact a fraudulent claim and could get you in trouble later on.
Unsure if that is significant, actively misleading, or simply coincidence. I'd lean towards the former given that both are apparently registered with the SEC, though my confidence bounds here are quite wide as I am not sufficiently knowledgeable of the rules behind company names in the US.
A final possibility that I've only just considered is that this disclosure was (poorly) copied from a16z's website.
An engine like unity basically provides utilities such as physically based rendering, camera systems, visual editors, scripting environments, a scenegraph editor, preview windows, io, asset import and conversion, audio, etc. Some games are of course easier to make than others in such engines, but they aren't that prescriptive.
That you're using a handrolled engine is fine, I'm sure your company knows what they're doing. But in the context of this post, and for people who'd like to start game development/design, saying that most devs write their own engine is in my opinion damaging, as I really don't think that most smaller studios do. It increases the barrier to entry, and perpetuates a certain amount of elitism, which really considering the make up of the industry is no help at all.
Unfortunately, yes. I would've liked to have seen support for netstandard rather than a particular runtime, I worried that it means people will get sloppy and just target whatever their web framework is targeting.
You've luckily got three plus years of support, so hopefully in that time you'll be able to make a plan about 3rd party dependencies.
This is more like a major library dropping support for a legacy runtime going forward.