Hey there, #GameDev and #IndieDev community of the Fedi!
Are any of you up for a little challenge? If so, you could join the #NoVideoJam, and make it an even bigger success than it was last year!
Yeah, no video. Well, you could have it. But the point of this #GameJam is to
1. remind developers that yes,, #blind gamers exist, yes, we would love to have more games to play, and no, it isn't so hard to make them and
2. to give us more of said games, because hell, there really isn't enough of them.
If this sounds scary, don't worry, there's plenty of people willing to help you. There's a Discord server linked in the jam's description, with plenty of skilled developers, sound designers and beta testers. And if you aren't into Discord, you could try forum.audiogames.net.
And finally, the link! https://itch.io/jam/no-video-jam-2

I made a #nes game using a web IDE over the weekend. You can download / play / edit it here http://8bitworkshop.com/redir.html?platform=nes&githubURL=https%3A%2F%2Fgithub.com%2Fvoxel-public%2Fakj11_ancient_ruins&file=ancient.c

Code quality actually started out OK but over the last 1/8 of the jam deteriorated into a real mess. Feel free to judge me #theLudarium #gamedev

For any ruby :ruby: devs out there, wanted to share a neat little open-source :opensource: module I wrote to solve a common problem. Keep in mind ruby is not my main language so if there is a batter approach here I'm all ears.

Basically right now I have a game (text based mud) and in normal and expected fashion objects in the game are created when their objects get initialized, such as a new player being created. The system then periodically saves the universe by marshalling all the object into some serialized format and saves it to a file from time to time. As tends to be the case with serialization, however, when an object is restored, such as a previous player logging out and back in, then the class is created directly without the initialize method getting called , its class and instance variables are simply populated directly.

This is where problems can arise if you change the system and add new features (such as a new variable to an object). New objects that are created will populate the new variable correctly through the initialize method however already existing players will not have that variable set at all (it won't be nil, it simply wont be set, which is a distinctly different state). This is the problem I solved.

What I did was created a mix-in module that lets you set default values for variables, once a class is reinstated from storage it checked if any variables that have defaults are unset (nil variables are considered set) and then applies the default value to them. In this way legacy objects will be able to update to new code changes automatically when it loads. To prevent duplicating code you can even intentionally leave it out of the initialize method and rely on the defaults when it is appropriate to do so.

Moreover the defaults do not have to be static values but can be determined based on the existing state of the object, which makes them dynamic and flexible... a class that uses the mixin could look like this:

require 'defaults'

class Foo
include Defaults

# @bar defaults to @baz*2
default(:bar) { |this| this.baz * 2 }
# @faaboo defaults to 178
default(:faaboo) { 178 }

def initialize
@baz = 13

#this line can be ommited
@bar = 26
# if you add this line instead
#either work fine

Here is a link to the module:


You can see a class that utilizes this new feature here:


#Ruby #RubyLang #Programming #Coding #software #ComputerScience @Science #code #source #sourcecode #opensource #oss #game #gaming #gamedev #QotoJournal