RockstarRaccoon

I'm thinking there's a way to mess with this using ZScript, in GZDoom, but I have't screwed with it yet. If you can't though, speedrunners will likely just roll with it...

Back it on IndieGoGo! | Indie DB | Website | Watch the Promotional Video! Membrane is a retro-ish shooter being developed in the GZDoom engine. Featuring fast gameplay, expansive levels, and fun sci fi weapons and powers. In it, you play as an alien abductee who has been implanted with a highly adaptive life form, the "Membrane", as part of an experiment gone right... Or perhaps horribly wrong! Fight your way across 5 massive maps, solve puzzles, and develop an arsenal of weapons and adaptations to terrorize the army of little green men in this twisted take on the Retro-Shooter genre. A 2 map tech demo has been released, and is available on Indie DB. We expect the game to be much longer and more impressive than that, but we just wanted to give everyone a feel for what we have so far. We've just launched our crowdfunding campaign on IndieGoGo to try and get more seed-capital for this, as working on this is very time consuming and takes some more powerful hardware and software to develop effectively. (seriously, GZDB was running at 10FPS on my old computer by the time I upgraded) If anyone is interested in buying and playing this game, you can do so now, through our IndieGoGo, and you'll be first in line with a copy by the time it's fully released! It's $15 to pre-order for release, and $20 to get early-access to development builds, which we think is a relatively low price compared to other games of this caliber, but you have to buy while the campaign is in progress. There are some other goodies for people who want to throw down more, like a physical copy for $50 and a model of yourself in the game for $200, so if any of that interests you, you oughtta do that before the campaign ends! SELECTED SCREENSHOTS Go check out our IndieGoGo Page and ZDoom Forums Thread for more details!

If you think it's a scam, don't spend money on it. No one needs to. Other people will, and they will probably be happy with what they get. They aren't that ridiculous for what they are. $15 - $20 is about what a game of this type normally costs on Steam, maybe on the high end of that, but nowhere near as much as, say, a more A-list game. I don't disagree that they're on the high side, but we do fully intend to give people something worth that amount of money. Keep in mind, this is a game with almost entirely original assets, with bone animated models and high resolution textures, and none of the enemies, items, or landscapes are supposed to resemble anything on Earth. Don has been working on the designs and models in his spare time since before that first demo came out. There is a lot of content here, and you've only really seen what is in a usable state. Anyway, sorry I haven't been too responsive, I'm actually working on setting up releases for a couple projects I had to put on hold for this.

Actually, we're trying to differentiate from the pile of lackluster "retro shooters" on Steam by looking at what they're doing and trying to do things which will stand out as different. Many of them seem to rely on tossing a bunch of enemies at the player in relatively straight-forward maps, which is actually NOT 90s design, but post-COD "hallway" design. These are going to follow more of the "adventure" style that Doom or Hexen had.

Well, let's keep in mind that this is all Alpha footage, but that's true. There are plenty of really cool things in the community just like this that you can get for free. We're hoping to be different enough from them, through both the weirdness of the setting and the polish of the final product. We've talked about the pricing scheme, but that's really Don's call, so I'm not really the person to be talking to about that...

Looks like a typo to me... Thanks for catching it.

It depends. Are you making this for a newer source port? If so, I believe most of them can do that with SBARINFO. If not, I'm pretty sure you technically can, but weird stuff happens when you do. I suggest you try dicking around with this stuff: this would be easy enough to test by say, making a picture of a circle that's like 30x40, and trying to get it to take that. You might even find a new trick there...

You should be editing your WAD file with SLADE, so that everything is packaged together. Otherwise, you will have to package the other WAD with it. What version are you mapping for? If you're going for a more modern port like ZDoom or Eternity, you might want to go with PK3 instead of WAD, as it's easier to manage.

I've actually encountered the same error, so I'm pretty sure it's a problem with SLADE. I don't remember how or if I fixed it. How about you try editing in indexed color format in the first place? I know GIMP supports that...

Yeah, we plan on using pretty much every feature and facet of GZDoom to make this look pretty much like a modern game, but we'd also like to see people making maps and mods for this like they do with the 90s games like Chex Quest and HACX. Have you tried the demo we just put out? :3 And you know if you give us money you don't have to wait for the release, right? :P

Heh, I remember that model...

That's an understandable reason not to, but I will note: in this day and age, a couple extra MB isn't considered unreasonable.

You don't need to redraw the whole map for this, just the outsides of it, to make sure they're closed. I'd also recommend that, in the future, you start by building out your entire map and then work out the issues in the way it plays, THEN go for the intense details. That way, you know your gameplay is the best it can be before your map is filled with things which will be hard to rework later.

You might also consider what I did in Metroid Doom: include Andrew Hulshult's IDKFA versions and use those, so that you not only have a good version of it, but can guarantee that the player has what you're intending in the first place without taking something that wasn't originally intended for use in mods.

I think it should be stated that, in the end, this is an engine using methods designed to run smoothly on 90s hardware. Unless you are trying to do a particularly impressive project (or using portals), you can probably assume that it will run relatively well on a newer computer. If taking time to worry over this means you're not going to have the time to make your project really shine, don't worry about it.

Membrane has it, and I'm pretty sure it's in the demo. I think you have to look in MOVEMENT.ACS and PLAYER.DEC. Like I said, it's something to do with a variable, but I've yet to really pour through and do the overhaul I'd like to, so I don't know the specifics. The fake inventory thing is another possibility, but I would think with ZScript you should be able to streamline it even more, possibly to a simple "if player is running then this instead" type declaration...

BAM. That's it. The new model format likely won't have a limit on the number of animations or keyframes.

It's not a sprite name definition like crouching, so it's a bit more complicated. Looking in Membrane, SuperDon apparently set up a variable within the player actor and has it determine whether to use the Walk or Run state definition. He sets this stuff up from a looping ACS script which looks at the player input and alter's the player actor. I'm not sure he's using the best method here, but I know it works.

There's a setup in Membrane where don used like, more than one sprite name to define like, 50 animations, and I don't think he even had those sprites in the PK3. He just replaced them all with a model animation. (he uses bone animation and converts it automatically, so he likes to animate at 30 FPS or higher) That's the kind of thing you can get away with. Go nuts! :3

The other thing you might want to look at is the "Map Analysis" tool, which can be used to scan it for potential bug-inducing problems.

Perhaps you should look into GZDoom's new "ZScript" feature. We are looking to implement tracking of a few other variables in Membrane using the control it provides...

You should look into dynamic lights, as having a TON of sectors is really not good for performance when compared to good use of attenuated spotlights and such...

I like making them really dark (below 128) and then only lighting them through various stuff in the map, like brightmapped textures, maybe glowing flats, maybe fireflies, maybe lights on structures, and usually a player flashlight of some sort. I also like to toss a few dark, moving clouds into the sky. The trick is to just think about what it's like to wander around outside at night, maybe even go outside at night and take a walk in some area without heavy lighting for reference, and make the in-game look like that.

https://zdoom.org/wiki/MAPINFO for information on what is probably the best way to do it. You want an Intermission Definition, and you set it as if it were the the next map. I'll warn you, this is without word-wrap, so you're going to have to play around with placing the '\n' character in there to wrap it manually. You can also call it in the middle of a map, if you're using a more recent version of GZDoom with ACS, using the StartSlideshow command. (which I don't think is on the wiki, but I know is in there because it was my feature suggestion and I used it)

GZDoomBuilder re-evaluates the sectors and lines to see if you're trying to attach some new piece of geometry to what you have every time you draw a sector. If this is unusually slow, it means you have something wrong with the way it's organized your geometry and probably need to rebuild a chunk of it. I suggest going around the edges of your major features and manually rebuilding some of that geometry, line by line, so you can find the places where it either has a line of length 0, or two lines don't actually connect, or whatever is causing this. It is annoying, but 90% of the time that is what is causing the problem. And instead of using sectors for those lighting effects, I'd suggest you look at dynamic lights, as they're gonna work much better for you here, both in ease of use, quality of look, AND (since you have way too many sectors) the speed at which the map edits, saves, loads, and runs. Merging those sectors and replacing the lights with attenuated spotlights and maybe a bit of specular mapping should make this better all around...