5 Steps To Start Making Games

[Lyberta]

So I accidentally stumbled upon this video on YouTube.

I've been in a libre world far too long and forgot that making libre games and libre anything is such a self-torture and people who make proprietary stuff get everything, all the tools, tutorials, convenience. They have everything, we have almost nothing. What's the point then? Like, the guy in this video talks about making a game in about 2 years. I estimate it will take me about 40 years to make a single game and that's already far above my life expectancy. I'm... broken....

[fluffrabbit]

Before I even watch I know it's going to be all about Unity. As long as the guy doesn't talk about GameMaker I'll know he isn't a retard.

40 years tho? You could write the world's software infrastructure in that time. It took me 2 years to learn OpenGL really well, and I didn't even know C++ when I started. I started the framework with C, moved a lot of stuff over to C++, moved some periphery components back to C, and I'm sort of going back and forth while juggling several projects. There is a concept of "minimum viable product", AKA "vertical slice", AKA "alpha". Get the game to a state where a programmer can look at it and give a thumbs up, even if it's only 10% done, and the rest will happen on its own.

[fluffrabbit]

lol C# is a "scripting language" apparently. In some respects I suppose that it acts as a domain-specific language in Unity, but it is also a standalone compiled language that runs atop the Mono framework. But this guy clearly isn't a programmer. And he mistakenly blames the difficulties on languages "like C++". C++ and C# are very similar. It's what Unity brings, not the language. I know I don't have to tell you this, but I feel that people like him need to hear it.

As for open source frameworks, Panda3D is looking pretty slick these days. I would use that over Godot because Godot has too many bugs due to trying to do too many things at once. But there's nothing stopping you from writing your own rendering engine, which naturally lends itself to writing other subsystems that are related. As long as you avoid the things that have cost you time in the past, such as compiling for mobile or dealing with assholes on forums, it should all be doable in a matter of months rather than years.

[Lyberta]

it should all be doable in a matter of months rather than years.

Well I've started in 2010 with my own engine. So far I have:

• Basic skeletons of most subsystems
• Ability to draw pixels, single pixel lines and rectangles
• Basic networking (no client-side prediction, no server-side lag compensation)

Here's my TODO list so far:

• Unicode (2 years)
• WebAssembly interpreter (1 year)
• Audio (1 year?)
• Virtual file system (maybe less than a year)
• Basic graphic primitives (no idea)
• GUI (3+ years)
• Level editor (no idea, a lot I guess)
• Physics (2 years)
• Turning command line interpreter into Turing complete language (1+ year)
• Writing actual game

So that's about 20 years total for an engine and who knows how much for the actual game.

[fluffrabbit]

No no no, you don't need all that. Better to build a clusterfuck nightmare codebase with the bits you need as you go along. Then you have a game engine made for a game rather than a game built on a game engine. It doesn't have to be super general at first, it will become general over time.

In particular, you don't need advanced scripting all over the place. WASM is good to investigate, but the STB C lexer, V8, LIL, Squirrel, or another interpreter might serve you better. Then no compiling, it just runs. My first game engine was scripted entirely using CSV, which made for a very simple syntax. I started working on a functional language for it back in high school, but I dropped that idea when I realized it was inefficient with my time.

Virtual file system? You don't need that either. You already have code to put things in the right places, and Emscripten is a special case that gives you access to your main data folder as a virtual file system. Just use the regular file system.

Graphics primitives? Level editor? No, no, no. Just use existing tools. For 3D stuff, use Blender or another 3D editor. For tile-based stuff, use Tiled. For esoteric vector-based mapping you're on your own, but you can probably get it done in a few hours if you don't over-engineer it.

Just do the game. A simple walking prototype is all you need for a start. I also recommend going proprietary by default, even if you use open source tools. That way you won't be mad when people refuse to help with your altruistic effort.

[rubenwardy]

it should all be doable in a matter of months rather than years.

Well I've started in 2010 with my own engine. So far I have:

• Basic skeletons of most subsystems
• Ability to draw pixels, single pixel lines and rectangles
• Basic networking (no client-side prediction, no server-side lag compensation)

Here's my TODO list so far:

• Unicode (2 years)
• WebAssembly interpreter (1 year)
• Audio (1 year?)
• Virtual file system (maybe less than a year)
• Basic graphic primitives (no idea)
• GUI (3+ years)
• Level editor (no idea, a lot I guess)
• Physics (2 years)
• Turning command line interpreter into Turing complete language (1+ year)
• Writing actual game

So that's about 20 years total for an engine and who knows how much for the actual game.

Your problem here is making so much of this yourself, rather than using existing libraries like SFML, enet, and engines like Godot. Unity is responsible for a lot indie games being made and release because it's so much easier to not reinvent the wheel. It's a good idea to reach a playable mvb as soon as possible, even if the code isn't as flexible as you want it to be. This helps with motivation and also iteration of game design

[smcameron]

Audio (1 year?)

1 year seems pessimistic, esp. if you use something like portaudio (which is still pretty low level -- you still have to write your own mixer code with portaudio) then it shouldn't take more than a couple weeks or maybe a month to get something going. When I did it back in 2007 (knowing *nothing* about audio programming when I started) for wordwarvi it amounted to approximately 500 lines of code, allowed concurrently triggering any number of sounds that are mixed on the fly and play concurrently with a dedicated channel for music. I'm pretty sure I had it basically working after a couple weekends (not polished, but working.) Now it didn't do any fancy 3D stuff or dynamic stereo manipulation, or reverb or effects of any kind, and getting it to read ogg files instead of wav files was another step (using code ripped out of libvorbis). But just to get going, you don't need all that stuff. (And later, I did add some real time stereo manipulation stuff for an audio-only game (more of a novelty actually) and it wasn't that hard.)

The way I approach big things like this is for each little part, I kind of throw together the smallest version of it that will basically work. That doesn't mean I don't think about the API and try to come up with something good, it means I try to identify the minimum feature set that will let me mostly do what I'm trying to do, and I implement just that, and do it in order to support the primary project which is *actually using it*. Later, you can go back and fill in missing things *on an as-needed basis*. This prevents you from spending a year building the world's best audio subsystem but never getting around to actually making anything that actually uses it.

Edit: Actually, just to get audio things working required only about 200 lines of code. Here's a summary of the first audio related commit:

{l Code}: {l Select All Code}

scameron@wombat ~/github/wordwarvi $ git show 804f70de7a4146abcccfbfea3e91888b775ad9b7 | diffstat
 Makefile    |    2
 wordwarvi.c |  215 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 216 insertions(+), 1 deletion(-)
scameron@wombat ~/github/wordwarvi $ git show 804f70de7a4146abcccfbfea3e91888b775ad9b7 | head
commit 804f70de7a4146abcccfbfea3e91888b775ad9b7
Author: smcameron <smcameron>
Date:   Tue May 8 00:36:13 2007 +0000

    Added very very simple sound.  Now needs portaudio and libsndfile
    (Doesn't actually use libsndfile yet though.)

diff --git a/Makefile b/Makefile
index 0372ab4..083ce0d 100644
--- a/Makefile
scameron@wombat ~/github/wordwarvi $


[drummyfish]

lol 40 years... some people can make a whole libre game in a 48 hour jam (sure, the code is shit and it's no GTA V, but still). My games usually take weeks to months, from the ground up, including assets and the engine.

I've kind of been there though. @fluffrabit is right, you've fallen for the proprietary capitalist style of development meme where they have a billion of programmers, sit them in a room for 3 years and out comes a hyperrealistic game built from the ground up. You want to do this yourself, and you can't, because you need progressively more effort for just maintaining what you've already written as time goes by, which will prevent you from any actual progress. Just avoid that bloat nightmare, use existing tools, code and assets and leave that maintenance to others. And don't try to match AAA proprietary games in hyper realistic visuals and physics and billions of features, they're just feeding consumerism with that, value of that will be near zero in a few years, you can't keep that pace. Keep it as simple as possible and focus on fun gameplay first and actually creating something playable, while keeping the door open to possible expansions in the future.

[Jastiv]

Well, I forked a game I didn't really understand back in I think it was 2005 or 2006.
I'd say the biggest problem with forking is I don't really understand all the intricacies of the code. (or why the java client compiles in java 11 or the editor doesn't)
Its definitely more doable to make some fun game play on par with indie games (think about the popularity of something like five nights at fredies, baldies basics, angry birds) and not try to make a super realistic graphics AAA game.
It makes sense to just use an engine like godot.
Don't bother making engines from scratch unless the game is either (A) a really small thing or (B) you would rather make an engine than a game.
For me when I started, making an engine from scratch was something I never even considered because I knew I didn't have the skill to pull it off. Instead I just thought in terms of "what open source game has an engine most similar to the game I want to make." and then go from there.

[Lyberta]

Better to build a clusterfuck nightmare codebase with the bits you need as you go along.

My mentally disabled brain doesn't like working with clusterfuck nightmare.

In particular, you don't need advanced scripting all over the place. WASM is good to investigate, but the STB C lexer, V8, LIL, Squirrel, or another interpreter might serve you better.

I chose WASM because with it I can write everything in C++. For example, I can have a shared base class defining synchronized properties and then inherit client-side and server-side classes from it. Right now everything gets compiled into native code. After I add WASM client-side code will be compiled to WASM while server-side will stay native. I use WASM so if client connects to modded server, server will simply upload a WASM blob that will run on client. That means Turing complete client-side mods.

Virtual file system? You don't need that either. You already have code to put things in the right places, and Emscripten is a special case that gives you access to your main data folder as a virtual file system. Just use the regular file system.

I don't plan to use Emscripten but WASI, seems much better. And I need VFS so client-side code can't get arbitrary access to the file system.

Your problem here is making so much of this yourself, rather than using existing libraries like SFML, enet, and engines like Godot.

Couldn't really find good libraries. SFML has horrible constructors and enet seems to be C. I do use SDL because it doesn't get in my way too much.

Audio (1 year?)

1 year seems pessimistic, esp. if you use something like portaudio (which is still pretty low level -- you still have to write your own mixer code with portaudio) then it shouldn't take more than a couple weeks or maybe a month to get something going. When I did it back in 2007 (knowing *nothing* about audio programming when I started) for wordwarvi it amounted to approximately 500 lines of code

Well, I started writing my own audio library at about the same time. I decided to see how much lines of code it has. SLOCCount says 12,438. That is more than my game engine - 9,013. I'm not sure what can be useful in 500 lines. My MultichannelAudioBuffer class template that is just for storing samples is 2165 lines of code.

The way I approach big things like this is for each little part, I kind of throw together the smallest version of it that will basically work. That doesn't mean I don't think about the API and try to come up with something good, it means I try to identify the minimum feature set that will let me mostly do what I'm trying to do, and I implement just that

But then you have this growing pain of writing incomplete class that slowly drives you insane. My MultichannelAudioBuffer had only .begin(), .end() and .push_back() for quite some time. It was driving me insane so I spent about a month on it to finish it and remove the pain.

[rubenwardy]

SFML is easily the best C++ library I've used, in my opinion, in terms of documentation and API. If you want to be more productive, you need to be able to accept things that aren't done exactly the way you like, but are well tested and used. You shouldn't need to be writing an audio library at all, it's supposedly a solved problem

One of the primary benefits of C++ is that it's built on C, so you can use C libraries easily. With well designed code, you abstract away such code. For example, only one class in my entire game even includes enet - the Socket class. Encapsulation like this helps when you want to change implementations, as I did when I switched from my own sockets implementation to enet.

I understand the trap of reinventing the well, I - like most developers - have fallen into it too. But to be productive, you need to be more pragmatic. It depends on your aims and objective though. If you just want to learn about everything, then reinventing everything is a good approach for that. But if you want to one day release a game, you should spend your time on actually making that game

[fluffrabbit]

I think I'm less intimidated by these features than others because I started with DarkBASIC and didn't move to "real" programming languages until I already had experience with 3D math, post-process effects, ad-hoc physics stuff, etc. If I were trying to make my first game in C/C++, I'd probably quit. But there are higher-level C/C++ frameworks than SDL available, so for a first game, I would use those. You really don't have to go with something like Godot. I can't stress enough how terrible it is, sorry Godot devs. Go ahead and add all the AAA features in the world, but when you do, use other people's code.

Lips of Suna is a great example of what I'm talking about, though of course there are far lighter 3D libs than Ogre.

[Lyberta]

If you want to be more productive, you need to be able to accept things that aren't done exactly the way you like

I guess that's where my mental disability kicks in. It demands perfection.

You shouldn't need to be writing an audio library at all, it's supposedly a solved problem

Well there were a couple of things I wanted from audio library. It should be agnostic to bit depth that means it would be almost 100% templates, it should have sample and frame classes that do the right thing (saturation arithmetic in case of integers) using usual operators. I couldn't really find such a library so I decided to write it myself.

One of the primary benefits of C++ is that it's built on C, so you can use C libraries easily.

Not really. C and C++ differ so much. There is no RAII in C so you have to write manual wrappers, there is no std::byte, no std::vector, std::function, stuff like that. It's difficult to work with C libraries because languages are so different.

With well designed code, you abstract away such code. For example, only one class in my entire game even includes enet - the Socket class. Encapsulation like this helps when you want to change implementations, as I did when I switched from my own sockets implementation to enet.

Yes, I also wrote my own socket class back in the day but now I migrated to Networking TS. And hopefully we get networking TS standardized fully in C++23.

I understand the trap of reinventing the well, I - like most developers - have fallen into it too. But to be productive, you need to be more pragmatic. It depends on your aims and objective though. If you just want to learn about everything, then reinventing everything is a good approach for that. But if you want to one day release a game, you should spend your time on actually making that game

Well, it looks like right now I'm trying to fix C++.

[onpon4]

Lyberta, what you've described so far tells me you're going about game development completely wrongly, and that's why it's taking you so long.

Most importantly, you're trying to do everything, and no game in the world has ever done that. You have a design goal in mind and you develop the code necessary to do that.

Just as an example, consider Unicode support. You could spend months on end trying to get your game perfectly compatible with all the Unicode standards. Or, for instance, you can do what I did with Project: Starfighter, just code in UTF-8 support, hardcode that as the supported encoding, and leave it at that for now, because the only reason you need Unicode support is so that the game can be translated properly.

I understand and am sorry to hear that you feel a need to do things this way because of your disability, but I just want to make sure you understand that it's that, and not some special privilege of proprietary software developers, that is causing this problem for you. Ultimately, what I think needs to happen is you need to learn to accept something that's not 100% absolutely perfect, but works really well and is efficient to develop with, like Godot Engine (among others, but Godot Engine is probably the easiest-to-use libre engine out there). And you need to learn to be okay with not doing everything.

[fluffrabbit]

I agree with all of the above, except the part about the Godot engine. It takes too long to build, it glitches out with grid maps, there's no good terrain system, it's just terrible unless you only want to make a simple 2D game. If this is that vector game that Lyberta was talking about, Godot might not be a bad choice, except you have to program in GDScript rather than C++. You could patch in a WASM runtime, but the Godot devs are slow to respond to patches.

[freemedia2018]

Lyberta it sounds more like you're creating an operating system than a game engine.

I'm not saying it to make fun of you, perhaps you'll find a more efficient way to do this. If your goal is to create an operating system, I'm impressed. If it's to create a game engine, it sounds like you're trying to build "a better mousetrap" with AI, laser containment, microdrones, an orbital sonar tracking array...

If you want all that, you'll never get there with a big plan. You want to work on a better mousetrap LITE, work on your game, then upgrade your Strategic Anti-Rodent Initiative one component at a time. That way you can spend more time enjoying your work, before you're too old and don't care about video games. Said in a silly way, but quite sincerely.

[Lyberta]

Just as an example, consider Unicode support. You could spend months on end trying to get your game perfectly compatible with all the Unicode standards. Or, for instance, you can do what I did with Project: Starfighter, just code in UTF-8 support, hardcode that as the supported encoding, and leave it at that for now, because the only reason you need Unicode support is so that the game can be translated properly.

No, the biggest reason I want Unicode are player names and chat.

Other than that, you don't "just" add Unicode support.

How do you access a "character" in a string? You need a complex algorithm to do that.
How do you reverse a string? You need a complex algorithm to do that.
How do you sort strings? You need a very complex algorithm to do that.
How do you split string into words/lines? You need a complex algorithm to do that.
How do you convert string to lowercase/uppercase? You need a very complex algorithm to do that.

All of that is thousands of lines of code and there is nothing to help you in the C or C++ standard library. The only library that does most of it is ICU but it is ancient and requires input in UTF-16 (that's absolute insanity). I want sane Unicode. If I solve it, I can propose it for standardization and help all C++ developers. Not just me.

Godot might not be a bad choice, except you have to program in GDScript rather than C++.

I coded about 9000 lines of SourcePawn over 3 years for SourceMod/Team Fortress 2. After Valve broke the game and made me a FOSS zealot in the process, I had to delete them because no other project in the world uses SourcePawn. So I swore to never code in any domain specific language ever and only use general purpose language so I can reuse my code for the rest of my life. So no GDScript or any engine-specific script ever.

[freemedia2018]

So I swore to never code in any domain specific language ever and only use general purpose language so I can reuse my code for the rest of my life. So no GDScript or any engine-specific script ever.

What if it's a free software DSL that transpiles to something universal like C/C++? Because that's an increasingly common way to create a language, particularly a DSL.

Other than that I understand your aversion.

[onpon4]

the biggest reason I want Unicode are player names and chat.

OK, well, same sort of deal: you don't need to do *everything*. You just need to do enough to suffice for what is needed (i.e. in this case, supporting all the languages needed by the biggest portion of your players).

This actually reminds me of an argument I and some others had with one of the Naev project members, who initially was opposed to changing gendered references to the player to gender-neutral because, they reasoned, it would be better to have a special gender specification somewhere. It's actually a named fallacy: Nirvana fallacy. You can't reject a solution just because it's imperfect, because *everything* is likely to be imperfect. The point is to make things better.

When it comes to making a new game, if your game isn't even playable yet, there's nothing whatsoever to solve by having 100% perfect Unicode support. The problem to solve is having a game at all, and worrying about perfecting this one minor component of it (which doesn't even affect the gameplay that much) just hinders any possible solution to the actual problem at hand.

How do you access a "character" in a string? You need a complex algorithm to do that.
How do you reverse a string? You need a complex algorithm to do that.
How do you sort strings? You need a very complex algorithm to do that.
How do you split string into words/lines? You need a complex algorithm to do that.
How do you convert string to lowercase/uppercase? You need a very complex algorithm to do that.

Or you can just reuse code that already does that. Python has most of this stuff as simple syntax and/or functions in the Python Standard Library:

{l Code}: {l Select All Code}

>>> s = "初めまして！Abbyです。お名前は？"
>>> print(s[2])
ま
>>> print(s[::-1])
？は前名お。すでybbA！てしまめ初
>>> print(''.join(reversed(s)))
？は前名お。すでybbA！てしまめ初
>>> print(''.join(sorted(s)))
Abby。おしすてではまめ初前名！？
>>> print(s.lower())
初めまして！abbyです。お名前は？
>>> print(s.upper())
初めまして！ABBYです。お名前は？


And for the word-splitting thing, there's the Uniseg library, which has the fuction "uniseg.linebreak.line_split_units". Real-world example from the now orphaned SGE Game Engine:

{l Code}: {l Select All Code}

try:
    from uniseg.linebreak import line_break_units
    USE_UNISEG = True
except ImportError:
    USE_UNISEG = False

#...

def f_split_text(self, text, width=None):
    # Split the text into lines of the proper size for ``width`` and
    # return a list of the lines.  If ``width`` is None, only
    # newlines split the text.
    lines = text.splitlines()

    if width is None:
        return lines
    else:
        split_text = []
        for line in lines:
            if self.rd["font"].size(line)[0] <= width:
                split_text.append(line)
            else:
                if USE_UNISEG:
                    words = list(line_break_units(line))
                    jchar = ''
                else:
                    jchar = ' '
                    words = line.split(jchar)

                while words:
                    current_line = words.pop(0)
                    while self.rd["font"].size(current_line)[0] > width:
                        start = ""
                        while self.rd["font"].size(
                                start + current_line[0])[0] <= width:
                            start += current_line[0]
                            current_line = current_line[1:]
                        split_text.append(start)

                    while (words and self.rd["font"].size(jchar.join(
                            [current_line, words[0]]).rstrip())[0] <= width):
                        current_line = jchar.join([current_line,
                                                   words.pop(0)])
                    split_text.append(current_line.rstrip())
                       
        return split_text


Unicode was much harder to handle with Project: Starfighter because there's very little stuff for C unicode support. That one I needed to ask for help for. But even with that, it was nowhere near as difficult as you're making it sound. Eventually I figured out how to use the Pango library, and this is the result:

{l Code}: {l Select All Code}

int gfx_renderUnicodeBase(const char *in, int x, int y, int real_x, int fontColor, int wrap, SDL_Surface *dest)
{
   SDL_Surface *textSurf;
   SDL_Color color;
   int w, h;
   int avail_w;
   int changed;
   int breakPoints[STRMAX];
   int nBreakPoints;
   char testStr[STRMAX];
   char remainingStr[STRMAX];
   PangoLogAttr logAttrs[STRMAX];
   int nLogAttrs;
   int i;
   SDL_Rect area;

   if (strcmp(in, "") == 0)
      return y;

   avail_w = dest->w - real_x;

   switch (fontColor)
   {
      case FONT_WHITE:
         color.r = 255;
         color.g = 255;
         color.b = 255;
         break;
      case FONT_RED:
         color.r = 255;
         color.g = 0;
         color.b = 0;
         break;
      case FONT_YELLOW:
         color.r = 255;
         color.g = 255;
         color.b = 0;
         break;
      case FONT_GREEN:
         color.r = 0;
         color.g = 255;
         color.b = 0;
         break;
      case FONT_CYAN:
         color.r = 0;
         color.g = 255;
         color.b = 255;
         break;
      case FONT_OUTLINE:
         color.r = 0;
         color.g = 0;
         color.b = 10;
         break;
      default:
         color.r = 255;
         color.g = 255;
         color.b = 255;
   }

   if (gfx_unicodeFont != NULL)
   {
      strcpy(remainingStr, in);
      if (TTF_SizeUTF8(gfx_unicodeFont, remainingStr, &w, &h) < 0)
      {
         engine_error(TTF_GetError());
      }

      changed = wrap;
      while (changed && (w > avail_w))
      {
         nLogAttrs = strlen(remainingStr) + 1;
         pango_get_log_attrs(remainingStr, strlen(remainingStr), -1, NULL, logAttrs, nLogAttrs);

         nBreakPoints = 0;
         for (i = 0; i < nLogAttrs; i++)
         {
            if (logAttrs[i].is_line_break)
            {
               breakPoints[nBreakPoints] = i;
               nBreakPoints++;
            }
         }

         changed = 0;
         for (i = nBreakPoints - 1; i >= 0; i--)
         {
            strncpy(testStr, remainingStr, breakPoints[i]);
            testStr[breakPoints[i]] = '\0';
            if (TTF_SizeUTF8(gfx_unicodeFont, testStr, &w, &h) < 0)
            {
               engine_error(TTF_GetError());
            }
            if (w <= avail_w)
            {
               textSurf = TTF_RenderUTF8_Blended(gfx_unicodeFont, testStr, color);
               if (textSurf == NULL)
               {
                  printf("While rendering testStr \"%s\" as unicode...\n", testStr);
                  engine_error("Attempted to render UTF8, got null surface!");
               }

               area.x = x;
               area.y = y;
               area.w = textSurf->w;
               area.h = textSurf->h;
               if (SDL_BlitSurface(textSurf, NULL, dest, &area) < 0)
               {
                  printf("BlitSurface error: %s\n", SDL_GetError());
                  engine_showError(2, "");
               }
               SDL_FreeSurface(textSurf);
               textSurf = NULL;
               y += TTF_FontHeight(gfx_unicodeFont) + 1;

               memmove(remainingStr, remainingStr + breakPoints[i],
                  (strlen(remainingStr) - breakPoints[i]) + 1);
               changed = 1;
               break;
            }
         }

         if (TTF_SizeUTF8(gfx_unicodeFont, remainingStr, &w, &h) < 0)
         {
            engine_error(TTF_GetError());
         }
      }
      textSurf = TTF_RenderUTF8_Blended(gfx_unicodeFont, remainingStr, color);
      if (textSurf == NULL)
      {
         printf("While rendering remainingStr \"%s\" as unicode...\n", remainingStr);
         engine_error("Attempted to render UTF8, got null surface!");
      }

      area.x = x;
      area.y = y;
      area.w = textSurf->w;
      area.h = textSurf->h;
      if (SDL_BlitSurface(textSurf, NULL, dest, &area) < 0)
      {
         printf("BlitSurface error: %s\n", SDL_GetError());
         engine_showError(2, "");
      }
      SDL_FreeSurface(textSurf);
      textSurf = NULL;
      y += TTF_FontHeight(gfx_unicodeFont) + 1;
   }
   else
   {
      engine_warn("gfx_unicodeFont is NULL!");
   }

   return y;
}

int gfx_renderUnicode(const char *in, int x, int y, int fontColor, int wrap, SDL_Surface *dest)
{
   int w;

   if (x == -1)
   {
      TTF_SizeUTF8(gfx_unicodeFont, in, &w, NULL);
      x = (dest->w - MIN(w, dest->w)) / 2;
   }

   gfx_renderUnicodeBase(in, x, y - 1, x, FONT_OUTLINE, wrap, dest);
   gfx_renderUnicodeBase(in, x, y + 1, x, FONT_OUTLINE, wrap, dest);
   gfx_renderUnicodeBase(in, x, y + 2, x, FONT_OUTLINE, wrap, dest);
   gfx_renderUnicodeBase(in, x - 1, y, x, FONT_OUTLINE, wrap, dest);
   gfx_renderUnicodeBase(in, x - 2, y, x, FONT_OUTLINE, wrap, dest);
   gfx_renderUnicodeBase(in, x + 1, y, x, FONT_OUTLINE, wrap, dest);
   return gfx_renderUnicodeBase(in, x, y, x, fontColor, wrap, dest);
}


Of course, the Starfighter example is far from perfect. But again, you don't have to be perfect; you just have to be good enough to suffice for now. It can always be improved later on, but if you don't even have a game, there's nothing to improve, you're just writing empty air for the most part.

So I swore to never code in any domain specific language ever and only use general purpose language so I can reuse my code for the rest of my life. So no GDScript or any engine-specific script ever.

That logic falls apart for libre software.

I orphaned the SGE Game Engine, for instance. But if you had happened to use it, I wouldn't be stopping you from picking it up and maintaining it yourself, or even just continuing to use it as-is.

Similarly, if Godot Engine somehow breaks, just take the old version that works and fork it. It's a lot less effort than trying to literally create everything from scratch.

[fluffrabbit]

if Godot Engine somehow breaks, just take the old version that works and fork it.

ののののの, bad idea. The Godot codebase is huge and old versions of Godot leave out stuff by design. Even the latest experimental versions haven't fixed show-stopping bugs. Oh, but they will, they say. If you're using Godot, you have to accept that things are broken and features are missing, and you can't expect to fix that stuff. I also agree with Lyberta on the domain-specific language stuff. There are very few cases where a DSL would be useful.

If you want Unicode, as well as JSON and other fun stuff, check out the stuff here: https://github.com/to-miz/tm

[onpon4]

That has nothing whatsoever to do with Lyberta's complaint that I was responding to. I'm talking about still being able to use it down the road, which applies equally no matter how good or bad the engine is. If version X works for you, and version X+1 does not, you fork version X and continue its development in the different direction you need, or you could just use it as-is.

[fluffrabbit]

I think you're not understanding my response. Current Godot version is 3.X. It sucks and I would not use it, but let's say that Lyberta uses it with the expectation that everything will be amazing in a couple of months. That doesn't happen. Instead what happens is the API changes in undocumented ways (has happened with Godot before) and all of your code breaks. Then you have a choice of either forking Godot and fixing it (good luck with that one) or fixing your own code to match whatever the baka decided to insert into their game engine, fully expecting that you will have to do the same every couple of months if you want fixes for problems that were there when you started using the damn thing.

[freemedia2018]

Instead what happens is the API changes in undocumented ways (has happened with Godot before) and all of your code breaks. Then you have a choice of either forking Godot and fixing it (good luck with that one) or fixing your own code to match whatever the baka decided to insert into their game engine, fully expecting that you will have to do the same every couple of months if you want fixes for problems that were there when you started

Major pet peeve of mine as well-- not sure what some developers have against keeping APIs remotely stable. Cults are constantly revamping their paths to enlightenment / redemption / acceptance so that people who wish to move forward keep shelling out more money, or doing more to obey the people who outrank them. It keeps the devout helpless. Unfortunately, some development environments act like cults in this regard. I don't think it's intentional, they have their reasons, etc. But it's a huge turn-off for me.

[Lyberta]

Or you can just reuse code that already does that. Python has most of this stuff as simple syntax and/or functions in the Python Standard Library:

{l Code}: {l Select All Code}

>>> s = "初めまして！Abbyです。お名前は？"
>>> print(s[2])
ま
>>> print(s[::-1])
？は前名お。すでybbA！てしまめ初
>>> print(''.join(reversed(s)))
？は前名お。すでybbA！てしまめ初
>>> print(''.join(sorted(s)))
Abby。おしすてではまめ初前名！？
>>> print(s.lower())
初めまして！abbyです。お名前は？
>>> print(s.upper())
初めまして！ABBYです。お名前は？


Now try that with emojis that have skin tone modifier and gender modifier. Or rainbow flag emoji. I can't even paste it here because it breaks forum. I assume most of your text contains grapheme clusters consisting of 1 scalar value. That's too easy. Also, proper operator [] would be incredibly slow...

Casing: what about German "SS / ß"? For case folding you need a locale. For sorting you need a collation table because same characters sort differently in different languages. So obviously .lower() and .sort() are wrong because they take not enough parameters.

[smcameron]

Languages are dying faster than they are evolving. That is to say on Day N, fewer languages exist than on Day N - 1. I embrace this, and assume that eventually, one language will prevail, and all other languages will go extinct. I view this as a Good Thing. It's good if all people may communicate with one another and are not hindered by language barriers. I also think it would be good if the language that wins this inevitable competition is easily representable by computers. English, with only 26 letters and very few diacritical marks, and having a head start in computing, is well suited. Let's hope it wins. To that end, I only support English. Let's hurry up get this over with and all be able to communicate in English. /s (not really /s... it's inevitable anyway, let's get it over with.) Emojis, as a part of the character set, should be executed on sight. If you can't express it in ascii, then you shouldn't be trying to cram it it into a string. If your character won't fit into a single byte, then it doesn't exist. If you are enabling multiple languages, you aren't making the world a better place, you are perpetuating the current awfulness.