Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Vapourware Codexian Game Development Thread

Catacombs

Arcane
Patron
Joined
Aug 10, 2017
Messages
5,938
"Interesting" map generation ... on TikTok. :decline:
 

Zed

Codex Staff
Patron
Staff Member
Joined
Oct 21, 2002
Messages
17,068
Codex USB, 2014
When creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?

ecgIkU1.png


Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.
I've done exactly this. Well, not exactly, as I didn't load or swap images, just hide/show (they were always loaded).
Actually I've done it a couple of times.
Only game I ever finished though was this for a 64x64 frame size contest: https://phantomax.itch.io/totaq

The actual game has all logic in a grid on the side with simple wall collision for showing/hiding walls, and the rendered first person view is all the player sees.
 

Justinian

Arcane
Developer
Joined
Oct 21, 2022
Messages
252
When creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?

ecgIkU1.png


Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.
Only game I ever finished though was this for a 64x64 frame size contest: https://phantomax.itch.io/totaq
I remember playing that ages ago.
 
Joined
Dec 24, 2018
Messages
1,783
Changed the way labels are registered with the renderer. Each letter is now a separate render object. Character mesh quads are reused.
Changed label generation to be something similar to Paradox's method, although I don't do the secondary main least squared fitting line (yet). A spline is now generated that is supposed to generally fit in the shape.
Changed label registration to use the supplied spline for model transformation.

Broadly, this actually works. As you can see in the attached image, it's not altogether correct - text is not centred along its advance, and tends to extend out, and then, once it's extended, go off in crazy directions - but I believe this is primarily a tuning issue and can be fixed by massaging values to get the text advance set correctly & keep the far ends of the splines under control, rather than needing a fundamental rework. At any rate, curved labels. I will never make fun of silly Paradox names on a map again. This shit is hard.

zonescurved.jpg
EDIT - improved with some tuning and moderation, eg the points used in the spline are now averaged with the main linear-least-squares-fitting straight line to soften the amount of overall variation. There's more to be done (middle of the shape should be preferred unless an offset line produces a longer length by a certain factor, not just any longer length), and some edge cases that aren't quite right, but this fixes the most egregious issues.
zonesimproved.jpg
 
Last edited:

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,952
Location
Adelaide
I will never make fun of silly Paradox names on a map again. This shit is hard.
I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.
 

Victor1234

Educated
Joined
Dec 17, 2022
Messages
255
I will never make fun of silly Paradox names on a map again. This shit is hard.
I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.
Indeed, although others also did it before them (1997):

ezgif-5-404a1002ad.png
 
Joined
Jan 31, 2023
Messages
57
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.
I think you're heavily overestimating the amount of effort it would take. Especially if you start form a premade template. That'd take like a week or two of intensive work imho, depending on the size and complexity of animation. You obviously dont need to animate every possible character separately, just have a body sprite + armor layer + weapon layer + hair on top.
 

LarryTyphoid

Scholar
Joined
Sep 16, 2021
Messages
2,233
The whole texture atlas business is a bit over my head right now, so for the time being I'm going to load each texture individually from separate image files, and worry about packing all of them later. Hopefully I won't have to dig up too much of my own work when I get to that point. There's a whole bunch of texture packing applications on github and elsewhere, including the one from dungeoncrawlers.org that was posted in this thread earlier, but I would like to have a command-line variant that can be run along with the compiler in the makefile, and finding a suitable candidate for that has left me spinning my wheels for almost a week.

Besides that, the only other formidable obstacle I see in my immediate future is properly implementing thin walls (IE, a Wizardry-style in which any given tile can have any combination of the 4 walls surrounding it, rather than tiles merely being full or empty, as was discussed at length in Grauken's thread on the subject). Thankfully, some insight on that subject has already been given by experienced devs in the aforementioned thread.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,952
Location
Adelaide
texture individually from separate image files
try using a texture array instead then, its the alternative method to atlasing. They can work together too but in some scenarios such as tiling textures we'd want to avoid an atlas and preference the array instead. I would check if your engine supports it (most do).
edit found a good video on the subject
 
Last edited:

LarryTyphoid

Scholar
Joined
Sep 16, 2021
Messages
2,233
try using a texture array instead then, its the alternative method to atlasing.
It sounds like the easier method just from the name alone. I might try it out later, but for now I'm just gonna have all the textures sloppy and unorganized so I can make some visible progress that I can show off to someone. I've told friends that I'm trying my hand at gamedev and I don't want them to think I'm a slacker (even though I am).
 

TheDeveloperDude

MagicScreen Games
Developer
Joined
Jan 9, 2012
Messages
406
No-nosense Football. You manage a football team. Buy new player, make tactics.
How can I improve the grafix for this game? I have no idea. Any suggestion?
 

Ysaye

Arbiter
Joined
May 27, 2018
Messages
771
Location
Australia
No-nosense Football. You manage a football team. Buy new player, make tactics.
How can I improve the grafix for this game? I have no idea. Any suggestion?


You could have panels flanking each of the left and right squares respectively; I was thinking something like:
  • For the recruitment pages, you could had footballer silhouettes with the left panel backgrounded with one of the colours, and the right panel with the other;
  • For the tactics pages, have coach silhouettes down the side; and
  • For the actual game, have some supporter babes silhouettes (because you have to bring some sex appeal?) or otherwise some fat drunk beer flinging supporters - in this one the colours at the back are different and outline the seats or stadium or something.
Was also thinking maybe underlining the squares you could at least have the football field markings, and for the game picture, having netting represented with some hatching for the locations where the netting.
 

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,224
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
The whole texture atlas business is a bit over my head right now, so for the time being I'm going to load each texture individually from separate image files, and worry about packing all of them later. Hopefully I won't have to dig up too much of my own work when I get to that point.

What sort of scene complexity do you have in mind? If it isn't anything complex you may not need texture atlases at all.

This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000:

 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,952
Location
Adelaide
This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000:
You've got the camera facing down so your draws are minimal, you've got good efficient use of tiling and all of your characters are reusing textures. Makes sense why it runs well.
You probably didn't need an atlas, and texture arrays didn't exist back then so it was probably best practice for what you were trying to do at the time.
 

LarryTyphoid

Scholar
Joined
Sep 16, 2021
Messages
2,233
What sort of scene complexity do you have in mind? If it isn't anything complex you may not need texture atlases at all.

This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000:
Just a simple 2D game. I might not need to do it, but I'd rather do everything in a relatively efficient manner rather than being sloppy and relying on modern PC power as a crutch.
 

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,224
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
You've got the camera facing down so your draws are minimal, you've got good efficient use of tiling and all of your characters are reusing textures. Makes sense why it runs well.
You probably didn't need an atlas, and texture arrays didn't exist back then so it was probably best practice for what you were trying to do at the time.

Camera didn't make much of a difference, i don't show it in that video but there were keys to switch cameras to behind the player. Also remember that this used a separate "draw polygon" call for every single (world) polygon in the world *and* each (world) polygon had a separate lightmap texture.

As another example Post Apocalyptic Petra's Direct3D renderer doesn't have a top down camera and runs fine on a Voodoo 1, no atlasing either:

JssBdox.jpg


...though it does try to minimize state changes (also no lightmaps). But while it was expensive back in the 90s, in modern hardware (where modern means anything released in the last 10 years) state changes do not affect that much (you can do more than a million texture state changes per second even on 10 year old GPUs - and you are likely to hit other limits before reaching that :-P).

I think unless you are going for something like early 2010s AAA 3D scene complexity you most likely wont see much of a difference in practice on modern hardware. Which is why i asked for the scene complexity.

Just a simple 2D game. I might not need to do it, but I'd rather do everything in a relatively efficient manner rather than being sloppy and relying on modern PC power as a crutch.

On a 2D game you are more likely to notice overdraw issues and that only on weak hardware and assuming your game has a lot of overlapping 2D elements (GUIs, etc).

To give you an idea, i wrote a quick and dirty program that generates 4096 128x128 textures and then draws a 64x64 grid with them (4096 unique sprites at the same time on screen is most likely way beyond what most 2D games show - assuming 32x32 sprites you'd fit less than half of that in a 1080p monitor without any form of scaling and that is, again, about drawing all unique sprites at the same time):

mimYSmy.png


(the textures are random and while they all look the same each "box" is a unique texture)

On my PC (which is already ~4 years old) i get the ~350 fps shown above, however it drops to about 30fps on my GPD Win 1. Note however that this is done via the simplest way possible using client side vertex arrays (i.e. sending the same vertex data over and over for every frame) and the GPD Win 1 struggles to run the original FEAR with its CPU (which is the limiting factor) being a weak Atom from 2015.

In a more realistic scenario where your game does some texture reuse and you only try to draw what'd be visible on screen instead of everything, even by still sticking with the client side vertices you'd easily be able to get 60fps on the GPD Win 1.

If you are trying to make some first person dungeon crawler ala Wizardry, etc you could just dump everything on screen without any concern for performance. This crawler-like maze i wrote some years ago:



...doesn't try to do any optimization (it draws the entire maze and objects all at once) and yet it runs even on some ancient Pentium 133MHz laptop using Microsoft's software rendered OpenGL, let alone anything with a 3D capable GPU :-P.

IMO it is much better to make something that works first as you need it and if there is a performance concern try to fix once you have something to compare your optimizations against. Even if you just want to optimize for the fun of it, it helps to have a reference point as well as some sort of target hardware in mind for what you are making (personally i use old/weak computers i have around).

Also keep in mind that i'm not trying to dissuade you from using atlasing or texture arrays, just making clear that if you are worried about them then depending on what you are trying to do they may not be a concern in practice.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,952
Location
Adelaide
I think unless you are going for something like early 2010s AAA 3D scene complexity you most likely wont see much of a difference in practice on modern hardware. Which is why i asked for the scene complexity.
I mean its valid. I'm just recommending things on that its one extra thing in the toolbox that I find interesting as an alternative. As has been said countless times by game developers, you only optimise when it clearly appears what you've done simply isn't working as efficiently as possible. If your implementation runs fun there's no need it is overkill. That said I'm recommending it from a standpoint that I have run into these problems in the past and in the present, this is of course more truer for 3D games especially at the scale I work at (ie. lots of unique objects in a scene) in that situation you need those tricks to keep everything smooth. For a 2d game it comes down to how many unique sprites are being rendered at any one time. If working to limitations you won't need these tricks.
To give you an idea, i wrote a quick and dirty program that generates 4096 128x128 textures and then draws a 64x64 grid with them (4096 unique sprites at the same time on screen is most likely way beyond what most 2D games show - assuming 32x32 sprites you'd fit less than half of that in a 1080p monitor without any form of scaling and that is, again, about drawing all unique sprites at the same time):
I've written a similar program myself, but my resolution was a lot higher and limited to 32-Bit single core. I was able to get into the thousands of textures on screen and still hit 60FPS using individual textures not atlases or arrays. Textures are extremely cheap. If we use the modern methods though it can be even cheaper, depends on the scope.
diagonallevels.png

This was meant to be a doom style engine, whilst all of those textures look like they're the same they're actually individual instances (there is no actual tiling going on I hadn't implemented it yet, I eventually did and broke the entire thing so had to abandon it, it broke because the face normals kept flipping and I couldn't work out why, I suspect it was a bug with using Directx9 on modern windows because it worked fine in XP, frankly it was a dumb project but I learned a bit from it). Fortunately it was only about 6 months of work, I eventually decided 3D engines were the way to go instead and haven't looked back since. The characters used 32 possible viewing directions, it was super smooth and utterly horrendously optimised, no atlases/spritesheets and it still ran perfect. Reason for the rainbow texture is that its the most taxing on color use so it was really filling up the Vram, the textures are 512x512 if I recall properly.

It certainly does depend on the scope of what you're trying to do.
 
Last edited:

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,224
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
I've written a similar program myself, but my resolution was a lot higher and limited to 32-Bit single core.

I kept the resolution small to avoid VRAM availability and bandwidth becoming an issue itself and affecting the benchmark (4096 512x512 RGBA textures would already be 4GB of VRAM data - that is 8 times more than the entire memory XBox 360 had and 16 times more than the VRAM PS3 had :-P). Atlases and texture arrays would still have the same (if no larger) VRAM requirements and the issue atlases (and for this particular use, texture arrays too, though there is more to them than that) is CPU bottlenecking the GPU due to multiple draw calls.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,952
Location
Adelaide
4096 512x512 RGBA textures would already be 4GB of VRAM data - that is 8 times more than the entire memory XBox 360 had and 16 times more than the VRAM PS3 had :-P
Well I mean I was looking at it from the perspective of this game would take years to develop, so by the time it came out that would be the norm as far as hardware is concerned sure enough I was right. But having your game stuck on windows XP due to a bug was a bad idea given its market share which is why I gave up, and well the 90s shooter fad pretty much died down in recent years I was trying to get it out during its peak, when Ion Fury released I was just like "nope not gonna get anywhere near how good this game looks and plays with this tech I've built" credit to Ken Silverman guy knows how to make an engine that can stand the test of time. If I could've licensed Build I would have. (I was under the impression the commercial license was separate from the source license you find online, I can't find reliable info on it but Ken says to do it you have to contact 3D Realms/Apogee)

This program was supposed to work with that voxel program I showed earlier in this thread, eventually I would've combined the two programs as I said reason for abandoning the voxel program was due to the fact there are better programs now, given the success of voxel doom though I think I was onto something, I just didn't have the resources to get it to where it needed to be and covid ruined everything. Voxels were replaced with pre-rendered meshes which is what you see in that screenshot. Eventually I just figured, well I'm going this far might as well start using Unity again. And now I'm using both Unity and Godot. Prior to this doom clone I was working on a flight sim in unreal 4, that project failed because someone beat me to it. (world war 1 battlefield clone focused on Aviation, yeah bad timing yet again).

I'll repeat that saying indies say, Don't develop tools, develop games. Most of what you're going to want to do has been done and probably been done better.
 
Last edited:

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,224
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
I'll repeat that saying indies say, Don't develop tools, develop games. Most of what you're going to want to do has been done and probably been done better.

That saying is actually kinda different from that interpretation: it is "write games, not engines" but the idea behind it isn't to not make your own engine (IIRC was written before even Unity was available on Windows, at a time where you either had to write your own engine or buy something like Torque). The idea is that if you are making an engine to make it for a specific game you have in mind with specifical goals, gameplay functionality, development limitations, etc instead of trying to make an engine without any specific goals as this will result in a bunch of random functionality that most likely is going to be useless in practice. In other words, your goal should be "write a game", not "write an engine" as the former will have specific needs whereas the latter is too vague.

Also note that this was originally written mainly as advice towards new developers who wanted to make their first engine (and besides a lot of commercially successful indie games have their own engines), though even big fat engines nowadays often started as games (e.g. pretty much all id Tech engines were written for specific id games, Unreal Engine started as the engine for Unreal, etc - even Unity was originally written for GooBall :-P).

With that in mind, here is a screenshot from my latest work in Little Immersive Engine :-P

S2VtAn6.jpg


It has been a long time since i last worked on the engine since i was busy with work and (most importantly) other projects (i got a modded original xbox and wrote some graphics for it - it is interesting since i'm using the open source nxdk instead of the original SDK and nxdk does not really have a graphics API aside from a few helper functions to construct a push buffer for the GPU, so you essentially have to write your own 3D graphics driver - and that without documentation, just looking at existing code from projects like the xemu emulator, which itself isn't 100% accurate :-P, as well as nouveau and whatever samples come with nxdk).

Recently i mostly fixed bugs with face deletion and undo/redo support. But now i also added some new functionality to extrude selected brush faces into new brushes, thus allowing the creation of the structure in the image above :). I still need to implement grid at some point - and of course some way to assign materials to faces (though ok that is kinda easy so i keep on skipping it).
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,237
Location
Poland
Strap Yourselves In Codex Year of the Donut
Here's the initial revision of the object inspector. Eventually it's going to support references between objects and similar non-trivial features. It has a declarative syntax that runs at compile-time.

Untitled.png


There's not much else done so far (json and sprite pipeline improvements, fix for a nasty coordinate formula bug, fixed-point 16-bit scenery time deltas) but I've had trouble resuming work on the game in the first place so it should be easier from now on. I should revise some specifics of the collision detection implementation and then add a barebones player character.
 

Nathaniel3W

Rockwell Studios
Patron
Developer
Joined
Feb 5, 2015
Messages
1,234
Location
Washington, DC
Strap Yourselves In Codex Year of the Donut Codex+ Now Streaming!
Hey Bad Sector are you the Das Geisterschiff dev? I just picked up Duskers for free on the Epic Games Store. It looks like it has kind of the same feel as your game. And it looks like Duskers may have been pretty successful. Almost 2000 reviews on Steam makes me think that game must have made at least $500,000 in revenue. Have you played it? How do you think it compares to the geister games?

Edit: My bad. It's zwanzig_zwoelf. Wazup zwanzig?
 
Last edited:

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,099
Location
デゼニランド
Hey Bad Sector are you the Das Geisterschiff dev? I just picked up Duskers for free on the Epic Games Store. It looks like it has kind of the same feel as your game. And it looks like Duskers may have been pretty successful. Almost 2000 reviews on Steam makes me think that game must have made at least $500,000 in revenue. Have you played it? How do you think it compares to the geister games?
Duskers has been on my radar for a long time and I bought it a while ago, but I'm yet to play it and thus unable to say if they have anything in common.
 
Joined
Jan 9, 2011
Messages
2,728
Codex 2012 Codex 2013 Codex 2014 PC RPG Website of the Year, 2015 Codex 2016 - The Age of Grimoire Make the Codex Great Again! Grab the Codex by the pussy Insert Title Here RPG Wokedex Strap Yourselves In Codex Year of the Donut Codex+ Now Streaming! Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Codex USB, 2014 Shadorwun: Hong Kong Divinity: Original Sin 2 BattleTech Bubbles In Memoria A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Steve gets a Kidney but I don't even get a tag. My team has the sexiest and deadliest waifus you can recruit. Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
Hey Bad Sector are you the Das Geisterschiff dev? I just picked up Duskers for free on the Epic Games Store. It looks like it has kind of the same feel as your game. And it looks like Duskers may have been pretty successful. Almost 2000 reviews on Steam makes me think that game must have made at least $500,000 in revenue. Have you played it? How do you think it compares to the geister games?
Duskers has been on my radar for a long time and I bought it a while ago, but I'm yet to play it and thus unable to say if they have anything in common.
I haven't played zz's game, but Duskers is good stuff. One thing I didn't like though
is that none of the plotlines are ever conclusively resolved. Would really like to know more about what is the shit that went on.
.
 

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,224
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
RPfG3Ee.png


Added a polygon tool in the brush editing mode where i draw an arbitrary polygon and it converts it to brushes. I still haven't implemented texture alignment options or even grid, so the test in the screenshot above is a bit off but in the future it'll be possible to make odd shapes and rough layouts quickly using this.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom