An auto-connective catalogue of all your favorite thinkers.
Here's a list of some of my favorite current-day thinkers:
An auto-connective catalogue of all your favorite thinkers.
Here's a list of some of my favorite current-day thinkers:
As for the Job To Be Done, last time we talked, Quaternius provided me with this prompt:
You could put together a list of categories and models you'd need along with some references for the specific stuff (if there were characters what would they have to be,etc)
We know the assets are readily available at https://gitlab.com/SuperTuxParty/SuperTuxParty/-/tree/dev/assets, but I think what Quaternius is asking for is a more digestible outline of the required work.
As far as I can tell, there are three primary categories of model types in the game:
Original: https://maddymakesgames.com/articles/celeste_and_towerfall_physics/index.html
I get a lot of questions about how the physics work in TowerFall and Celeste. It’s a very simple system that I arrived at after about a decade of experimenting with tile-based platformers. I wrote an engine ages ago for Game Maker platformers that uses these same basic concepts, and since then I’ve simplified and improved it a bit. Also, the Celeste and TowerFall engines are written in C# so we have fancy features like delegates and structs that make everything nicer. It’s nothing ground-breaking, but I decided to write it down in case it helps anyone!
All of our physics are handled by two classes: Solids and Actors. Solids are, of course, the collidable level geometry. Actors are physics objects, such as players, arrows, monsters, treasure chests, etc. Anything that has to move and interact with the level geometry is an Actor. The system has a few simple constraints:
Spicy Lobster wants to port https://github.com/a-nikolaev/curseofwar to Rust-lang.
There are many things to like about this project:
After three years of working with Godot, I wanted to share my feedback and insights on this powerful game development engine. As a dedicated user of Godot, I have experienced both its strengths and areas where improvements could be made. Through this feedback, I hope to contribute to the ongoing development and growth of the Godot community. Let's dive into the details and explore the strengths and areas for improvement in Godot!
By default, Godot's core features and functionalities are bundled together in a single monolithic binary. This can make it challenging for developers to selectively include or exclude specific features based on their project requirements. This lack of modularity can result in larger binary sizes and potential overhead.
Online community platforms are assembly-kits for large, communal bonfires, designed to draw people towards the light and into the warm togetherness of community. I think the primary function of bonfire software is to create space for group-scale discourse.
Riffing on thoughts about healthy information consumption, Tom Critchlow described his personal campfire thusly:
If you haven't heard the news, Reddit is making some drastic, user-hostile changes. This is essentially the final stage of any ad-supported and VC-funded platform's inevitable march towards enshittification.
I really love the /r/rust community. As a community manager it's my main portal into the latest happenings of the Rust ecosystem from a high-level point of view primarily focused on project updates rather than technical discourse. This is the only Reddit community I engage directly with; my daily fix of the Reddit frontpage happens strictly via login-less browsing on Apollo, which will soon come to an abrupt end.
This moment in time presents a unique opportunity for this space to claim its independence as a wholly community-owned operation. If the moderators a