XCOM Inspired Fantasy Game

[Galdred]

Hey!
That's a pretty impressive game project! I really like the Amiga/Atari aesthetics, and the flooding is impressive!

TLDR: my biggest mistake was picking squares over hexes. I would recommended hexagonal lattice even for real-time strategies. Unfortunately Blizzard doesn't feel enough competition to fix their competitive games and make the next Stracraft into a perfect game.

Spoiler:

I am working on another pretty different XCOM inspired fantasy game, and I decided to go with hexes for the same reasons you recommended them, more or less.
What triggered me the most with squares was that formations don't work if both sides are not facing each other from the main directions, which should happen a lot in a game with large maps and fog of war (because you cannot have proper Zones of controls with squares).

However, it has been a huge pain to make walls and buildings, so I am still really torn about the issue. It really makes the wall tiles hard to read in term of blocking movement and LoS.

Spoiler:

The NW->SE walls don't follow the hexagonal lines which causes all sort of issues.
I should have gone with natural caves instead of constructed walls.

So I am not sure you really were wrong about picking squares.

[NancyGold]

Hey!
That's a pretty impressive game project! I really like the Amiga/Atari aesthetics, and the flooding is impressive!



I am working on another pretty different XCOM inspired fantasy game, and I decided to go with hexes for the same reasons you recommended them, more or less.
What triggered me the most with squares was that formations don't work if both sides are not facing each other from the main directions, which should happen a lot in a game with large maps and fog of war (because you cannot have proper Zones of controls with squares).

However, it has been a huge pain to make walls and buildings, so I am still really torn about the issue. It really makes the wall tiles hard to read in term of blocking movement and LoS.

Spoiler:

The NW->SE walls don't follow the hexagonal lines which causes all sort of issues.
I should have gone with natural caves instead of constructed walls.

So I am not sure you really were wrong about picking squares.

Astonishingly good looking project! As for implementing the hex tiling, check Age of Wonders games. Especially the first AoW, which had walls for castles and dungeons.

I myself currently got dragged away with all the refugee life issues and the camp management now threatening me for filming a fight (they believe that all happening in the camp must stay in the camp). Although I have finished my own C-like language (called NewC), featuring an extended macro processor, which fixes all the issues impeding me from using the old CPP. Had to do that, since I really dislike C++, but still for the voxel editor I need custom types, like vec3 and bounded checked arrays with O(1) push. I can't do the voxel editor in Symta, since performance is really so critical. The NewC is not so much a compiler, than a very tricky rewriter (I'm not that crazy to implement my own optimizing compiler), replacing `vector.x` with `vec3_get_x(vector)` and `auto` with proper types. Obviously it is totally incompatible with C++, doing the right thing in the wrong way, breaking every single C++ textbook good practice, and encouraging the use of macroprocessor instead of templates. In fact, that is one of the reasons I had to re-implement the macroprocessor, because the C's one, while turing complete, is just too clunky to use for anything beyond basic `#define PI`

Anyway, I have rewrote the core voxel format several times, implemented the OBJ importer/exporter, developed a few voxel editing techniques, and got some insight into deforming the voxel models without SDF. Which I could use maybe for Spell of Mastery 2, since it really requires GPU.

TLDR: parsing C using C is much easier than writing a voxel editor, which is much easier than implementing a video game. Like an order of magnitude easier.

[NancyGold]

Ok. Refactored the macroprocessor into standalone library around 2000 sloc. Now it can be used to preprocess say Lua code. Dunno if anybody will buy it at itch.io and I have no idea where one can sell C/C++ code, or what price to set for it. Usually people just give it free of charge for no reason or attach some crazy copyleft license like GPL. Still it is in C99, so could be used with any project, even to generate HTML pages from templates. I personally will use it to preprocess the game code and config files. Sometimes it is just so much easier to do a lexical macro, than a syntatic one - and generally they solve orthogonal problems than happen to have similar subsets.

Code: [Select]

New C macroprocessor improvements over the original C preprocessor.
- Succinct declarations: instead of `#define PI 3.14`, we now have `#PI 3.14`
  `#if #SYMBOL` instead of `#ifdef SYMBOL`
  #once, instead of `#pragma once`
- Calculate arbitrary functions!
    #fac(n,x) #if n>0 fac(#[n-1],#[x*n]) #else x #endif
    fac(10,1) //factorial of 10
- Ability to redefine punctuation, like `+` and `-`, and to do it only in the
  specific context of another macro.
- Nested macros with different scopes, just like normal C variables.
    #x 123
    x //expands into 123
    #{
      #x 456 //shadow the x defined above
      #<x=#[x+1]> //increment x by 1
      x //expands into 457
    } //interior x gets out of scope
    x //expands int 123
- No need to escape newlines with `\`:
    #foo {
      printf("hello");
      printf("world");
    }
- Much easier to use variadic args. For example:
    #last([xs],x) x
  picks the last element of the arglist.
- Macros can be defined anywhere, not just at the start of line.
  For example:
    #x 123
    #y #z{456} x z
    y
  will expand into `123 456`
- Macros can be expanded inside of strings.
- Macros arguments can be inserted into strings:
   #foo( x, y ) "#x+123+#y"
- Allows calling an external program with arguments. For example:
    #+ -
    #(echo "a+b")
  will expand into `a-b`: first external `echo` command is called with "a+b"
  Then then its stdout is being macroexpanded.
- Special builtin command #(say ...) printing to stdout. Useful for debugging.
- Nested / * * / comments.
- When a function-like macro invokation has no () arglist,
  NCM takes as the arguments everything up to the newline or the //-comment
  That would allow user the create elegant looking DSLs.
  Or use NCM to preprocess assembly files:
    #myopcode(a,b) {...}
    xor ax, ax
    myopcode bx, ax
- Available as a single header library and can be used to preprocess
  other languages, like GLSL.
- Escapable comas in arg list.
- A way to change `#` to another character, if you use the macroprocessor to
  preprocess a language where `#` is used for, say, comments.
- Auto adding extension ".h" to files without one.
- And much more!


[Galdred]

Spoiler:

Astonishingly good looking project! As for implementing the hex tiling, check Age of Wonders games. Especially the first AoW, which had walls for castles and dungeons.

I myself currently got dragged away with all the refugee life issues and the camp management now threatening me for filming a fight (they believe that all happening in the camp must stay in the camp). Although I have finished my own C-like language (called NewC), featuring an extended macro processor, which fixes all the issues impeding me from using the old CPP. Had to do that, since I really dislike C++, but still for the voxel editor I need custom types, like vec3 and bounded checked arrays with O(1) push. I can't do the voxel editor in Symta, since performance is really so critical. The NewC is not so much a compiler, than a very tricky rewriter (I'm not that crazy to implement my own optimizing compiler), replacing `vector.x` with `vec3_get_x(vector)` and `auto` with proper types. Obviously it is totally incompatible with C++, doing the right thing in the wrong way, breaking every single C++ textbook good practice, and encouraging the use of macroprocessor instead of templates. In fact, that is one of the reasons I had to re-implement the macroprocessor, because the C's one, while turing complete, is just too clunky to use for anything beyond basic `#define PI`

Anyway, I have rewrote the core voxel format several times, implemented the OBJ importer/exporter, developed a few voxel editing techniques, and got some insight into deforming the voxel models without SDF. Which I could use maybe for Spell of Mastery 2, since it really requires GPU.

TLDR: parsing C using C is much easier than writing a voxel editor, which is much easier than implementing a video game. Like an order of magnitude easier.

Thanks! I did play all the AoW (except 3) a lot actually. I am sorry about your refugee camp issues. It is a real disgrace that we in the West created so many, then handled the problem in such an inhuman way. I hope your situation will get sorted soon enough. In which country are you now? The Netherlands?
Regarding selling your code, you can just call it an engine, and you should be able to do so, but with everyone using Gamemaker, Unity or Unreal Engine, it is harde to compete (the one I use, Moai, got completely destroyed by the competition of Unity, because it lacked tutorials, documentation, and things like the asset store, which come with a large user base).

[NancyGold]

Thanks! I did play all the AoW (except 3) a lot actually. I am sorry about your refugee camp issues. It is a real disgrace that we in the West created so many, then handled the problem in such an inhuman way. I hope your situation will get sorted soon enough. In which country are you now? The Netherlands?

Yeah. I'm in NL for now. I believe Age of Wonders developers are Dutch, and Dijkstra too!
Fallout 1 and 2 also had hexes and rectangular walls.

Regarding selling your code, you can just call it an engine, and you should be able to do so, but with everyone using Gamemaker, Unity or Unreal Engine, it is harde to compete (the one I use, Moai, got completely destroyed by the competition of Unity, because it lacked tutorials, documentation, and things like the asset store, which come with a large user base).

Well I doubt you can use C/C++ with Unity (it is C# only) and a macroprocessor is not really a video game engine, but a general text processing utility (like a regex library), which you can use for all sorts of things.
For example, if you want unique numeric ids in your config file, you can write

Code: [Select]

    #count 0  //a variable like macro
    #next() {#<count> #<count=#[count+1]>} // define a function like macro
    next() //expands into 0
    next() //expands into 1
That can also be used to implement gensyms in C/C++

Then plain C/C++ doesn't support optional and keywords arguments, yet one can still have them using macros:

Code: [Select]

    void foo(int x, int y, int z) {...}
    #foo(x,y=123,z=abc) foo(x,y,z)
now foo macro will supply the default values for y and z,
and user can also call

Code: [Select]

foo(456,z=789) too supply argument only for z

it is a single header library, so it can be piggybacked to any text input.

[Yankes]

Well I doubt you can use C/C++ with Unity (it is C# only) and a macroprocessor is not really a video game engine, but a general text processing utility (like a regex library), which you can use for all sorts of things.

MS created C++/CX or C++/WinRT that allow to interact with C# types (exactly with CLI). In theory this could work for Unity too.
At leasy you run pure C# code that simply call C++ dll using p/invoke.

Then plain C/C++ doesn't support optional and keywords arguments, yet one can still have them using macros:

In recent C++20 standers you could write something like this:

Code: [Select]

foo({.x = 5, .y = 6});


[NancyGold]

MS created C++/CX or C++/WinRT that allow to interact with C# types (exactly with CLI). In theory this could work for Unity too.
At leasy you run pure C# code that simply call C++ dll using p/invoke.
In recent C++20 standers you could write something like this:

Code: [Select]

foo({.x = 5, .y = 6});


I believe Unity uses its own implementation of C#, and I'm not even sure if there is any proper FFI interface. Unity is like a walled garden, and its users expect everything to be in Unity format. Unreal Engine appears to be a much better alternative, since one can use any language with it. I think there is a need for a more general source code marketplace, like stock photo sites. No idea why none have appeared in all these years.

[NancyGold]

The progress is slow, but steady. Most of the work is on the New C language, which now includes most of the C++ features and few of its own, yet in a way that makes them useful for my programming style. I.e. I want to do IntVar[bit] to test if a bit is set in particular variable, without introducing a standalone bitfield struct, and New C allows me defining [] for builtin types. I also prefer composition over inheritance and macros over templates, but C++ isn't really about it.

Anyway, I have implemented loaders for the Ken Silverman's Duke Nukem engine voxel files. His format, instead of octrees, uses RLE and has visibility mask for each voxel column, allowing to render voxels really fast on 90ies hardware, with the limitation being that voxels are axis aligned (most older games had hacks for rendering axis aligned stuff). Still very impressive. Would be cool to see a Duke Nukem mod for OXC.

Next target is refactoring the Symta lisp implementation to support JIT, and then continuing to work on the game. Without JIT, it the complexity gets out of control (I can't reuse the interpreter core for ingame data) and I can't debug the game while it is still running, having to rely on stack traces.

[NancyGold]

For some reason I believed that the original 1995 Command & Conquer had voxel sprites, because these tanks rotated rather smoothly and had voxel looking shading. It didn't. Instead it used RLE compressed sprites with a lot of angles, and in case of tanks, turrets were drawn separately. Only Tiberian Sun had voxels, and just for a few larger units and aircrafts.

[NancyGold]

Westwood Tiberian Sun models are hollow inside and have holes in the bottom. That makes it non-trivial to properly calculate normals for them (without patching the holes manually). Yet the normals are stored inside these VXL files (in the form of indices into one of the normal tables). All that makes me believe that, that Westwood people haven't used any voxel editor to create these models, but instead rendered them from the usual 3d mesh, created with the old boring polygonal editor. There is also no existing footage of the Westwood voxel editing tool.

On the opposite side, Koen van de Sande created actual voxel editor for C&C ( https://www.tibed.net/voxel ), which modders used to draw a ton of new voxel models for the game. It is a rather tedious process, since the editor has no real 3d view, instead showing sections of the model, so modders have to set voxel individually. As I understand, that project was part of his BSc diploma: http://voxelcoloring.sourceforge.net/

Apparently that was one of the first true voxel editors in existence.

[NancyGold]

Goed avond, folkje!

Recently I did a total overhaul of the Symta language, fixing most of the issues which were discovered during the game development.
In addition I've added support for the bytecode interpreter, so now I can execute Symta code during runtime as a script.
That allows to introspect and modify the game engine while it is running. I can't stress enough how useful it is for debugging.
The code itself is being lexically macroprocessed using https://nashgold.itch.io/new-c-macroprocessor
The same macro-processor I use to preprocess my C code.

The Symta code now looks more like Haskell.
Here is an example of the function parsing `if/then/else`
There are several version of `if` syntax - one normal if A: B else C` and `if:`, which is more like Lisp's `cond`
In addition during the transition phase I have to support the older `if A then B else C` form, till I clean the code out of it.

Code: [Select]

parse_if Sym =
  OCol Sym.src.1
  if is_next `:`:
    T expect `:` Sym
    X parse_offside 0 0 Sym.value Sym.src.0 OCol
    ret  :: Sym X.0
  Cnd Then No
  Head parse_xs 1
  if is_next `then`:
    Cnd = Head
    T expect `then` Sym
    Then = parse_offside 0 0 T.value T.src.0 OCol
  else
    if Head.end or not Head.0^token_is(`:`) then
      parser_error "missing `:` for" Sym
    Cnd = Head.1
    case Cnd [H [K [@L] [@R]]]: when K^token_is(`or`) or K^token_is(`and`):
      Cnd =: K [H @L] R //huge kludge
    Then = Head.2
  Else:
  if is_next `elif`:
    T expect `elif` Sym
    GInput =: T.retok(`else`) T.retok(`if`) @GInput
  if is_next `else`:
    T expect `else` Sym
    Else = parse_offside 0 0 T.value T.src.0 OCol
  :Sym Cnd Then Else


So I hope to continue working on the game.
I have already made it work with Windows in rather botched way.
Shadows are really buggy, since on Windows I compile with GCC and it doesn't have the proper SSE code for alpha blending.
Main menu is also slowed down to 1 frame per second. And I have no idea what causes it.
I had to disable pthreads, since the Windows version is just agonizingly slow, taking 1 second to perform the stuff that should be microsecond.
That is due to very slow switching, even when usleep gets explicitly invoked.
Moreover, I don't have access to a real Windows machine, so Virtual Box add its of quirks.
TLDR: a ton of issues to solve.

[Yankes]

Code: [Select]

Shadows are really buggy, since on Windows I compile with GCC and it doesn't have the proper SSE code for alpha blending.What version of GCC you used? I couple of times play with SSE and windows version support it.
One solution used by OXC and OXCE is https://mxe.cc/

[NancyGold]

Code: [Select]

Shadows are really buggy, since on Windows I compile with GCC and it doesn't have the proper SSE code for alpha blending.What version of GCC you used? I couple of times play with SSE and windows version support it.
One solution used by OXC and OXCE is https://mxe.cc/

Some old version, I have stashed on the virtual machine image.
It doesn't have all the Xintrin headers.

Code: [Select]

#include <emmintrin.h>
#include <smmintrin.h>
#include <xmmintrin.h>
#include <immintrin.h>

And the mouse sampling frequency problem is related to SDL working improperly with the Virtual Box driver, which intergrates mouse and clipboard with OSX, so one can use mouse without the mouse cappture.

[NancyGold]

My voxel editor, VoxPie, finally sees the first public release
https://nancygold.itch.io/voxpie

I have also learned a bit about video editing by creating a trailer for it.
And now I better understand the requirements for making the animation easier.

[NancyGold]

Cheers! Breaking with my bf really affected my sanity, but Im still alive
Most of the changes went to the Symta - the Lisp programming language dialect behind the game.
But I'm working on the game itself now, which required refactoring the entire codebase, due to the language changes.
I've completely settled with the background story, blending all the elements I had in mind, so that they will drive the gameplay nicely.
The demon invasion is still there but it gets proper development now.
Think about XCOM organization existing as a contractor for some time, before the actual alien invasion, but then gets redirected to fight it.
And the stuff XCOM does during that time affects how the alien invasion will proceed.
Obviously my game has mercenary organization, instead of XCOM, but otherwise it is the same.
Yeah I'm using the extra-planar demons instead of aliens, because fantasy and stuff, but Might & Magic had space demon aliens too in a fantasy setting.
Almost connected all the points to make the game completable from start to finish.
Even after that it will require a ton of polish. The ideas.txt list is like 100kb, while the todo.txt is 50kb.
And TODO has the stuff I really need in game for it to play right.

Currently working on the basic intro movie. I thought about adding a simple storyboard for now, but syncing it with music and voice acting will be huge pain. I can put it together as a standalone movie, but it will require some decoding library, which will need some syncing too. The final goal is to do that movie in my voxel editor for the moderately cheesy effect.