Incline Das Geisterschiff - turn-based cyberpunk dungeon crawler

[zwanzig_zwoelf]

Started rebuilding the demo level. Thanks to the stuff I implemented the level design is way faster now.

 

[zwanzig_zwoelf]

Implemented terminals to throw additional flavor text into the level without stuffing it in player's face (storyfags rejoice).
Did extra work on dark zones, now moving on to double-check forcefields and other stuff to make sure nothing is missing.
Also figured out what to do with the teleporters in case an entity is teleported to the spot occupied by another entity. Guess I'll go with telefragging, because why the fuck not.

EDIT:
Added areas where the player is forced to use manual movement/attacking just for shits and giggles.
Did some optimizations to the renderer and lo and behold, increased the speed by ~42%, which is a massive improvement and should work out nicely for my weak-ass CPU.

 

[zwanzig_zwoelf]

Testing usage of lens flares to add some subtle fake lights to the area.

 

[Excommunicator]

I think those lights are going to be a winner

 

[zwanzig_zwoelf]

Some new screenshots.

 

[Excommunicator]

Pic 2 is best. The lights work best when they're being "textured" onto another surface otherwise then can look a bit out of place

 

[zwanzig_zwoelf]

Yeah, that side effect actually works in my favor and gives nice results. Gotta find more ways to use it to add extra details to areas.

 

[zwanzig_zwoelf]

Ok folks, bad news. Looks like I'll have to cut levels into smaller parts and allow free travel between them, otherwise it becomes a massive pain in the ass to edit and build. While the game runs fine except for a few places where I went overboard with lines, keeping the same approach will require more processing power than I have. The tutorial demo had a rather small level so it wasn't a problem, and I think twice or three times as much will still work fine, but not more. The bigger demo I was working on was roughly 60x60 tiles and had bigger requirements in general due to the amount of lines in the area.

This sets me back a few days since I'll have to change saving/loading to keep the world persistent when moving between smaller areas. Shouldn't be too hard to pull off, just need to adapt the saving system for this task and test the living shit out of it. Already implemented the transfer of player data between levels, so the rest should be a walk in the park.

Good news? This should speed up the level design and allow me to abuse this approach to imitate multi-layered areas while keeping the game running without issues on slower rigs. Also loading times are fast since the heavy stuff is loaded on startup.

 

[zwanzig_zwoelf]

Update #Deux:

• Level persistence implemented, now you can safely walk between different parts of the same dungeon. Also allows me to overcome certain limitations of the pathfinding system.
• Fixed certain issues that occured whenever the save was reloaded.
• Fixed other micro-issues (landmine/door relationship, old hacks, targeting bugs, etc).
• Config implemented. Allows one to set their own settings, such as the FPS limit, etc. Also allows to select whether you'd like to keep saves in the documents folder or inside the game folder, since a lot of folks hate when their C:\ drive gets cluttered with game files and similar stuff. I was too lazy to write the text-based config, though, so have fun fucking around with the hex editor.

Goodie, it's time to go back to level design.

 

[zwanzig_zwoelf]

Implemented a small prompt for choices, mainly as a confirmation to transfer between areas. Could be useful if I ever decide to throw in some story-related choices (although I doubt it, I'm not interested in this kind of stuff).
Still, guess now it's officially an RPG.

 

[zwanzig_zwoelf]

Had a few days without Internet connection, spent time working on the game and playing Deus Ex: Invisible War.

So:
-- One of the ingame areas for the demo is finished, 4 more to go.
-- Terminals which allow you to apply the upgrades right now (instead of holding them until the end of the mission) are implemented, but need extra work.
-- A bunch of status effects implemented, triggered upon entering certain areas. One can check how they affect stats (and notice them by the noise on the screen) and lure enemies inside these areas to gain some advantage... of course, they work the other way too. They're also affecting human and robot enemies differently, e.g. dark zones give aim and evasion penalties to humans, while barely affecting bots, while other areas render bots almost useless in combat while being just a slight annoyance to human enemies.
-- Hazards implemented. Only laser beams for now, which cause damage based on weight (the harder the entity, the less damage it does), which could be useful against smaller assholes with high evasion.
-- Added another enemy type, a spider-like bot with an SMG which doesn't do much damage unless it lands a critical hit. It's a rather mean asshole.
-- Started implementing scripted events (sidequests, etc).
-- Height is now taken into account during damage calculations, now standing above or below your enemy slightly affects the damage inflicted to the target. Doesn't help a lot when it comes to small arms (SMG/laser), except for critical hit cases, but when it comes to more powerful guns, it might as well save you (or your enemy) a shot or two.

 

[zwanzig_zwoelf]

Alright, made a new editor for lines (not only lines tho, it can also be used to create simple stuff using triangles/quadrilaterals, but w/e). Almost done testing and doing last-minute fixes and boi, this thing should accelerate the development by at least several times. Creating angled surfaces is still kinda tricky, but not as painful as before.

This little bugger took me less than a minute. Earlier I'd have to input the coordinates for every line by hand, then tweak, tweak, tweak again, then yell at the moon whenever it ended up looking wrong, which would take at least 5-10 minutes depending on how smoothly things went and how much time was wasted on iterations.

Yanno, it's funny that creating something this simple using modern tech is a pain in the butt and requires writing a custom editor, while bloom is provided by default.

Doing extra testing and last-minute fixes and going back to my game.

 

[Zep Zepo]

Now add occlusion to the parts of lines the camera shouldn't see.

Zep--

 

[Punch]

Don't mind some fluff in the UI as long as it fits the game, but if you really jerk off to mech UIs, I suggest you give Brahma Force a try.

I wish someone made a game in that style for VR devices, you know a somewhat agile and compact mech jumping around blasting other enemies like that game. Would be boss to ENERGY MODULE SECURED all day long, especially with a steel battalion like input device.

I'm going to download your game, looks damn interesting to me. Love the aesthetics.

 

[zwanzig_zwoelf]

Now add occlusion to the parts of lines the camera shouldn't see.

Zep--

I would, but I don't want to since that's how I envisioned it.

Don't mind some fluff in the UI as long as it fits the game, but if you really jerk off to mech UIs, I suggest you give Brahma Force a try.

I wish someone made a game in that style for VR devices, you know a somewhat agile and compact mech jumping around blasting other enemies like that game. Would be boss to ENERGY MODULE SECURED all day long, especially with a steel battalion like input device.

I'm going to download your game, looks damn interesting to me. Love the aesthetics.

Thanks, enjoy the demo, don't forget to bitch about it!

 

[zwanzig_zwoelf]

The improved renderer allows me to ditch the earlier fake light effects (which used raster images and kinda stood out like sore thumbs) and add new ones using simple vector gfx.
Still salty about the need to keep the graphics sparse (closer to the tutorial demo instead of the stuff shown in December thanks to the dying laptop), but at least the new editing tools allow me to use the sparse graphics more efficiently.

 

[zwanzig_zwoelf]

Also yeah, another small screenshot from one of the ingame areas.

 

[zwanzig_zwoelf]

Okay, here's a small summary of things done lately:

• Distance is now taken into account (if the target is further than the weapon range, he'll get lower damage upon getting a hit). This will make running from enemies a less painful tactic, especially since combat was always considering as the 'last resort' for the player due to ammo/hp limits;
• Implemented explosive attacks for bazooka (yeah, should've done that a long time ago). Works differently than other weapons and might as well cause some extra carnage/butthurt to players. Still, gotta do some testing and tweaking.
• Rebuilt one of the ingame areas due to changes in the way stuff is drawn.

The rest is not that interesting TBF (fixing various old glitches/oversignts). Overall, the rest of the January will be about making one of the chapters and polishing the gameplay in general while February will be all about implementing the rest (the ghost ship). Then it's all about implementing a new tutorial and the epilogue chapter and I'm all set for the initial release.

 

[80s Stallone]

is this Lands of Lore/Dungeon Master-style or what?

 

[zwanzig_zwoelf]

is this Lands of Lore/Dungeon Master-style or what?

These games have been on my to play list for a while, so I can't give you a simple answer. The main inspiration was behind Carmine (old PC-98 game) as well as Akalabeth and some other old games.

This game plays like a simple dungeon crawler with TB combat inside the dungeon, but instead of focusing on combat it's focused on long-term survival to reach the objectives since you can't replenish ammo/health while exploring the dungeon. Puzzles are limited to things like finding keycards, figuring out a shortest path to your goals within the dungeon (so if you fail you avoid wasting health/ammo on stuff you don't feel as necessary), finding landmines and disarming/shooting them to open a path or luring the enemy onto them to conserve ammo, as well as using switches to get past forcefields and finding your way through dark zones. There are also tiny twists here and there (melee attacks are limited to ramming, there are various areas which can cause extra trouble for you or your enemies, etc).

Overall this is a first project with an attempt to make a simple and short yet solid game with rather uncommon design on zero budget, on my own and within a reasonable amount of time.

 

[AdolfSatan]

Looks amazing. It's good to see that you're not trying to overshoot the scope, I'll be looking forward to play this!

 

[zwanzig_zwoelf]

Looks amazing. It's good to see that you're not trying to overshoot the scope, I'll be looking forward to play this!

Thank you.
TBH I'm kinda salty about not pulling off certain things I have in mind due to budget/tech limitations as well as doing my best to keep the project within the reasonable time limit (not interested in following VD's route and spending 10 years just on a single game when I can try smaller ideas first and use them to develop modules for bigger games I have in mind), but at least I've got something to look forward to in future projects. If this thing fails in one way or another, it can be easily modified to serve as a framework for other games and I've already got design sketches for 2 more games using this codebase in the back of my head: one is about turning the whole dungeon thing upside down by allowing you to modify dungeon layout by moving/destroying walls as well as some other things, while another one is a blobber similar to Shin Megami Tensei about gathering a party of people with psi powers and wreaking havoc in a cyberpunk city.

 

[AdolfSatan]

I do understand you; while games aren't my medium of creation, I have suffered to through having to cut parts that simply couldn't be made to fit into the bigger picture of a work. It's a shit feeling because you know you put a lot of love and effort into it, but it's part of the toiling, wacha gonna do.
In your case might be mostly due to limitations outside of your current reach, but keep in mind that the workaround to limitations is what made out of many works of art and technology such wondrous pieces.
Better to leave the players hungering for more than complaining about fat that should have been skimmed or unfinished crap, we all know too well that feeling.

 

[zwanzig_zwoelf]

I know what you mean. I'm relaxed about it because I've made workarounds to the biggest boons:

• Bigger areas are impossible to pull off on my current hardware since the editor draws everything while in the game you only see a fraction of the dungeon, but it's fixed by breaking huge dungeons into smaller parts with the ability to travel between them and since loading times are nonexistent (a few seconds max for big and very packed areas, but usually near-instant), it's a good solution for me;
• Lines being either a pain in the ass to create or being uncontrolled or unpredictable mess (via textures, shaders, IPP or other means). This is fixed by writing a small module that uses the low-level GL functionality and making a tool to edit them easily;
• Maybe something else, but I can't be arsed to remember now.

Maybe one day I'll write down every tiny detail. Right now I know I've got something solid on my hands, but I need to make sure not to fuck it up.

BTW, I'm thinking about writing a huge pile of text about lines soon-ish since they're a rather interesting topic and there are a few people out there who had to deal with this issue before. There was a blog somewhere where the guy developed a Battlezone clone and dealt with the same issues I had, but apparently he decided to drop it, which is a shame, since we could share some knowledge on the matter because his experience with the lines saved me some time and effort since I didn't have to waste time on ways that were a complete failure since the beginning (drawing lines via textures).

In case you're interested, here's a short summary:

Spoiler

Lines can be drawn by rendering the UV map of the mesh and solidifying the lines in the image editor, but I disliked this idea since the start, because this method wastes texture memory and whenever you decide to make some changes to the mesh, you have to rebuild the texture again. And again. And again. Also, this way lines aren't 'clean' and you're risking to encounter issues due to mipmapping, pixellization and other stuff related to raster gfx, while we want to create vector gfx or at least fake them properly.

You can also draw lines via shader, but I'm not that good with shader programming and as it turns out you'll most likely encounter issues with thin lines in the distance due to floating point calcs (issues like flickering, which get irritating pretty fast).

You can also try edge detection to fake that effect, which allows you to create stuff faster (just dump the mesh into the editor and tweak it a bit), but it's performance-heavy (big no-no for me, since I want this thing to run on old rigs) and you have no control over tiny details so you have to exaggerate a lot in the process, and the lines aren't precise either unless you're willing to sacrifice performance by writing a more precise method to deal with this.

Low-level GL functionality gives you full control over the appearance of lines, but there are several drawbacks, such as the need to keep the lines at a small distance from the rest of the meshes to avoid z-fighting and there are no tools available to handle the lines, so you have to write your own tools to deal with this, not to mention the need to batch the lines into as few draw calls as possible to avoid performance issues and wasting the cpu cycles.

IIRC Excommunicator was interested in the subject too, so I'm paging him just in case.

 

[AdolfSatan]

It's always interesting to read others approach to these issues because of the multiplicity of possibilities in which to solve them.
How are you constructing the elements themselves? At this low level of polygons I think I'd work with coordinates rather than visual drawing, feels like it'd probably be faster and more streamline-able: Once you get the hang to the ratios needed to create or approach X shape you can start doing blind input and then doing minor tweaking, whereas visual modelling requires your attention full-time.

What program are you working with? Last time I dabbed into cyber sculpture was over ten years ago, but if I don't recall wrong, even back then 3DSMAX (obviously not what you'd use to create game levels, but I'll assume that the tools used for that matter can't be that far away in essence) had a function to add a value and colour to the contour and edges of an element, not unlike the function in PS layers.

Where that unavailable, I think I'd solve it by making a flat extrusion of X+2% —or whatever value depending on the desired thickness of the faux border— and filling the new plane with a solid colour like red, while retaining the "inner" mass of the object flat black. Problem is, this would at least double the amount of polygons, which is completely inverse to the idea of making this as lightweight as possible, and would probably add lots of graphical issues in the final render.

Having no textures per se (I would forego them absolutely in any case), but needing to make drawings on walls such as that wolf, I'd create an object with a value of 0 on the z axis and hang it up there to avoid the use of rasterized images which is bound to look fucked unless you make it ultra hd which completely ruins the idea of optimizing resources.

Ones last thought: is it possible to create a fake 3d space by having 2d lines graphed on based on coordinates that fake perspective in the same way the scumm engine did? Just throwing it to the air, I don't think this would actually be applicable in any way.

None of what I wrote is worth shit probably because I'm stuck in time and have no idea of the resources you're counting on, but it's a nice mental exercise anyways, so sorry for making you read a bunch of crap.

loading times are nonexistent (a few seconds max for big and very packed areas

Doubt anyone will mind this. Just make sure is not an area one jumps back and forth to repeatedly.

Been skipping a bit through your sc. Nice music, this will fit great with the game! I find the sound a bit heavy on the high end of the spectrum though, too many instruments/samples are crashing frequencies up there.