lethedwarddavidsonworld-blog

[lethedwarddavidsonworld-blog]

Signalis Doom - 6

Not a bunch to show, i've spent days burried in tutorials and training on various programs. I was much rustier than i thought. The realities of the amount of sprite-art required is a bit daunting. It's at minimum a couple hundred sprites. My first plan was to hand prototype these visuals, but even that is a bit much. So I'm gonna experiment with creating Spine2D rigs for the characters. most of the characters are humanoids, some taller than others. It Makes sense to build a common rig fore them. So that's where i'm at, i've realized that i'm gonna have to either go with a photo-model method, or a 2d rigging method based on character turnarounds. None of the models i have use rigs that would work for what i need, so i'd need to rerig everything anyway. Always a bother to grind away for days and make progress but none of it visual. oh well, back to it.

[lethedwarddavidsonworld-blog]

Signalis Doom - 5

Not much today either, it was mostly a mix of overcoming issues with 3d models in doom and figuring out some workflows.

3d models are still considered sprites, so to get models to display properly, it involves a degree of pointing the engine to look at invisible dummy sprites and then swapping those with the model. Odd stuff. There's better formats than this one and i'm going to look into those. That being said, i'm unsure how much i'm gonna commit to 3d, right now it's just experimentation. what I'll prob end up doing is spending a day banging out a buncha mockup sprites to approximate some chars and start mapping. Just enough to get the idea. tbh i could be doing way more mapping to establish a level language than i am, i'm kinda putting it off to play with textures and i gotta diversify.

I'm considering commissioning some artists for some spritework, either on specific characters or UI elements or such. I know i'll want something done for the opening splash. Most of my time today, and the next few days, is going to be spent reacquainting myself with a host of tools. I've been doing gamedev for years, i went to school for 3d animation, and i've spent a great deal of time in alot of art tools. However, i tend to forget how they work very easily. I realized i'm not gonna get anything done unless i take the time to remember how the following tools work; 1. Maya for core animation(could be a problem, iqm is the newest doom format and the community pipeline is best setup for blender, but we'll see how it goes) 2,. Blender for import/export/better compability with some aspects of gzdoom 3. Photoshop for photo manipulation of the existing textures and as a means of either creating new textures, or givng more nuance to ones i create elsewhere. 4. Aesperite for core pixel art. Signalis is a mix of low rez painted works and pixel art, and knowing when to deploy each is a good idea. 5. I'll need to get a proper toolkit up for the model to 2d pipeline, i have options but they need to be tested. 6. FL studio for audio manipulation. 7. and imma be real i don't know how spreadsheets work and i'm gonna need a hell of a spritesheet to organize what assets i'll need to recreate. That sounds like a lot but i've used them all before, and i'd need to more or less do the same thing for any real production anyway.

On the plus side, i think i've figured out how to do the floors. i'll just take elements of the original textures, and build a larger one out of them with built-in variation for tiles and color variation. I'll add more variation as needed in-editor.

I'm realizing i'm spending alot of time in odd spots. To be honest, i've never done a fan project like this before, much less one working with OG textures. I'm having a tough time getting my head around not only the unique nature of doom modding (releasing contnet packs taht can slot into any game) with full game production (Og maps, mechanics, story with bespoke stuff) ontop of fanworks (fanfiction, recontexualization of original assets). part of me wonders if my focus on getting og textures working is a mistake, as it's putting me in a mindset that's not the most useful for my project. But we'll see, I'll get my priorities straightned out, this ain't getting done overnight either way.

[lethedwarddavidsonworld-blog]

Signalis Doom - 4

Another mixed bag of a day, largely spent on textures. Did you know video games tend to have alot of them? So today's issue came from me grappling with the fact that what's good for Signalis texturing is not good for Doom texturing. At first, i didn't see the issues though. Signalis's Textures are all actually at or around doom's texture resolutions, and it's sprite sheets can easily be chopped up into good looking walls and pillars and such.

The problem comes from two places. 1. these are textures made to wrap around a 3d model, not laid out along a floor or a solid wall, so i had to figure out exactly how i was going to chop it up. Do i have a few solid pieces? do i chop it up into a dozen small ones so i have the most control? the answer is it's gonna vary.

For example. here's a chunk of the Penrose and it's wall texturing. The entire room is one model, and every part of it(including the lil' spires in the corners) are all pulling from the same sheet. Each part is meant for dif stuff, which explains why some chunks are much brighter, or darker, than others. That's great for UVing, but i don't really know what i'm supposed to do with something like this. What do i do with the clearly darker chunk of wall? Sometimes, there are walls that have a lil' extra line on the bottom, or the top, and i don't know why. I think they'd texture rooms so that dif parts would look better to the camera angle. That's great for their angle, but a bit odd in first person.

I mean it guess it's not that weird, but i think it'd have to edit it to have a more natural falloff or somesuch. It doesn't look great ported as-is, and this problem comes up alot (this is a minor example tbh) 2. Doom's textures more often than not are expected to look acceptable when used on large surfaces. This means floors and walls and such need to be able to tile (or repeat forever) cleanly, but without drawing too much attention to the repetition. Like a walking loop, you don't want a specific action to pop too much because it'll call attention to the loop.

Signalis's textures, however, are often very small textured tiled very aggressively. It's something that you don't think much about in a slow game from a pulled back perspective. However, once you're low to the ground and moving at a clip, not only do you notice the repetition, but it can honestly get a bit nauseating to see the patterns whoosh by.

the floor textures look like this. Most areas are made up of the middle tile in the ring, with the ring parts often running along walls. The bits on the righjt and bottom are often used to break up the visuals. At first, i thought this would be a big problem. The 32x32 tiles just repeat too hard to look good. However, i am a dummy, and forgot that this is pretty easily solved by breaking the ground up and slotting those tiles in.

Now, it's more work than it'd be on a 3d model, cuz i'm gonna need to remember to do this manually. But, that solves the problem of using the little details. Doesn't really solve this tiled floor being a nightmare to see stretch on forever, but at least it's something. --- I spent a bit of time working on getting some 3d models and stuff into the game as a test, which didn't go great. The community models for the characters are fantastic, however, they don't deform well when converted to the .md3 format.

GZDoom doens't used fbx files, it uses OBJ for static stuff, and MD3 (an old quake 3(?) file type) for stuff with animations. It's an old old format, and only really works via a couple of blender addons or old modeling programs. Conversion from obj/fbx/ect to md3 can always be funky, i don't really know why, it just can be. Sometiems it works, or sometimes you need to model in md3 from scratch. i don't know how far i'm gonna go with that. I also played aroudn with getting sprite turnarounds of the characters. However, that's going to take it's own tech setup that i didn't give much time to today.

Overall, a pretty frustrating day, but i got alot more stuff in-engine and figured out mass naming schemes and so on. I can't say i've really solved any problem, but I'm gonna pretend noticing the problems is progress in-of-itself. So uhh, i dunno, hey do you wanna see Ariane's bathroom? god, poor girl, 20(?????) years in that tube and this is what she's got to work with.

(the blender scene is not mine, it was assembled by a very skilled person on the signalis discord. all credit goes to whoever did it, they're a godsend)

[lethedwarddavidsonworld-blog]

Signalis Doom - 3

I suppose i forgot to mention that i plan to update this every day i work on it, which so far, has been 3 days in a row. Today was both productive and a total bust. It was mostly spent writing a tool to help me mass import the various textures into doom. Since the og files are sprite sheets, i need to split them up via a text file. It's a predictable pattern, so i figured i'd automate it with a python program. I'm rustier with python than i thought, and even when i'm not getting in my own way, it turns out i overlooked some important things. Not every file is named consistantly, enough are that it threw me.

The common naming scheme is LOCATION_TYPE_IDENTIFIER. the top two are ROT_WALL_ORANGE and ROT_WALL_BLANK. but the third is just MED_WALLS. In the doom editor, any texture files must be named 8 characters or less. You can get away with keeping the source file named something longer, but you need to create a cute truncaded name somewhere at some point for each file. I had planned to have a program scan each file and create names. it woudl read ROT_WALL_ORANGE, and by using the hyphens are markers, grab 3 letters of location, 3 letters of type, the first letter of color, and then a number. ROTWALO1. Great idea in theory, but as mentioned, these files don't all actually follow that pattern.

So that was the better part of a day down the drain. It was a good learning experience, and a reminder that there's times to brute force stuff and there's times to automate a process. It's not gonna be the last time i spend too long on a bad idea, lemme tell ya. There is already an existing tool that does do much of what i was trying to acomplish, but would require me to rename the og files. I had wanted to keep them named the same to assist in easier file replacement later with original material, but at this point it's more trouble than it's worth keeping them as they were. but since i don't have anything to show, uhhhh.... hey i bought this Signalis fanart recently from @Legend_Knit on twitter. it looks great! def check their stuff out if you haven't already.

[lethedwarddavidsonworld-blog]

Signalis Doom - 2

Didn't get much done today, most of it was running into texturing issues and figuring out various ways to work with the doom TEXTURES lumps. Some aux stuff related to the project got done too, but not much i can put on a Done boartd.

Was reminded that projects built on direct use of ripped assets aren't exactly legal. I mean, i knew that obviously, but the doommodding scene is flooded with this stuff, all of the time, and really none of this is legal. But most of that stuff is from older releases or very similar things to itself. I can see it being different for a small game like Signalis that came out so recently vs 20 or 30 year old games. rose engine is cool with video using ripped assets, but less fan games, and that's fine. this is a learning exercise right now anyway.

The plan for now is to utilize these assets, mostly the textures, to find out what i would need for the finished product. Once i can get a proof of concept up and running, some custom maps made, ect, then i can look into creating replacing them with original assets before any sort of public release.

[lethedwarddavidsonworld-blog]

Signalis Doom - 1

Starting a devlog now that i have a few lil things to show. I decided to get back into gzdoom, and i decided early on that since nobody had done Signalis Doom, i might as well. I've spent a few weeks on zscript and auxilery stuff, not doing as much mapping as i should. But i'm finally getting around to the Sig stuff.

There's a great deal to do here; i'm planning a full weapon replacement, enemy replacement to a degree, new textures, new maps, and new systems like companions and implimentaion of visual distortions. It's alot.

I've put togehter a todo board to help with this. Frankly, it's more fun to add things to the board than to do things on it, but oh well.

A critical issue that is going to come up again and again is that Signalis is a game made for a very specific camera angle, and the art is made to reflect that. Many of the textures are made to look best from that specific angle.

The lil black lines here ontop feed into the dark ceiling, as sig doesn't have any roofs. The bottom is meant to sell the connection between floor and wall. looks fine from an angle, looks odd in fps.

I can account for that, extending parts and removing dark lines and turning them into more conventional textures. that'll take alot of work for every one of them however, and woukld need to be done on a case by case basis as some have it more than others. I'm unsure if i should even bother, or jsut convert them as-is. We'll see, it's a stylistic choice. Using a texture lumpw ould let me mass import the wall models, so that's my first step, getting the walls and floors adn anything that follows a pattern in here.

people have modeled and textured much of the game in useable blender files, so i have a wealth of resouces to pull from. other people have done alot of the work here, i jsut need to assemble it.

Today, i'm planning to get as many of the textures in there as possible. Later, i'll need to start figuring out how i'm going to do the weapons/enemies, ie with custom sprtie art or sprite rendered models or just normal model md3s. we'll see.

it's alot of work but since i'm working with premade(stolen tbh) assets, it's going to go alot smoother than it would otherwise.

[lethedwarddavidsonworld-blog]

The Caligula Effect 2

Test Text Temp Text: It's alright. Strong idea for a combat system let down in part due to it's slow pace. Fascinating concept, people reliving an idealized version of their youth, but doesn't do much with it as it keeps the old pasts a mystery. Alot of room to play with why grandmas and children and 45 year old burnouts all are pretending to be high schoolers, and some of that is there, but it keeps these thoughts as reveals and late-game wrap-up fodder instead of using it for material throughout.

[lethedwarddavidsonworld-blog]

test