Nagol Namrof 🌻💀🌻

START THE YEAR OFF RIGHT. GET FEWAR-DVD NOW ON STEAM AND ITCH!

DUNGEON DIENAMICS MADE FOR GM48 #GameMaker

“A very common strategy I’ve seen in the programming world is thinking of certain desired high-level features, then directly codifying each one as a separate codepath. I call this strategy ‘top-down’ because it begins enforcing constraints on code by starting with high-level requirements. Such an approach would mean that, in the case of user interface rendering, each of the features I’ve mentioned—text, rectangles, rounded rectangles, rectangle borders, rounded rectangular borders, drop shadows, and icons—would all be implemented as distinct codepaths. Each feature is seen as a separate ‘case’ to handle, and the programmer in charge naïvely translates that into distinct cases in the code. “This has a number of possible drawbacks. The first is simply that you may write (and thus maintain) more code to implement each feature, when compared to an alternative world where you got all of the features you wanted out of a smaller number of codepaths. That might not sound too bad for a small number of features, but it is worse than you might first assume. Each ‘case’ is heterogeneous, and so there is a degree of variability that propagates elsewhere, and forces itself not only into the implementation of each case, but also other code that must interact with each case. Any codepath that wants to programmatically parameterize this rendering codepath now must scale itself with the number of cases. For these reasons, I consider each addition of a ‘case’ as a multiplication of code, rather than an addition of code.”

Before You Melt is OUT NOW!

i made a puzzle-platformer about a snowman. coming out this Sunday #gamedev #GameMaker

BEFORE YOU MELT Out on 01.03 on itch.io

free-list-based pools have an weird property people don't talk about - at some point the slot allocation pattern becomes almost random. But there are alternative approaches, which don't use free lists at all. Lately I've been using a multi-level bit pool:

@usgraphics @neurospicy9 I definitely read it as the opposite which surprised me from your account. It read as ""manual"" programming going from a profession to a hobby

@neurospicy9 :( man, I was trying to say that craftsmanship is awesome. Instead getting hate.

Muad'dib - the little mouse. "I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past, I will turn the inner eye to see its path..."

@Blabberf Good to see you!

added a main menu to my game

The release date for the exploration puzzle platformer game "Öoo" is set for August 8th! Please consider sharing and adding it to your Steam wishlist! Steam👇

Cover art I made for FEWAR DVD for when we made it free Still think it’s pretty cool :) #pixelart #gamedev

Hey! I'm a pixel artist with 7+ years of experience creating 2D game assets for games What I can do for you:
- Sprites & character design
- Portraits & backgrounds
- Tilesets & UI elements
- Animation (walk cycles, attacks, VFX)
- Cover art & promo materials #pixelart #game

@zack_overflow For number 2, if you give each resizable array its own arena/reserved address space block, you have less relocation than a more standard/std approach.

I've always been fascinated how memory mangement in Postgres is just "use arenas everywhere bro" But there are practical problems with arenas: 1. Really big allocations won't get freed until the end and take up a lot of memory 2. If you have something like a dynamically resizable array and it needs to realloc to grow, it's easy for it not to be able to reclaim the allocation and so each resize wastes memory I wanna do a deep dive someday and learn how postgres addresses them

@TahaTorabpour @SheriefFYI Second this

@SheriefFYI rxi.github.io/a_simple_undo_…

any recommended reading on implementing undo / redo systems in game editors?

Hello everyone! I have not been on here for a long time since I’ve been busy working on the game Out of Sight which is releasing today! The game is our take on the concept of “second person perspective” with a mix of puzzles and horror. Check it out if it looks cool to you! 🧸

@Kinix17Games Thanks, I appreciate that. The guy is a prolific reviewer. He has 17000 thousand reviews, all very similar to this one. If anything he's losing his touch a bit, some of the paragraphs are copy paste now it seems.

Big gamedev milestone reached: steamcommunity.com/profiles/76561…

드럼마신魔神 (63.1MB)

I read this article about software development, which I knew about because I saw Prime reacting to it: notashelf.dev/posts/curse-of… For the most part I think it is fine: a relatively young programmer is doing the healthy work of introspecting on what he should really be doing. But there's one part of the article that I think is a deep mistake, and the author doesn't know it's so wrong because he has never experienced the alternative: "Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Not now, not later, but eventually. Libraries deprecate. APIs change. Performance regressions creep in. Your once-perfect tool breaks silently because libfoo.so is now libfoo.so.2. 2 I have had scripts silently fail because a website changed its HTML layout. I have had configuration formats break because of upstream version bumps. I have had Docker containers die because Alpine Linux rotated a mirror URL. In each case, the immediate emotional response was not just inconvenience but something that moreso resembles guilt." Yes, this is true in much of the programming world. But there is another world in which people build things that last much longer. I have done it many times. I shipped a binary for this game Braid in 2009 that you can still download and play on Steam 16 years later. If you are pretty young (like 35), you can run binaries on Windows that were compiled before you were even born, which is amazing given how hard they have been trying to f up Windows lately. On an emulator like MAME, you can play arcade games programmed in 1979. If today's software "technology" is so much better, why does it fall apart like tissue paper? The author is not wrong about the cited decay. But this decay is not inherent to the practice of software. It's due to choices made, usually foolishly, by the people designing the systems being interacted with. And, it's due to a lack of knowing better, non-exposure to the sector of programmers who are very concerned with their code lasting a long time, actually. The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies. The actual algorithms you program, the actual functioning machinery you build, is a mathematical object defined by the semantics of your programming language, and mathematical objects are eternal, they will last far longer than your human life. The goal then is to avoid introducing decay into the system. You must build an oasis of peace that is insulated from this constant bombardment of horrible decisions, and only hesitantly interface into the outside world. This means, for example: If you are shipping on iOS, you only reluctantly use any functions iOS gives you, because when you use them, Tim Apple will come along and break your program next year for arbitrary pointless reasons, because Tim Apple does not respect you or anyone you know. This means a program cannot last forever on iOS, because Tim Apple likes breaking your things and watching you submissively clean them up. But the core of your program, which could be 95% of the code, is fine, and you can deploy it elsewhere. This means you have to insulate from Linux userspace, because of all the jackass decision making that introduces constant incompatibilities while somehow never making the system better. Using a library dependency to do font rendering or sparse matrix math? That dependency gets checked into your source tree, a copy of exactly the version you use. Ten years later you can pull down that source and recompile, and it works, because your program is a mathematical object. If you want to upgrade to something newer that has bug fixes and so forth, you are free to do so, but you are also free not to do so, and your program still works. (And how many of these bug fixes do you really need? Your program worked correctly when you shipped it to the greatest extent you could measure, because you are a skillful software engineer who wants to ship things of a high quality). Everyone who got into programming for the joy of it knows, at some level, that the magic of programs is that they represent complexity that is replicable over time (and thus they exist outside of time). But the trashy programmer culture of the past 20 years stopped aspiring to this, and now has forgotten it is even possible. And so long as people have forgotten, decisions will continue to be made that make the problem worse. There are programmers who only write glue code, and who think that's what programming is; to these people what I have written above will not make sense. But the good news for that contingent is, they can always just stop writing glue code and start doing something else! If today's software "technology" is so good, why do you think it needs so much glue? Maybe there is a stylistic problem. So if you are looking for what to do in the world of software that can represent a lasting contribution, maybe this is food for thought. @NotAShelf @ThePrimeagen