It's been awhile since we've had to make any changes to AethOS Build Dist, but recently I was asked to upgrade the kernel version.
In a previous article, Thoughts on MetaZen, I showed a simple proof of concept web page backed by
ZScript, but as a proof of concept it wasn't intended to be a fully designed application.
Today I'll give a few more details and fix a few mistakes I discovered in the initial design.
This is part four, and possibly the last for awhile, of a multi-part series where I give examples of
Reactive design using
Taking things a little further, this example shows how to combine two observables and publish the combined values into a subject, which in turns updates a DOM element.
This is part three of a multi-part series where I provide some simple examples of Reactive design using RxJS.
In this example I'm going to show how to create a
Subject that updates a DOM element when the subject changes value.
In the previous article I explained what I mean when I say
In this article I'm going to dig a little deeper and get a little more concrete with a simple example.
MetaZen provides software architects and designers with a way to defer some of the more important architectural decisions for a project.
Curiously, by deferring these decisions, we make them less important, and as a result the truly important decisions receive the proper attention they deserve.
This next series of articles are about one of these decisions… are you going to utilize
reactive components in your design?
In order to explore the answer to this question, first one must be able to answer another question:
What is Reactive?
MetaZen started out as an idea of mine way back in the early 1990's. I realized early in my software development career that I was rarely going to have the opportunity to innovate. Most of my time was going to be spent doing menial tasks, with only a few nuggets of interesting coding sprinkled into the mix.
Wow, that really sounded like a boring way to spend the rest of my life. What a huge waste of time.
Ever since then it's been my goal to change that.
Independent game developers (Indies) have been around for as long as game development has been around.
We hear people tossing the "indie" term around, but what does it really mean? My answer will probably surprise you, and possibly make a few people angry.
I've been looking for a game engine for an upcoming project and I'm exploring using Atomic Game Engine.
The biggest hurdle will be the fact that Atomic Game Engine development has stalled, and very few people are actually using it. It also has some bit rot, primarily due to the fork of Urho3d not being kept up to date.
For the past few weeks we've been considering moving back to a monolithic repo for all of the IndieZen software. Guess what? Today's the day we pulled the trigger.
While the Joel Test is a great way to determine if you have a good team, there are more things you have to do in order to be considered a great developer while walking the path of the Software Artisan.
There’s a silly saying that we use in the IndieZen community: When you’re trying to swim with a bag of hammers, it’s called a “floating point error”.
(ba dum bum)… and the crowd groans….
Ok, a slightly less corny saying that you’ve probably heard: “When the only tool you use is a hammer, every problem looks like a nail.”
Whether you're a beginner, hobbyist, aspiring game developer, or a seasoned veteran, this article provides some great guidelines and hints for creating a great Indie game development team.
The article assumes you're putting together a zero or low-budget team to build an Indie game. It answers questions like "Who is the leader?" and gives you great advice on how to keep your team motivated and making constant, steady progress on your game.
If you're considering starting a game development project or if you're already part of a team, this article is definitely a must-read.
subscribe via RSS