Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xenoargh]

OK, so I have a basic "game" built.  Integration of the maze generator with the lighting and pathfinding system wasn't too scary, but I ended up doing a lot of cleanup in the end.

There's a "main character" you can move around the world, etc.; no baddies to shoot yet, but soon.  The LOS and lighting system got fixed up and I'm fairly confident the whole thing's working like it's supposed to.

I'm having an issue that I didn't fully anticipate, though.  I've learned why Teleglitch used the widely-panned feature of turning the camera when entering new rooms.  

It has to do with navigating spaces that are at odd angular rotations, while using the traditional WASD control setup.  It turns out, once I got a character to move around in the spaces and collide with walls, etc., that this was awkward; moving down a hallway, for example, was pretty annoying.

So... I think I'm going to have to think about my major options:

1.  Tank controls; all movement is relative to the direction the character's facing.  That's how I have it set up right now, and it works pretty well, but I'm guessing newbies will find it a little hard to do.

2.  Mouse movement, where the character moves towards the mouse position when left-clicked and pathfinds on its own, like in games like Grim Dawn, Diablo, etc.  The problem with this is that, while it works, it's hardly a good solution for a twin-stick shooter.

3.  Accept Teleglitch's fix for these issues was correct, and implement it.  Given the amount of complaining it generated at the time, I'm not entirely sold, but, if you didn't get motion sickness from the rotations, it worked.

4.  Give up the fancy angular stuff, of course.  But man, it's cool-feeling.

[TaLaR]

As player I'd prefer either 3 or 4.
3 is more immersive, 4 is simple and functional.

1: Tank controls are clunky by definition, so you'll have to make rest the game slow and imprecise to match control scheme.
2: Whenever I see a diablo-like setup my first though is "If only I could properly WASD instead...". Second is "Hmm... I could probably find/make ahk script to convert controls to WASD". But of course such conversion is usually imperfect, and I end up simply passing on the game.

[David]

Gotta say, it's neat seeing you grapple with a game design problem you've run headlong into as a logical conclusion of the feature-set you built. You can imagine how game devs have this happen all the time, and it's not something you'd even really think about unless you've actually prototyped such a system and run into it yourself.

In conclusion, nice game dev process going on and it's fun to read this thread!

[xenoargh]

Yeah, it's interesting dealing with the stuff as it comes up.  The core's pretty satisfying, even in its really early state; it feels like I'm walking through a interconnected series of spaces, which is cool.

[xenoargh]

Welp.  I have zombies in the game.  OK, they're not very interesting zombies right now, but they can successfully navigate the game-world and seek a target.

Oh, wait, didn't I get that done already?  Like, 2 weeks ago?  Well... it turned out that, transitioning from "Simplistic Square World" to "Fully Rotated World" broke their puny, brainless AIs pretty badly.  Reasons for this included not dealing with the A* system in a way that would prevent blocked paths, poor design of the motion-planning systems, and generally, they were pretty brain-dead upon introduction.

Now, they're un-broken, mostly; the zombies can wander the entire map, trying to eat your poor Space Trooper's brains.  However, since said Trooper doesn't have a gun to fight back with, yet, that's hardly sporting, in a world of tight hallways.  So they're still Mostly Harmless right now.

I'm seriously considering whether to implement a node-based pathfinder rather than what I'm doing, which is A* using a grid that gets initialized after the world builds.  It'll be a pain, because the pathfinder nodes will have to calculate connections with one another after the world builds and that means that they'll almost certainly have to be built into the rooms as objects of some kind before being virtualized or I'll have to use some other strategy, but... huh, Teleglitch did that, too... and probably for the same reasons.

It's fairly defendable in terms of both speed and practical obstacle avoidance; one of the things that gave me a real headache was that the AI needs to navigate all those twisty, narrow corridors without borking, which turned out to be Fairly Hard and computationally expensive to boot.  A*'s idea of navigating a hallway is to cut the corners so tightly that the critters get caught on the corners; that was fixable but involved some Heavy Math.  I'm sure glad I was running at 500 FPS back at the beginning of time, because I'm already down to 200, and there still isn't all that much happening, which is not making me happy.  I also don't exactly have hordes of them running around, yet, and I kind of want hordes at times; I think the upper limit on these critters is somewhere south of 30 actively pathfinding before we start seeing noticeable framerate drops. 

I probably need to deal with this soon.

[xenoargh]

Well, that was... fun?

Basically, I ended up doing a combination approach, where the A* feeds into some special movement-guidance points, to help my zombies not get caught on corners too often, combined with an approach to reduce the number of pathfinder steps generated.  It works fairly well and it's fast, and I was able to get the A* considerably faster, too.  Still running well over 100 FPS with lots of critters active; I might actually get hordes after all.

Not much fun, though; endless test-cycles to see if the zombies were finally tracking reasonably well.  So I've got a fairly good base to build more critter AI now; that was the biggest hassle, I think.

I've also partially animated my Space Trooper and I built a simple state-machine to control the animation states.

For example, the character can aim and fire a gun now, and kill things:

This is almost certainly premature on my part; I don't yet have the inventory system built yet, etc., etc., and there's absolutely no good reason to do this yet... except it's fun, and it was a long day.

Once the base animation's done and that system works, I think I'll try and tackle the issue of camera rotation. 

One of the things that came up during this series of changes was that I tackled one of the things I actually didn't like about Teleglitch; the "aiming" system.  Aiming in that game was cool, in the sense that you got to see a little further, while moving more slowly; it made when to shoot a serious choice.  I liked that part.  However, I didn't like how the mouse-aiming part worked so well.  So what I've done, instead, is that there's a zoom-out when aiming, centered on the character; you get a little benefit to your view distance while aiming, but it's not doing complicated mouse-lerping every frame that created occasional issues with the LOS system in general.  This works very nicely and it gives the sense that you're in a special mode, too.

[xenoargh]

I apologize in advance; this turned into a bigger Wall of Text than usual, lol 

I've gotten all the basics of the game ready; it's still very crude but it works, by gum.  Shooting, moving around, killing things, keeping a basic score, getting hit, dead, etc., etc.

The last few days consisted mainly of grim work on the motion-controller system for the critters, polishing, documenting, making the system abstracted rather than built into the basic critter, etc., etc.  I think that I really did get there, eventually; there are very few obvious issues with them now.

Interestingly, at least to me, was the learning-curve on figuring out the best combination of steering systems; this was a bit like the work I did on my Starsector AI replacer, but with a lot more emphasis on practical obstacle avoidance; one of things I never really developed for that system was a raycaster system for that, but, rather, an angle-tester (i.e., if this close to <thing> and angle <this> then Do Stuff)

This motion controller needed a ray-caster approach, which is slower (get things that might intersect the ray, then test each) but it was ultimately really necessary to get things working well-enough; at first, my zombies had the unerring ability to crash headlong into walls, among other lovely headaches.

I've seen a lot of approaches tried by various folks over the years and have read a fair number of articles on this.  I think it's interesting to share my solution here, at least the abstract:

Essentially, every frame, we shoot one of six rays.  They aren't all spaced evenly and they aren't randomized (that's an approach I've seen used, and while it has merits, it also has problems; if the randomizer misses too much, your only solution is more randomized rays, per-frame, which is exactly what I don't want, because rays are expensive to cast).  Essentially, there are three in front, two at the sides, and one in the rear.  There's only one raycast per game-frame, which appears to be sufficient.

Each ray influences critter behavior slightly differently; if, for example, a critter hits a wall with a side-ray, it turns and slows itself simultaneously.

But now I have to deal with the obvious problem of Content; everything's at the Programmer Art stage, and I have to make choices that I'll live with later.  I know it's been pretty boring looking at my test artwork as I proceed, but this is how things go at the beginning and luckily, I can wear the Artist Hat if I need to (and I probably do, along with the Sound Designer hat, Animator Hat, etc., etc.).

I'm experimenting with an interesting idea; now that zoom works, the question of putting scalar graphics into the game comes into play.  Teleglitch was panned by some of its critics because of its relatively-low resolution art; it was deliberately old-school in that way.  One of the two brothers who were the initial developers said that he was trying to deliberately push the low-res envelope, and while it was interesting, it wasn't everybody's cup of tea (not that there is any such perfect cup, when it comes to art).  So, I can avoid this, by using a trick somewhat similar to Starsector.

The only catches?

1.  Whatever scalar I wish to use, I have to set now; once I start seriously developing sprites for the game, I can't change that willy-nilly.  I think 2:1 is reasonable; if I'm uncomfortable with the zoom later, I can always dial it back and interpolation will cover most of my sins.

2.  Obviously, there's a cost in texture memory, but frankly, I'm not expecting to experience major problems with a 2D game that's using sprite sheets, etc., unless I go really hog-wild.  Memory use in general for the game is nothing right now, by modern standards.  My biggest issues with graphical performance are that scaling the screen up beyond its current size (it's 1000 / 1000) won't work out, in terms of the performance of the LOS / shadow-caster; I can put UI elements to the sides, buff out the 80 pixels top and bottom for 1080 if I wish, but nothing beyond that.  That's the biggest practical detail, in terms of performance, now that the critter system's largely optimized; I just got done running down over 50 critters without lag and everything stayed above 100 FPS the whole time, so I'm fairly confident I'm all right.

But, with my zoom system, an interesting idea came up.  

I can combine higher-resolution images that look their best at min zoom, rather than max-zoom, and the zoom-out can feel bigger; you'll go from "intimate" to "sniper zooming out". And if players prefer a more-intimate view, I can give them a slider to cap max zoom, leaving min-zoom at 1:1.  Going over max zoom won't be possible (it breaks everything, lol) but it won't be necessary, either, I suspect; I can simply limit the ranges of weapons, etc., so that it feels like a really long range.

This sounds reasonable and cool.

All that said, I don't think I'm going to go hog-wild with the graphics side of things.  

I did some messing around with normal-maps, just playing, and I think it'll add too much production time if I'm the only developer; not just building the system (lights would have to create vector data, among other "fun") but mainly, it'll mean developing artwork means developing normalmaps, too.

That takes lots of time to do well, with 2D stuff where they're going to be presented next to other things in a scene and compared in terms of relative heights, etc. I tested out a lot of ideas on this back when GraphicsLib was still pretty new, and frankly, I think it would require a 3D workflow for art to do it reasonably fast, and by reasonably fast, I mean building out characters in 3D, rigging, animating, etc.; anything less, and the randomness of the normals and depth maps (because a really good look probably requires a parallax shader) would be too unreasonable.  I may come back to this later; I like the idea of normal-lighting to give things a 3D-ish feel, especially if I can figure out a way to "bake" it into static objects under static lights or something to make performance really reasonable.

I think I will be using some of my shader-fu on some other ideas, though; among other things, I've been considering water that characters can "splash" through as a possible idea, superimposing normalmaps to edit the final result, fake reflections of nearby stuff and so forth.  

But frankly, those bells and whistles can wait until the actual game is largely done; I know I can do the big things now:

1.  Dynamic and static lighting for the scenes with soft shadows.  I haven't shown it off much, but it works well.  The system I started with required, erm, a fair amount of modification to work properly for this project, and I think I need to do some additional optimization, but I think it's basically there.

2.  The main character's state machine is largely complete, other than building in the equipment system (the bones are there, but not the details).  One game-design choice I made early was that I wasn't going to have a Teleglitch-style inventory; instead, players will have 6 "equipment slots"; this is all they can carry around with them.  Each slot can have anything in it, and what each slot does when used will be determined by what's in it.  That part is still largely not built yet, but I intend to get it done soon.  Examples of things that might go into "equipment slots" are:

A.  Weapons, duh.  A game like this lives on interesting ways to blow things away, cut them into bits, etc., etc.
B.  Instead of having a "healing potion" item, have a "healing potion" piece of equipment that eats "potion ammo" and has a cooldown timer so that it can't be spammed.  That (might) end up Diablo-style abstracted, though; it's pretty essential in games like this to have potions.
C.  Sensors that let players ping monsters through the walls and see them briefly.
D.  Shield devices and other sci-fi gadgets like that (the setting's definitely sci-fi).
E.  Other stuff I can't even be bothered to write down, like devices that help players unlock chests they find, etc.; passives and actives; anything that isn't a new suit (more about suits when that's a thing, but basically, you have a suit that's your armor, it comes with passive buffs / debuffs, and you get a helmet slot, too).

Basically, though... the plan is for:

A.  Ammo is abstractly carried around and won't have weight.
B.  Resources you find are abstractly carried around and might have weight (kind of like Fallout 3/4's system here).  But, in general, I think I'm against weight; if I want to limit players' ability to use ABC items to make XYZ resource (like converting Metal and Chemicals into Pistol Ammo, for example), then the best way to limit this is to restrict it to the pre-run phase (more on the plan for the game's structure later, when the core's built and I can start worrying about structural elements of the meta).
C.  Weapons and other Equipment aren't abstract, might have weight (carrying around a Minigun might be awesome in firefights, but might be a problem when it's empty and you're trying to flee).
D.  If you built a thing during the pre-game, if it's an abstract (like ammo) you have it with you; if it's Equipment, you don't, unless you equip it before the run.
E.  Suits and helmets are set during pre-game and can't get changed during a run.  If you find new stuff, great, it might help on the next run.

So gameplay means making choices and living with them through a run, essentially unless you find a better <something> and give up an Equipment slot to pick it up, essentially.  

I'm probably going to allow soft-storage (i.e., picking something up won't delete that other something, it just shoves it into abstract storage and you can't use it the rest of this run) but probably I'll have to implement hard-storage because somebody will whine that they picked up a Rusty Shotgun to check it out and can't get their Street-Sweeper 9000 back.  Dunno yet.  

Maybe the Right Answer is to give people a choice- pick it up and drop their <something> on the ground, as an interactive they can swap back, or put their current item into abstract storage immediately.  Or just presume that to add something to your gear menu later on, you need to keep it until the end of a run; after that, it stays in your abstract storage.  I guess all of this depends on how many items I allow for; if the abstract-storage UI is 32-pixel buttons, then basically the sky's the limit; I can have 1024 items available to choose from and my problem is coming up with 1024 things that are vaguely original and relevant (yeah, right).  64-pixel buttons (256 choices) sounds a lot more realistic; it'll be hard to come up with that many truly-unique-feeling things anyhow.

So, basically, it's time to work on the UI in general, I think, starting with a basic Loading Screen, a Level Loading screen (to hide the Procedural Stuff, not that it takes long right now) and probably it's time to think about the Equipment screen and then the core gameplay UI.

There's also the question of Content.  I don't think I want to talk much about that, yet.  Let's say only that I face a fairly major challenge there, if I'm going to raise the resolution on the sprites by 2X.

[PyroFuzz]

Basing what i just saw from images, it looks like it would make a cool science fiction Dwarf fortress thats not rimworld. Or maybe like dungeon of the endless.

[xenoargh]

I doubt if the core would work for something like Dwarf Fortress; it has some practical upper limits on world size, before things get too big and the game slows down, and it's not a fully-destructible environment; I have thought about how this can be used for multiple genres, but right now I'm concentrating on the sci-fi version and story I want to tell

I think that a comparison to Dungeon of the Endless is closer to the mark, although I doubt I'll have RTS-style control over friendly characters; if you have allies along with your main character, they'll be more independent and follow you, like Mercenaries in Diablo did.  It's going to be a while before I make any decisions about all that stuff.  First I have to get the core UIs built, so that the player knows what's going on at a deeper level and can do things like swap equipment, interact with people / objects, etc.

[xenoargh]

Progress.  Still don't have a UI or a million other little details done, but the zombies can seek a player, the lighting system's largely working as designed, including sources from pixel-art Stuff (see the little glow on the Space Trooper's helmet) etc., etc.  Yes, the rooms are still boring to look at, but that's just art, not mechanical problems; I'll take that.  I think it's really time to get the base UI done now, so that we can have a basic game of, "don't get eaten by Zombies".

[xenoargh]

Got the basic UI done last night.  That went remarkably easily.  It's basic, it's ugly, but hey, it works, which is way more than I expected on my first day of trying to tackle that.  There's a "loading screen", too, to cover the period where all of the world-generation happens, finally.

So it looks like now I need to actually build out my first real game loop- have a screen where players can see the controls, have the objective explained, and start a new game when they've died.  Then flesh out some of the sub-systems so that it's reasonably complete as a game.

At this point, with the vast majority of the core logic built (believe it or not, things like getting resources from pickups, etc., is so minor I haven't even bothered coding in "chests" yet) FPS is still over 200 on this rig (with load, i.e., 30-50 zombies trying to find you), but it's less than 300 at this point, which is a little worrisome.  At the worst, it bogged to about 100 FPS, with noticeable stuttering, but I finally tracked that down and killed it (the zombies were tending to call the pathfinder more than was ideal).  I think it'll hold up when sounds and effects are thrown in, but we'll see.  Can't wait to start building out effects and art and all that fun stuff, but I need to keep plugging away at essentials.

But I think the main CPU load's basically built out; other than sounds, I don't have a lot of fancy-math stuff to construct now, other than a few specifics for behavioral stuff, which should all be reasonably performant.

We'll see when I get the next details done; the next step is probably to formally build out the game loop for the first time, in a crude fashion, so that we'll have something basically playable, with a win / lose condition, etc.; with the big exception of some important UIs, this gets me pretty close to having the bare bones built.

[Sproginator]

May I recommend making the UI more around the character? Like a kind of floating system. Games such as these look so much more eerie with the UI as part of the character

For instance, Have the currently equipped weapons name showing next to the character as floating text. Indicate HP via a blood splatter filter over the screen. Stuff like that

Apart from that, Love it so far!

[xenoargh]

I might look at things like that as I get further along.  I get what you're saying there, but I think the balance is between keeping everything visually clean (this is a game where seeing all around you is super-important) and making the feel good.

One option might be to have a small UI that follows the character and shows minimal information (health / energy left, ammo left, if appropriate) and have the bigger things (like which piece of Equipment you're using) out on on the corner edges.  I think players need that information, and it's not taking up a lot of space atm.

I've just finished up the main game loops; the player can start the game, get killed, restart the game, pause the game, unpause.  Still working on structural stuff like this to make the whole thing playable and then it's finally time to worry about introducing some mechanics to make it (hopefully) Fun and starting to add a little more content.

[Sproginator]

I might look at things like that as I get further along.  I get what you're saying there, but I think the balance is between keeping everything visually clean (this is a game where seeing all around you is super-important) and making the feel good.

One option might be to have a small UI that follows the character and shows minimal information (health / energy left, ammo left, if appropriate) and have the bigger things (like which piece of Equipment you're using) out on on the corner edges.  I think players need that information, and it's not taking up a lot of space atm.

I've just finished up the main game loops; the player can start the game, get killed, restart the game, pause the game, unpause.  Still working on structural stuff like this to make the whole thing playable and then it's finally time to worry about introducing some mechanics to make it (hopefully) Fun and starting to add a little more content.

Sounds great man! Can't wait to keep following the development

[xenoargh]

Well, I should have some new news soon   I got slowed down quite a lot the last month, due to various RL things (holidays and other stuff) but I'm relatively free this week to get more work done