Vapourware Codexian Game Development Thread

[LarryTyphoid]

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.

 

[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.

https://www.dungeoncrawlers.org/resources/gamedev/

Is a good place to start, particularly if you are looking to make a pseudo 3D game like Wizardry 1 - 7.

 

[zwanzig_zwoelf]

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.

Gardens of Imagination by Christopher Lampton is a pretty nice book to get you started with common stuff if you have no idea where to start.

 

[Twiglard]

Have you done any research on how a feature-complete editor (or other modding environment) for isometric RPGs should look like? It's one thing to place floor tiles and walls, but another to start adding interactible objects with their own scripts and dialogs.

Is there an already-existing editor for one of the RPG's that could be considered well-designed and suitable for that purpose, so that I may incorporate its ideas?

 

[Bad Sector]

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.

FWIW Wizardry was written in Pascal which even at the time was a bit higher level than C - kinda far from "smashing sticks together". Of course nowadays it is much easier to make a game than back then but you aren't really gaining much by using C.

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.

Note that the original Wizardry games used wireframe graphics for the maze, which simplified things. Also TBH i do not see the point of using predrawn sprites for the walls these days as even OpenGL 1.1 from the early 90s can draw walls for you much easier and simpler.

Either way i'd recommend to try a top down tile-based game first since aside from the perspective there isn't that much of a difference between implementing the world and movement for a first person dungeon crawler ala Wizardry/Might&Magic and that.

Have you done any research on how a feature-complete editor (or other modding environment) for isometric RPGs should look like? It's one thing to place floor tiles and walls, but another to start adding interactible objects with their own scripts and dialogs.

Aside from making the locations/areas themselves (the tile/floor placement), setting up properties, scripts, etc for actual gameplay shouldn't be any different from any other game editor - and there are as many approaches to them as there are custom engines. I'd recommend checking existing RPG engines with editors for ideas...

Is there an already-existing editor for one of the RPG's that could be considered well-designed and suitable for that purpose, so that I may incorporate its ideas?

...like Aurora Toolset (NWN1) and TES:Creation Kit, both providing a lot of RPG specific functionality and regarded as relatively easy to learn and use - while also being quite different from each other. Also the Shadowrun Returns games have a very simple editor, though it might be a bit too simple at times. On the other hand of the spectrum is RedKit for Witcher 2 - the RPG-specific bits were somewhat inspired by Aurora's equivalent functionality but since functionality and flexibility was much more of a concern than user friendliness, they are much more complex to use.

All of those can give you ideas for how to set up the game. And TBH i'd also recommend checking out game editors in general, not just RPGs, as depending on the game large parts of them can apply to other genres.

 

[Ysaye]

Released my new game. Give it a try if you like Hydlide / Ys and want to play a short RPG where almost every line of flavor text gives you a hint towards something of interest.

Congratulations on the new game - I bought it and had a little spin on my new Aya Neo Air and it looks and sounds awesome in that format.

 

[Tavernking]

Ripping old my old black magic code and replacing it with new cleaner architecture. I'm losing a lot of cool solutions that now I'll have to rediscover the solutions for in the 'right way'. This is for the best in the long run, but psychologically feels like I'm losing weeks of progress.

 

[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?

 

[Gandalf]

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

Heroic Fantasy Games (for Knights of the Chalice 2)

 

[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.