9,788 karma · joined June 18, 2007
I work at Drawlabs Game Studio where I make web games, mobile games and game middleware from network servers/clients to stats tracking and community tools for contract, white label and internal products.
http://drawlabs.com
I work with and have worked at 2XL Games, SupaSupa Games, Cheyenne Mountain Entertainment, and Prizelogic / eMarketingInc / Nomadic Agency making web, interactive, mobile (iPhone/iPad/iPod/iOS/Android) and multi-platform desktop games, apps, web interactives, APIs and tools for entertainment/promotion.
"There is no subject more captivating, more worthy of study, than nature. To understand this great mechanism, to discover the forces which are active, and the laws which govern them, is the highest aim of the intellect of man." -- Nikola Tesla
http://drawk.com/
http://drawlogic.com/
https://github.com/drawcode
http://www.linkedin.com/in/drawk
http://stackoverflow.com/users/71690/ryan-christensen
Maybe the solution is a lower level API (current) and a higher level API (somewhat stateful/named but not so global). That does add extra weight though.
Think of a wired network (TCP) vs radio/television broadcast (UDP). There really never was a "connection" it is just a logical concept/abstraction that means an endpoint can be reached, when no data is sent/received there is no connection.
Broadcast or UDP is a "connection" but more like a tuner. UDP datagrams are sent out and don't need to be ACK'd and may never be received, they just broadcast to where you tell them to go. They might even be received out of order where you can discard previous ones if they aren't needed. Note: You can do Reliable UDP and ACK any important messages with a UDP datagram back. Most highly available real-time systems and games use UDP with some sprinkle of RUDP when needed. Example: player positions or actions across the level don't matter to you, can be received and rendered or not. Global state like level starting, level ending, you want to ACK those back to unify the simulation on important states. Any critical message you mark for ACK thus the "reliable" part, it also handles discarding out of order messages which happens with UDP broadcast.
Wired or TCP is more like a stream and has a "connection" and handles all the ordering, verification and ACK backs for you. This has lots of overhead and isn't great for gaming beyond like turn based or simple networking, it works great for sending a web page or file though because all parts are necessary.
Streaming or SCTP-like it really RUDP with more standards around it. It is a combination of the TCP where needed and UDP and can be direct or broadcast.
All types of "connections" are really virtual/logical connections not actual connections.
Gaffer on Games also has some great overviews on these topics and is a must read like Beej's.
https://gafferongames.com/categories/game-networking/
This article on "virtual connections" may help you grok it.
https://gafferongames.com/post/virtual_connection_over_udp/
Reliable UDP started to be popular with enet and RakNet, and is the basis of most good networking systems and netcode today.
https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco...
enet
RakNet
http://www.jenkinssoftware.com/
WebRTC is also UDP based and can do RUDP, also uses lots of the NAT/punchthrough techniques from RakNet and others
I suppose it depends on where you place the camera, on the player like tom7 "WolfNEStein 3D" or from a viewpoint far enough back to view a portion of the level like 3dsen.
3dsen approach is more playable and is really neat for depth in 3d and VR. Could be cool in AR as well.
WebGL and WebGPU also show some of the difference in how rendering libraries have evolved. They used to be all "stateful" global state like OpenGL/OpenGL ES. WebGL followed that model as it was simple and needed for the time, but could have bugs if correct flags weren't set.
WebGPU and other newer rendering libraries (Vulkan, Metal, and Direct3D 12) are more "modern" in that they have almost no global state. They are also more raw and lower level and take a bit more to grok.
This is one of the best overviews of the differences between WebGL/WebGPU but also is similar to how OpenGL to Vulkan, Metal, and Direct3D 12 evolved.
https://webgpufundamentals.org/webgpu/lessons/webgpu-from-we...
> The biggest difference is WebGL is a stateful API and WebGPU is not. By that I mean in WebGL there is a bunch of global state. Which textures are currently bound, which buffers are currently bound, what the current program is, what the blending, depth, and stencil settings are. You set those states by calling various API functions like `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc…, and they stay what you set them globally until you change them to something else.
> By contrast, In WebGPU there is almost no global state. Instead, there are the concepts of a pipeline or render pipeline and a render pass which together effectively contain most of the state that was global in WebGL. Which textures, which attributes, which buffers, and all the various other settings. Any settings you don’t set have default values. You can’t modify a pipeline. Instead, you create them and after that they are immutable. If you want different settings you need to create another pipeline. render passes do have some state, but that state is local to the render pass.
> The second-biggest difference is that WebGPU is lower level than WebGL. In WebGL many things connect by names. For example, you declare a uniform in GLSL and you look up its location
> `loc = gl.getUniformLocation(program, 'nameOfUniform')`;
> Another example is varyings, in a vertex shader you use `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in the fragment shader you declare the corresponding varying naming it `v_texcoord`. The good part of this is if you mistype the name you’ll get an error.
> WebGPU, on the other hand, everything is entirely connected by index or byte offset. You don’t create individual uniforms like WebGL, instead you declare uniform blocks (a structure that declares your uniforms). It’s then up to you to make sure you manually organize the data you pass to the shader to match that structure.
> Note: WebGL2 has the same concept, known as Uniform Blocks, but WebGL2 also had the concept of uniforms by name. And, even though individual fields in a WebGL2 Uniform Block needed to be set via byte offsets, (a) you could query WebGL2 for those offsets and (b) you could still look up the block locations themselves by name.
> In WebGPU on the other hand EVERYTHING is by byte offset or index (often called ‘location’) and there is no API to query them. That means it’s entirely up to you to keep those locations in sync and to manually compute byte offsets.
For a time, supporting four rendering engines did cause lots of work for game engines, much more integration and abstraction.
As OpenGL support fades at least one will drop off. I will miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL ES / WebGL in particular opened up mobile/web gaming in ways never before possible. Prior to that you had Director (3D), Flash (Papervision/Away3D/etc), Silverlight and more recently `<canvas>`. Canvas is great for smaller games but you need raw power for rendering 3d and WebGL (almost a direct port of OpenGL ES) brought that and engines like three.js use that well. Mobile gaming became the biggest gaming market due to OpenGL ES and web games took a leap on WebGL, also apps, interactives and tools became faster rendered.
With GL, in many cases the global state is more simple, but to take advantage of GPUs and rendering lower level the innovations were needed. The naming to index/position based for instance is lower level and can also end up in bugs just as the global state in GL could. The benefit is performance and cleaner global state.
It is probably a good idea to learn OpenGL/WebGL as some of the concept in WebGPU/newer engines will be more clear, much of it was simpler with naming.
Well Apple makes more sense considering M* chips are ARM based and they have signed until 2040, though that could change at some point.
Intel might be using this as more a way to get "intel" so to speak. Not a bad idea to have some investment leverage.
I could see ARM after going public increasing the cost of licensing and some of the larger players would be ok with that to prevent competitors. Seems like lots of leverage plays here.
That could be a benefit. Imagine being able to go dev shields up with just cones around your desk.
When it is time to innovate, surround yourself with cones.
"You haven't checked on your 'resources' in an hour, how is resource #4233 (Johnson) doing on that new feature?" -- funding borg consultcult front man
"I don't know, his cone shields are up, we can't get our needed hourly metrics" -- Microsoft Middle Manager 2.0
WebAssembly, WASI, like WebRTC/WebGPU/WebXR/WebAudio, just makes webdev, gamedev + native/networking very very interesting in this phase of technology where js frameworks are culty bloated/verbose and apps are the main thing for marketing/tools. Web apps + tools are opening up with wasm/wasi.
Runno (https://runno.dev/ + https://runno.dev/wasi) is a great idea and helps make interesting native stuff in a sandbox locally. Running all this directly without having to mash into assembly is a great idea. Awesome job on this!
> Runno helps you make runnable code examples that can be embedded in web pages. This is very handy for educational tools, it means:
> - You can make code examples that don't need users to install scary tools.
> - No need to run a server, it all runs client-side in the browser.
> - Your users can edit and re-run any code examples you make.
> - The examples are extremely customisable with HTML, CSS and JavaScript!
If they were just called metrics in most companies and not Key Performance Indicators (KPI), then they would get less focus. KPIs has been a heavy consultant pushed term but they are just metrics, they should never been seen as how to create value and develop a product.
People love to say "KPI" as much as "Agile" and "velocity" nowadays, both have been horribly twisted and ruin agility and value creation over value extraction. They need to be generic again... metrics, agility, delivery and usability.
When metrics are all you measure, you end up with problems [1]
[1] https://en.wikipedia.org/wiki/Performance_indicator#Problems
Other than that, pretty fun trivia game and includes some historical content.
I was arguing that competition if it is a more open market with fair rules/regulations, where competition is fair, that is true. Though many times it is a fixed market, or a cheat that stifles competition that might keep it in check.
Fixed markets happen more and more where the concentration is high and efficient players will game the system.
No products or markets are better where big fish solely control everything. That is why anti-trust or regulation need to expand to funding level not just surface company level. If you own entire industries across many companies, that is still oligarchy/monopoly if it is controlled by the same funding/sources.
Concentration needs to be broken up, for competition and better market and quality of life for everyone. Most people definitely don't want to make the authoritarian systems wealthier than open markets.
Concentration starts to take us away from a fair market and more towards a fixed/gamed market.
Everything in that gets so tuned that competition is very hard to enter. Very little margin and too much optimization/efficiency is bad for resilience. Couple that with private equity backed near leverage monopolies that control necessary supply and you have trouble.
HBS is even realizing too much optimization/efficiency is a bad thing. The slack/margin is squeezing out an ability to change vectors quickly.
The High Price of Efficiency, Our Obsession with Efficiency Is Destroying Our Resilience [1]
> Superefficient businesses create the potential for social disorder.
> A superefficient dominant model elevates the risk of catastrophic failure.
> *If a system is highly efficient, odds are that efficient players will game it.*
> sometimes power becomes so concentrated that political action is needed to loosen the stranglehold of the dominant players, as in the antitrust movement of the 1890s.
Couple massive wealth and concentration, even leaning authoritarian by then as tends to happen with fixed/controlled markets, with AI/AGI and you no longer have a "blue shell" because those players control the rules and thus the game.
Competition can do that if it is fair competition and a good game design. That is why rules and regulations are important in any game or it becomes Calvinball where the only rule is there are no rules and "it can't be played the same way twice" [1], which sounds great until you start losing to cheats. Though even that has some aspect of competition, the changing of rules in your favor while others change the rules in their favor.
The flaw in the thinking is that there will be "fair" competition. Any game design with good regulations and caps on game theory advantages (especially the cheat) "fair" competition is attainable. In game theory, if the other side cheats and your side keeps cooperating, you will lose every time. There is a great little game theory game that highlights it here called The Evolution of Trust. [2]
In a market with collusion, or excessive advantage, this may not be possible to retain fairness. Even right now we can see with overweight/top heavy wealth players in capitalism if there is collusion or one player gets too big, and there is no anti-trust or "blue shell", then that player will win every time. AI needs an anti-trust or "blue shell" to knock down any player that is too advanced, but that might not be possible. Doing that is barely possible in a market run by humans now.
The market is a garden, you have to help the seeds and cull back the overgrowth at the top. This is so the whole garden can thrive, lower seeds, middle plants and large production. Right now the large overgrowth gets all the benefits, policy control, water and nutrients, taking over the garden and even harming themselves with the overgrowth.
Most real world game theory and design would be horrible game design where the larger player always wins. Now imagine a game that the larger player controls the game design, you'd never be able to nerf them.
If one player can get the "powder keg" everyone, we need the game to be able to "blue shell" the bigger and potentially colluding/cheating player.
[1] Calvinball https://calvinandhobbes.fandom.com/wiki/Calvinball
[2] The Evolution of Trust https://ncase.me/trust/
If a person pays for a thing they are more invested in making it something worthwhile and thus less attacks.
If something is free and any issue, it suddenly is horrible because they never associated value with it from the beginning.
It is a psychological thing and plays into many parts of the market.
A great thing about desalination with stills is it uses the natural water cycle, the water that comes out is cleaner than any other as it uses that.
> A concentrated solar still is a system that uses the same quantity of solar heat input (same solar collection area) as a simple solar still but can produce a volume of freshwater that is many times greater. While a simple solar still is a way of distilling water by using the heat of the sun to drive evaporation from a water source and ambient air to cool a condenser film, a concentrated solar still uses a concentrated solar thermal collector to concentrate solar heat and deliver it to a multi-effect evaporation process for distillation, thus increasing the natural rate of evaporation. The concentrated solar still is capable of large-scale water production in areas with plentiful solar energy.
Some libs also support comments and trim before processing but I prefer the external/metadata way. Comments add weight.
Same reason that JSON won.
JSON and Markdown are base standards that were generated by market need to simplify.
JSON won because it was not overly complex and there was some flexibility. If you need more go YAML or use JSON as a platform for more.
Every attempt to change JSON has and should be shot down. JSON really just has basic CS types: string, int/number, bool, object, lists. From there any data or types can be serialized or filled. With JSON you can do types via overloads/additional keys, you can add files by url/uri or base64, and any additional needs using parts of basic JSON. Even large numbers can just be strings with type defs as additional keys/patterns. Financial data can just use strings or ints with no decimal largely because this is the safest way to store financial data to prevent float issues.
KISS is life and sometimes things are just done, no improvements needed. Now you can take JSON and add things on top of it if you want. Same with Markdown. The base doesn't need to change... ever.
Don't SOAP my JSON. Don't HTML my Markdown. Though you can add specs (JSONSchema/OpenAPI) and formatting tools on top in a processing step. For messaging and base content, they are perfect, simple, clear, concise and no need to change.
McKinsey and Jeff Skilling used Enron as a "sandbox". [2]
McKinsey is somewhat a consult cult that ruined agility with "Agile" which goes against everything agile was supposed to be. [3] Real agile and agility is now crushed due to them turning it into a micromanagement always on critical path. [4]
McKinsey margin cutting has killed off lots of research and development and innovation.
[1] https://en.wikipedia.org/wiki/McKinsey_%26_Company#Controver...
[2] https://en.wikipedia.org/wiki/McKinsey_%26_Company#Enron
Apple did recently add better support for mixing Objective-C++/C++ to Swift which was more difficult before. [1][2][3] Swift to C++ had more leaps prior to recent updates though it was still possible. Really it just handles the Swift to Objective-C++ to C++ link better.
Objective-C++ has been used since iOS inception to link C++ game engines to Objective-C. All you have to do is compile with g++ or other and typically files with .m are Objective-C only and files with .mm are Objective-C++. Objective-C/C++ and interop with C/C++ actually works really well and every single game engine on the store (pretty much ever game) uses Objective-C++ to link them at a minimum.
We used lots of C++, Objective-C and even Objective C++ (g++ mixing Objective-C + C++, connecting to C++ engine) in a custom game engine that worked on mobile for lots of shipped titles. It is powerful and fun. People have been mixing assembly, C/C++, Objective-C/C++ since the 80s. These technologies so close to the metal and machine code actually work better together than most "modern" frameworks/systems.
A sample of early game engines using this link is Oolong from 2008ish, that was used on an early Quake port and many game studios had something like this for custom engines to get them to the iPhone/iPad/etc. [4]
Fun fact: Objective-C was created before C++. Objective-C all they way back to 1981 but officially 1984. [5] C++ all the way back to 1982 but officially 1985. [6]
[1] https://www.swift.org/documentation/cxx-interop/
[2] https://developer.apple.com/documentation/Swift/UsingC++APIs...
[3] https://developer.apple.com/videos/play/wwdc2023/10172/
[4] https://code.google.com/archive/p/oolongengine/
Some amazing work is coming out of a public state university and that is exciting, in sustainability, in technology, in space exploration (Rovers) and many other things.
ASU and community colleges, which recently are able to give out bachelors degrees, are some of the best parts of Arizona and bright spots on how education can be competitive both in quality and cost, as well as available to all that want to pursue. [2]
[1] https://president.asu.edu/watch/obama-at-asu-commencement-sp...
[2] https://www.maricopa.edu/degrees-certificates/bachelors-degr...
With this infrastructure move especially, it is hard to trust in Google. This can't have been losing money or been that costly. Google why?
Google Domains integrates well with Google Cloud and Google Workspace and other products. Even if it was a loss leader it had to be useful. Tell me how this makes sense.
Tooling could be improved and will be, it is fairly new still and the Azure Cosmos DB Emulator is not bad.
There is a CosmosDB Synapse setup that allows more analytics/intel on top like you said but same with other NoSQL, takes a bit to get worked in.
I actually like the flexibility of query types and that they include SQL as it makes it a bit more standard and somewhat less vendor lockin. You can use other types as well Mongo/Cassandra/Tables syntax. For filtering the SQL side isn't bad but most of what we do is flat/associative and not heavily normalized. For most of our data we are very cache heavy as well to reduce db hits and retries.
ACID compliance is huge and there are some design considerations.
What cloud DB do you use the most DynamoDB?
It could have been solved by limiting the two side vectors lengths to less distance (maybe even tuned by speed) and fixed it enough if the reason was for side damage. If it was to fix some other issue like maybe floats losing precision far out that would not be a good idea.
Where possible go with simple but abstracted cloud storage, cloud tables and then a cloud db that is managed. We use Azure mostly right now but our storage system works across Azure storage, Amazon S3, Google Cloud and others. For tables, Azure Tables mainly. For database with filtering/paging better performant and ACID compliant cloud db, CosmosDB currently which is a dream with the differing apis (SQL, Mongo, Cassandra, Tables style). The more you can avoid vendor or dev-lockin the better so simple formats/messaging/routing and abstracted specifics/implementations.
When you store data in storage or a cloud db the scaling is "infinite" and you can also snapshot or backup to anther one, you never worry about data.
The front ends and APIs are mostly repos pushed to app/web services and everything else in data storage. Super simple and anywhere you need some special service that can be serverless or a dedicated setup, like maybe a RDBMS, chat server, network server or WebRTC/socket endpoint that interacts with the simple side. These managed as well if possible, though not always. Additionally, build cheap and horizontal scaling on web/real-time servers. Vertical scaling and sharding is for suckers.
Side note: CosmosDB is like a combination of NoSQL, document databases and GraphQL and it is ACID compliant and you can do REST or SQL, it can even wrap MongoDB and Cassandra and make them ACID compliant. It really feels like the best way. Not many have all that and ACID compliant. Not even Amazon Redshift has that, DynamoDB does if specified. Google Firestore does if specified. I used to be big on RDMBS Oracle then MSSQL then PostgreSQL and those are great for backing/reporting etc but CosmosDB combines all the power of RDMBS, NoSQL, document databases, and ACID compliant with little worry about scale. It is vendor lockin to Azure, which you can route around with platform abstraction, but currently can't be beat. As you got that clean API layer you could change later but best way is limited/clean and if possible, non breaking change API layers/signatures.
I agree and Node and Express are still great when going with just js. Node and Koa more now but still great. Socket.io for real-time. All are great for getting things up quickly, simple and shipping things.
Part of that demand is cash to buy and cost of the goods. If debt costs more then people have less to spend on other things. Like for instance higher credit card rates or student loans. That impacts purchasing power.
Inelastic goods may not be fixed by higher interest rates, especially with other supply chain/geopolitical/environmental impacts and companies debt requirements.
Elastic goods or investments, higher interest rates for loans for larger purchases or business purchases/investments/inventory certainly are impacted by higher rates when debt is involved.
In the end if the higher interest rates affect mostly business/consumer elastic goods then yes interest rates bring down price inflation and affects demand eventually. The flip is if the interest rate increases start to affect the supply like margins or business survivability, then any reduction in demand will just offset with a reduction in supply.
Largely because those are inelastic goods, they are always purchased. While some may be able pull back, most cannot.
Higher interest rates for loans for larger purchases or business purchases/investments certainly are impacted by higher rates.
Coen brothers still make movies with real people and brought this world to life in an authentic way.
[Anton vs the "We can't give out no information" lady](https://www.youtube.com/watch?v=_WLA81q9ok0) I love Coen movies with regular people like this. The lady is hilarious and it is one of the only people that Anton didn't take out.
[1] https://en.wikipedia.org/wiki/Cormac_McCarthy#/media/File:Co...
[2] https://www.slashfilm.com/img/gallery/how-quentin-tarantino-...
When you got started you were in the open mode, playing, prototyping, dreaming and iterating.
When you finish you have to move to the closed mode and have an internal editor that says "ship" and "cut that" or "move to an update" and that is a difficult ride. Sometimes people don't finish simply because it is too painful for a labor of love to be trimmed, but it is the skill you need to ship. It sucks but is.
What you have to do there is revisit the love/play that initially got you to the idea and project.
See your project in the world/market and feel the original feelings of when you started it. Don't focus on what you had to cut or didn't meet your expectations, focus on what did and head to post-production and ship.
Ultimately we are only what we ship to the world, no matter how much you have in development or your adventures. If it isn't where you want to be improve it, but also learn to love each ship as that is a major step. It is a joy when what you envisioned comes out as you wanted or better, when it isn't, make changes and updates.
Both "work with a high degree of quality" and "finish strong" are good areas to strive for, but "finish strong" is where it is at.
C/C++ will always be around no matter how hard replacements are thrown at it. C++ is the Grand Canyon and attempts to dethrone it from what it does best are mere rainstorms adding to a river at the bottom of the canyon, maybe one day but that day is not close.
C/C++ work well together and this made them win along with the power and timing of coming about in the application age.
The game engine is in C++ so to use it on iOS we needed to have an integration point for the system level Objective-C libraries to the C++ game engine (same with Android NDK integration in a way).
Another game engine from around the time Oolong Engine [1] also used this and was used for an early Quake to iOS port.
Like our custom engine Oolong used PowerVR/PVRTexTool to simulate PVRTC/PVRTC2 textures.
This setup made it so you could just develop your whole desktop/console/mobile game on PC then it would run on iOS with the Objective-C++ integration points. That was huge for game studios that only had PCs pretty much at the time.