Vapourware Codexian Game Development Thread

[Nathaniel3W]

Tavernking I know what you mean. My first game Himeko Sutori was one long string of good-enough solutions that I came up with when I didn't really know what I was doing. It's possible that development would have taken a lot longer had I stopped to learn the "right" way to do everything. Maybe it would have taken so much longer that I would still be working on it, or Kickstarter backers would complain, or the game would have lost all interest. So maybe the good-enough solutions worked for me. But Himeko Sutori was also a crash course in all things gamedev. I learned a lot and before starting my next game, I took more time to prepare. The code that I copy/pasted without really understanding? I studied that until I understood what it does. The slapdash UI that was slow, unresponsive, and ugly? I learned all of the best practices of every aspect of UI development in my engine and I completely replaced the UI in the next game. That's going to make my next game better, but I don't know how well that would have worked on a project when your concern is just finishing it.

 

[Twiglard]

So I'm thinking the next step in gamedev is adding an entity system. But an entity system needs code for editing properties in the UI. So I'm writing some generic code. Here's how instantiating individual accessors won't need to specify template parameters.

struct TestAccessors {
    constexpr int bar() const { return _bar; }
    constexpr void set_bar(int value) { _bar = value; }
    int foo;
    int _bar;
    int _baz;
};

using entity = Entity<TestAccessors>;
static constexpr auto m_foo = entity::type<int>::field{"foo"_s, &TestAccessors::foo, &TestAccessors::foo};
static constexpr auto m_bar = entity::type<int>::field{"bar"_s, &TestAccessors::bar, &TestAccessors::set_bar};
static constexpr auto r_baz = [](const TestAccessors& x) { return x._baz; };
static constexpr auto w_baz = [](TestAccessors& x, int v) { x._baz = v; };
static constexpr auto m_baz = entity::type<int>::field("baz"_s, r_baz, w_baz);

Later on they'll be put into a tuple and iterated over.

template<typename F, typename Tuple>
constexpr void visit_tuple(F&& fun, Tuple&& tuple);

This is thanks to deduction guides (see previous link). Accessors can be one of several things (pointer to member variable, pointer to member function (i.e. bar() and set_bar()) and new types can be added through partial specialization. Reminds me, have to add a generalized operator() specialization.

C++20 concepts are used for accessor types and higher-order functions to help with debugging template instantiation.

This is all fun and games, but then they need their types erased to be put into a single container. But this can be done with no overhead because readers and writers are static constexpr with global lifetime.

 

[Twiglard]

Virgin std::type_info

• bloated code
• undefined reference to typeinfo of T
• std::type_info not constexpr
• can't even take the const char* from type_info and rely on comparing pointer value
• name is mangled/"""decorated""" anyway

vs chad __PRETTY_FUNCTION__

• supported by every compiler
• only pay for what you use
• compiler coalesces definitions
• -fno-rtti/GR-
• dynamic_cast is slow and for pussies anyway

---

My 'reflection' code is pretty much done.

template<typename T>
requires std::is_same_v<T, std::decay_t<T>>
struct entity_metadata final {
    static constexpr StringView class_name = name_of<T>;
    static constexpr std::size_t size = std::tuple_size_v<entities::detail::accessors_for<T>>;
    static constexpr entities::detail::accessors_for<T> accessors = T::accessors();
    static constexpr auto erased_accessors = erased_helper(accessors);
};

All this fancy 'reflection' data takes exactly no time to compute.

Time to make some widgets to edit entities' slots member variables.

 

[Bad Sector]

But an entity system needs code for editing properties in the UI.

The weird thing is that this sort of functionality not only was around in other languages since the 80s (e.g. Smalltalk's metaclasses) but many frameworks, including even some by C++ vendors (e.g. Borland) provided some version of it since the 90s - and yet it still isn't something that C++ can't natively provide by itself. The compiler already knows this information and yet there is no way to "bake" and access it from the compiled program.

Free Pascal "inherited" this feature from Delphi which had it in 1995 or so, so in my engine i can do

TEntity = class(TRootObject)
published // like "public" but generates RTTI info
  // Property Foo, generates code that whenever is read it is treated
  // the same as a direct memory access but when it is written it becomes
  // a call to the "SetFoo" method
  property Foo: Integer read FFoo write SetFoo;
  // Property Bar is read-only
  property Bar: TSomeBar read FBar;
end;

These can be accessed via RTTI functions and are used not only to generate the property editor UI, but also implement object serialization, undo/redo steps for anything that is stored in properties, automatic asset loading and dependency tracking, etc.

As a bonus you can also add attributes to the RTTI data (like "@SomeProperty(SomeParameter=SomeValue) property MyProperty etc") so that you can e.g. have a string that only accepts values that match a specified regular expression or just tweak how the editor UI will present some specific property (via property attributes, e.g. declaring the acceptable range of some numeric property) or edited data type (via class attributes, e.g. declaring that by default whenever the editor is to open an asset editor for a property that point to an asset, to open the asset's editor in an overlay window instead of a new tab or frame).

In C++ that stuff is possibly only through either using an external tool like Unreal's "header tool" that parse header files and generate source code before the build is made (so it isn't really a C++ feature itself) or via some macro-based RTTI (this is what an engine i worked on at a company in the past used), assuming of course you don't want to declare the RTTI information by hand (which is what the engine of another company did and was as error prone as it sounds :-P).

(there is also the x-macros-based approach where you write all the types to be exposed via RTTI in header files as macro invocations with multiple different macro definitions that expand to both type declarations and RTTI code for registration, serialization, etc - which has the bonus of working with plain C too - but this can easily cause compiling times to explode as new types are added)

Supposedly there are plans on adding that stuff in C++ at some point but they seem to be low priority.

 

[rusty_shackleford]

Are there any modern RPG developers who publish their editor with their game besides Bethesda and Larian?

 

[Wunderbar]

Are there any modern RPG developers who publish their editor with their game besides Bethesda and Larian?

solasta devs?

 

[TheDeveloperDude]

Do you have any idea what the problem could be?
I have this game. itch.io
It is written in LWJGL2.
I have been making/playing it for 10 years. LOL.
Now Somebody has downloaded it at last. And the 3D rendering is total black. post with screenshot
Is it possible the basic OpenGL rendering/lightning is not working on every PC?
What can I do? I have one PC and one video card, Radeon 5750 with Windows 10.

Anyone could try it, please?
Instructions to starting: New game->Roguelike->OK. You should decrease the relics number from 20 to 1. It will generate fewer files in your userhome\motuw directory.

 

[Tavernking]

I have been making/playing it for 10 years. LOL.
Now Somebody has downloaded it at last.

In a thousand years, one hundred people would have played it! You're doing good my man

 

[Twiglard]

Some time ago I already managed to correctly play scenery animations. But they weren't real gameworld objects, and it was high time to change that. Because reading pixels back from the GPU is expensive, I decided to implement clicking (aka 'picking') through bit arrays attached to each animation atlas. Having the bitmask as well as screen position and size of a scenery item is enough information to establish what is under the cursor.

So I computed the screen position of a scenery item through chunk's[1] camera offset and projection of the tile coordinate[2] where the scenery item is located. Printed the result each frame, then grabbed a screenshot and compared the drawn position to the value being output. It didn't work. Tried a dozen formulas. Then came the realization. Well, this is embarrassing.

I haven't configured HiDPI scaling. The viewport was being scaled by the OS!

It explains some shady things[3] going on. So this is why I enabled MSAA so that the floor and walls won't look like shit. Now that a real solution is known, all MSAA code can be deleted. It was absurd using MSAA in a 2D game.

So now you can click on scenery items but you can't place them and there aren't any more kinds than a single model of doors. I'm going to add some just so that a UI for placing scenery can be made.

Then comes storing scenery data in a save file, and maybe then I can finally start making the UI property editor.

1. A chunk is a grouping of 256 tiles so that they can be drawn in a single batch and arranged in memory in a way that eliminates padding between the tiles' data types.
2. Here's a chunk with coordinates of individual tiles shopped in.
3. Tiles had their semi-correct size when scaling in the shader through gl_Position = 1/viewport_size * position But the correct formula is 2/viewport_size, as opengl's screen coordinates exist in the range of [-1, 1].

 

[Ysaye]

Trying to make a blobber in C with SDL2 for a first project. I figured it'd be easy, since Wizardry came out in 1980 and programmers were basically smashing sticks together back then to my limited understanding, so it couldn't be that hard nowadays. Very naive of me. There are TONS of resources for top-down grid-based games because of the Rogue-like development community, but first-person games seem to be entirely absent. I got cocky because I wrote a simple text-based RPG in Python for school, and fiddled with Rogue-like code, but now I'm stumbling at something I thought would be simple: the grid-based movement itself.

So from what I've gathered, grid-based maps are stored in multidimensional arrays, and the value of each element indicates what sort of tile it is, and then there's a variable for the player's position which moves through the array depending on player input. That's all pretty simple and it probably goes without saying for most in this thread (if I've gotten it right, that is). What I'm really stumbling at is the turning perspective: there's gotta be four different angles for each tile to simulate a first-person perspective. So would you have something like a "perspective" array with 4 different values depending on which cardinal direction the player is supposed to be facing?

I just discovered this thread and I'm gonna start reading through the earlier pages to get some more information, but if you guys have any good resources on blobber development I'd appreciate it; that way I wouldn't have to bother you with newbie questions like this.

This might also interest you if you want to go down the route BadSector was suggesting within the Godot environment:

 

[Twiglard]

I'm almost done with scenery code in the editor. Individual scenery pieces are specified in a .json file that later populates the editor's UI. Some scenery pieces such as doors have to be animated so scenery is implemented internally using animation atlases. There's no harm in treating static scenery as one-element animations because atlases are allocated only once per image file. To get a scenery piece facing in 4 cardinal directions, only 2 frames are necessary thanks to horizontal mirroring.

So now I can place interactive doors and they activate the same as the ones that are hardcoded.

The UI looks like a good starting point for further editor and game logic development.

Doesn't look too impressive but it took a better part of a week writing all sorts of infrastructure to make it possible. Setting up sprites so that they could be rendered only took one evening.

I still need to write code for saving scenery to disk. It would be pretty cool if saving a door mid-swing and reloading it repeatedly finished the animation in progress. One thing I hated while playing STALKER was enemy AI resetting on quickload. Hopefully I'll be able to avoid similar issues with scripts after finally integrating luajit.

 

[quaesta]

For my musicbros, how do you go about making some background tracks? I noticed in OSTs I like they have an A B C section, or is basically a loop that has several altercation/automation in place for it, to give the illusion of movement. Besides that, I noticed you got to be careful with the EQ/volume levels, to not conflict with the game's soundscape. One technique I really wanna try is applying a compressor of the song to the sound effects, so if a loud sound effect occurs the music quiets out, and/or if a high bitch noise (like a fairy/sparkle) occurs, the song gets filtered to give more room for the effect

 

[MF]

For my musicbros, how do you go about making some background tracks? I noticed in OSTs I like they have an A B C section, or is basically a loop that has several altercation/automation in place for it, to give the illusion of movement. Besides that, I noticed you got to be careful with the EQ/volume levels, to not conflict with the game's soundscape. One technique I really wanna try is applying a compressor of the song to the sound effects, so if a loud sound effect occurs the music quiets out, and/or if a high bitch noise (like a fairy/sparkle) occurs, the song gets filtered to give more room for the effect

You make background tracks as you would any other music, although sometimes you can cue up movements in reaction to what's happening in the game. That's just a matter of modular composition.

For levels you need mixing channels in game with duck settings applied to mixer ratios. EG. music channel ducks when the voice and SFX channels get louder, etc. You don't use a compressor, it's more like fader automation. Most engines have built-in support for this combined with spatial mixing, but the basics of channel ducking are easy enough to roll from scratch. Look up Ducking as a concept and you'll find all the info you need.

 

[Twiglard]

Serializing scenery now works. I've added a CI test that serializes a sample chunk to disk (also known as saving the map inside the editor). So let's talk about how saving the game was originally implemented and how the original issues were solved.

The project uses the nlohmann/json library for data declarations (aka 'proto' using terminology inherited from Fallout). It's a nice library where you declare the method of serializing each individual data type using template partial specializations. It's difficult to get it wrong but compile-times are slow. Fortunately, serialization can be defined in a separate library without needing to even forward-declare the json library inside normal game logic.

The very first implementation of saving used json to dump chunks into disk. The first time it worked, the resultant file (as before: a chunk is 256 tiles) took 50 KB in size. Replacing spaces with tabs made it half that. Removing json indentation altogether still made it larger than 15 KB. Trying to save using binary json formats such as CBOR doesn't help either as they fail to deduplicate strings such as tileset names that were being saved for each tile separately.

So let's write a new serializer. You know how a serializer works. Member variables in the form of pointers to start and end iterators (latter for reader only), amount of bytes read/written, some operator<< / operator>> and byte-swapping for non-floats endian-wise. Thankfully, C++23's <bit> already has a constexpr version of std::bit_cast (implemented in GCC, Clang and MSVC) so it can be tested at compile-time without bothering with unit tests.

The wire protocol is straightforward. Only serializing scenery is more complicated than deduplicating id's of tile atlases. Each tile has flags which can be different from the scenery proto that's defined in a .json file. Scenery protos can reuse the same image (referenced by name in the .json file) but with different type and flags (flags such as whether it allows passing through it, whether it blocks the view, whether it's a door that's open etc.). It's only necessary to output a full definition if flags aren't set to default values. Otherwise the scenery id and scenery rotation all fit within 16 bits.

So yeah, now I can load some test saves made in the earliest version and add scenery to them.

 

[LarryTyphoid]

I'm getting a pretty good grasp of the basics of SDL2. Now I'm gonna start with the wireframe visuals. I've gotta get the dimensions down and construct a rudimentary user interface, because I plan on later applying textures to each "sector" of the screen which will be drawn by a friend. Hopefully I'll have something to show before long.

Reading these ancient sources like Gardens of Imagination and the Game Developer's Magazine makes me really respect people like Cleveland Mark Blakemore, and also envy them, for being there when software development seemed a more respectable field. Everything at my college computer science course seems so fucking gay. Speaking of Gardens of Imagination, I've been appreciating that it's been validating some of my previous thought process on how to construct a maze; it's nice to have some confirmation that I'm not an utter retard once in awhile.

 

[Zanzoken]

Am I the only one who thinks voxel environments look pretty sweet, but voxel characters look like shit?

These are all done by the same artist.

Environments

Spoiler

Characters

Spoiler

I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

Don't quite have it figured out yet but it seems like 3D assets converted to look like pixel art is the way. And probably better to just make the game in 3D and keep the camera in a fixed perspective to achieve the 2D effect.

 

[zwanzig_zwoelf]

I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

It's not as scary as it looks. If you start with strict limitations and do your homework, it's doable with enough practice, and it might even be FUN.

You can try setting the target resolution to 320x180 (scales nicely to 720p / 1080p / 2K / 4K), picking a palette from lospec (I suggest looking for a 16-color palette), setting the sprite/tile size to 16x16 and just start drawing.

Animations aren't exactly scary as long as you find the right minimum. Romancing SaGa has about 11 animation frames per character and it works like a charm, Final Fantasy for the NES managed to get away with just 4 (for the overworld).

Humanoid characters can be cheated easily by drawing one generic character as a template and then using it as a base for other characters.

There are also tons of ripped graphics from old games out there that you can study.

 

[RobotSquirrel]

I'm having a fun time figuring out how to port over my UI stuff from Unity into Godot. It's just that Godot's documentation is really bad. But otherwise not a bad engine I'm impressed with what it can do.
I'm finally on break so I can do some light game dev stuff.

 

[RobotSquirrel]

Is there a particular reason to switch from Unity to Godot?

I'm still using unity but only for the art side of it mainly, most of the assets I bought for making art with it are amazing, some of the best game art tools I've ever used really. My main reason for considering Godot is that it just straight-up has the better license for longevity.
I will still use Unity but mainly for projects that are shorter term which I think better suits unity's workflow anyway, anything long-term is going to Godot because I know if anything goes wrong I can always fork the engine, can't do that with Unity so I'm a bit worried. Plus I hate Unity Hub so so much somehow its getting worse as time goes on.
I've been thinking a lot about how you maintain games longterm given how long it's going to take to develop any of the things I want to make, Unity's recent behavior plus them being on the stock market makes me think they're pretty vulnerable to geopolitics, all we'd need is another tech crash and suddenly Unity ain't looking so great (though neither would Unreal for the same reasons though at least their engine is open sourced). Read this as I'm pessimistic about the future of the industry (the share prices are telling), Godot would be immune to it. Those of you using SDL I am jealous lol, I lack the memory management skills to work it effectively but SDL that's a great way to ensure you stay in control of your product.

 

[Twiglard]

I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

Blender toon shader BRDF for the win.

 

[Zanzoken]

I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

It's not as scary as it looks. If you start with strict limitations and do your homework, it's doable with enough practice, and it might even be FUN.

You can try setting the target resolution to 320x180 (scales nicely to 720p / 1080p / 2K / 4K), picking a palette from lospec (I suggest looking for a 16-color palette), setting the sprite/tile size to 16x16 and just start drawing.

Animations aren't exactly scary as long as you find the right minimum. Romancing SaGa has about 11 animation frames per character and it works like a charm, Final Fantasy for the NES managed to get away with just 4 (for the overworld).

Humanoid characters can be cheated easily by drawing one generic character as a template and then using it as a base for other characters.

There are also tons of ripped graphics from old games out there that you can study.

Thanks for your reply. Unfortunately what I want to make is more of an action RPG, with lots of character customization. So if you have 2 genders, 10 hairstyle options, 10 weapons, 20 armors... all animated in 8 directions with movement, attacks, etc... if you try to do all that in traditional pixel art and animation, I think you're looking at an effort best measured in years.

It's not going to be easy regardless, but it seems like using a 3D workflow actually brings it back into the realm of possibility. The ability to reuse assets and animations is even greater with 3D. Plus there's a lot of low-poly 3D art available out there in the free / paid asset space, and Mixamo for animations.

Not trying to say you're wrong, or pretend I have all the answers. But that's kinda where my head is at the moment. Ultimately I am not married to a particular style... I just want the game to look good, and am trying to find the simplest path to get there.

 

[zwanzig_zwoelf]

I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

It's not as scary as it looks. If you start with strict limitations and do your homework, it's doable with enough practice, and it might even be FUN.

You can try setting the target resolution to 320x180 (scales nicely to 720p / 1080p / 2K / 4K), picking a palette from lospec (I suggest looking for a 16-color palette), setting the sprite/tile size to 16x16 and just start drawing.

Animations aren't exactly scary as long as you find the right minimum. Romancing SaGa has about 11 animation frames per character and it works like a charm, Final Fantasy for the NES managed to get away with just 4 (for the overworld).

Humanoid characters can be cheated easily by drawing one generic character as a template and then using it as a base for other characters.

There are also tons of ripped graphics from old games out there that you can study.

Thanks for your reply. Unfortunately what I want to make is more of an action RPG, with lots of character customization. So if you have 2 genders, 10 hairstyle options, 10 weapons, 20 armors... all animated in 8 directions with movement, attacks, etc... if you try to do all that in traditional pixel art and animation, I think you're looking at an effort best measured in years.

It's not going to be easy regardless, but it seems like using a 3D workflow actually brings it back into the realm of possibility. The ability to reuse assets and animations is even greater with 3D. Plus there's a lot of low-poly 3D art available out there in the free / paid asset space, and Mixamo for animations.

Not trying to say you're wrong, or pretend I have all the answers. But that's kinda where my head is at the moment. Ultimately I am not married to a particular style... I just want the game to look good, and am trying to find the simplest path to get there.

Don't worry, I was unaware of the specifics of your project, so my suggestion was pointing towards the barest minimum to get things started.

 

[Ysaye]

Am I the only one who thinks voxel environments look pretty sweet, but voxel characters look like shit?

These are all done by the same artist.


I am exploring methods for how one might create a 2D top-down RPG with a pixel art aesthetic, without having to hand draw and animate all of the assets.

Don't quite have it figured out yet but it seems like 3D assets converted to look like pixel art is the way. And probably better to just make the game in 3D and keep the camera in a fixed perspective to achieve the 2D effect.

No you are not the only one; I definitely agree with you that you can make some great environments even with very basic voxels but it is hard to make good looking characters and animation can be a total pain.

I have mucked around with voxel graphics quite a bit (mainly for sticking into RPG In A Box which at the moment is good for setting up a Voxel world and interactions with items though still I don't think has the right setup for combat which renders the whole thing a bit meh) and there are two things I have concluded with respect to voxel characters for games:

(1) Rather than trying to "pixel" rounded shapes of characters (eg. like those in your spoilers) and/or lots of alternating colour changes, I find it more attractive when characters are made 95% up of single coloured cubes and rectangular prisms. If you use this form, I like either a "Chibi" form (you can do eyes in this form - maybe say have a look at the works that Majaz Studio or some of Arthur Ciappina's works) or those with exaggerated long legs or torsos and maybe just showing the outline of the head and the hair rather than trying to detail out the eyes and whatnot (see for example some of Pawel Szpiczakowski's voxel characters or maybe the https://warlloyd.itch.io/crusader-knight or see the characters in Crossy Road); or
(2) "pixel Billboard" chess pieces with an outline (say in black) can also look really good in an isometric voxel view, and also reduces on animation costs if you are happy for those to just slide around, particularly if it is in isometric view.

 

[Twiglard]

 

[Twiglard]

Looks cool. Stuff needs some scaling, I think, because that bench looked way to big when one compare it to the doors or that other table with chairs and stool.

All assets and asset metadata are temporary. Especially wall heights, because I don't know how to best deal with them yet.