|
Drr... Drr... Drr...
|
#
?
Mar 24, 2018 04:53
|
|
|
|
| # ? Apr 16, 2024 06:34 |
|
|
.Zbr... zbr... zbr...
|
|
#
?
Mar 24, 2018 13:15
|
|
|
I prefer a more photorealistic yet artisanal approach https://twitter.com/FFXVEN/status/655096152954572803 (I assume they did it photogrammetrically(?) but it wouldn't surprise me to find out it's hand-modeled)
|
|
#
?
Mar 24, 2018 16:37
|
|
|
hey girl you up posted:I prefer a more photorealistic yet artisanal approach Looking at that topology, I'm 100% sure that it was photogrammetry.
|
|
#
?
Mar 24, 2018 17:26
|
|
|
We had a guy model rocks for over 3 months at work. Just every day, rocks. Rocks weren't even a big thing in our game (effectively, a RTS game), just decorations players could place. I felt really bad for that guy. Also, I'm a graphics programmer and while I've also dabbled in some 3d modeling and am ok at it, I share your hatred for the actual process, having to fiddle with so many things just to get a single asset ready (much less, polished enough) is a massive pain. Not to mention that if your model's sufficiently complex, UV mapping it will take ages (until you just give up and use automated methods).
|
|
#
?
Mar 24, 2018 19:13
|
|
|
Falcorum posted:We had a guy model rocks for over 3 months at work. Just every day, rocks. That's a lot of rocks. And yeah, when pondering about what I should write, I had no choice other than rocks. Because they're so innocent, so inconspicuous, so simple and so paralyzing at the same time. They'll never be valued by any player, they're boring to make and they're almost always numerous, and they're a necessity in almost every genre.
|
|
#
?
Mar 25, 2018 21:38
|
|
|
Chapter 26 - Tilesets, Part I For the past month I've been researching into tilesets. If you don't know, tilesets are sets of textures, objects or data structures which you use to design a terrain, background or game environment. Think every 16-bit RPG and older. Those oldschool Final Fantasy which have you walking on a grid-based board are all using tilesets. Some of my Shmup references use tilesets for the background and seeing how I want to make a procedural game, dealing with tilesets seems logical. When you're walking around a dungeon in a roguelike, it's very likely that you're walking on a dungeon composed by tiles from a tileset. In a way, it was a bit naive of me to think that things would go fast. A lot of procedural games are really dependent on tilesets, and even voxel-based ones behave like a tileset-based game, which makes sense. When I realized I needed a robust system I started looking for existing solutions. It sucks to say that I wasted a lot of time. Well, not wasted - I learned a lot about what not to do. And the fact that the solutions I found were not optimal forced me to learn a lot more about tilesets that I didn't, and in hindsight I think that was the best way things could go. All things considered one month is more than I wanted to spend (and I'm still not done) but when I see how much there's to tilesets and how important they should be in my game, it's not a lot of time given all that I studied and learned. Now, something I've noticed is that there are many different ways of handling tilesets. A 2d platformer has nothing to do with Sim City which might have nothing to do with RPG Maker which may have nothing to do with a 3D Action RPG. Even between 2D Platformers, just from watching Sonic's presentation on GDC I got the feeling that the way they handle physics forced them to also handle their tilesets in a way that's very different from other 2d platformers. Because of that, there are so many solutions. And I don't mean in assets, I mean conceptually. Tilesets is a vast subject with many branches. In this update, I want to talk about one of those branches that caught my attention. I'm going to use Starcraft as an example because of how rich Starcraft is in every way when it comes down to tiles. The tiles beautiful, varied, and the game has a bunch of peculiarities which serve as a good example of how there seems to be no such thing as a vanilla way of dealing with tilesets. Corner-Based Detection This method is used when you need transitive tiles. The specifics of the implementation vary from game to game, but it's a real easy method to implement when you're dealing with transitions (like grass-to-earth tiles, or highground-to-lowground) because it minimizes the amount of tiles that you need to do. There are downsides to it. But let's take a look at what happens in a typical case:   Whenever you paint something, a bunch of transitive tiles are automatically filled around. This means that you have to paint tiles for all the transitions. Now how many tiles you need to paint depends on whether the tiles can be rotated around or not. Assuming tiles can be rotated (which they often can't but let's pretend they can) then you have to draw a minimum of 5 tiles, which is pretty good. Why 5? Well, let's understand how corner-based tiles work first. I open up the Starcraft Map Editor.  If I paint grass then what we get is a single patch of grass, surrounded by grass. Do note how a lot of grass is leaking to other tiles.  I think it's easy to predict what happens if we next the tile next side as grass:  Alright, that's great. Now, what would happen if we skipped the neighbour tile, and instead painted the next one?  The tile in-between gets filed. But how and why? Shouldn't you be able to code in an intermediary tile between two filed tiles? What sort of witchcraft is going on? In fact, now that we have 3 Grass patches in a row, what would happen if we removed the middle tile? At this point there are 15 tiles being affected by the 3 patches of grass, of which we only drew 2. So let's remove the patch in the middle and see what happens.  We now get two thin patches of grass that are, otherwise, unpaintable. These patches are covering a total of 2x3 tiles each. In fact, you can get a thin patch like that linking two unrelated tiles by painting them in an L shape.  If you're a bit savvy you probably realized at this point that these thin patches are transitive tiles being used back-to-back. So what exactly is going on? Let's go back to the diagram. Let's say we filled two non-neighbour patches in the same row.  When looking for a texture to fill the tile-in-between, one would imagine that the system would look for a tile with the following properties:  And, indeed, you could code a system that received a tile like that. In which case you'd have to write a lot of tiles for many different scenarios. Starcraft, however, only considers the corners of the tiles - when you paint a tile you're not painting a single tile (or even the tile itself), but the corners of the tiles in a vertex grid. Picture them like this:  So you paint one of the tiles as grass:  And now you paint the non-neighbour tile as a grass:  And, as you can see - the tile between them is not indistinguishable from if you had painted directly on it. This means that there can be no special case for hole tiles! To help you visualize them:  So what was going on in Starcraft?  The grid doesn't need to know if the tile is filled or not. Indeed, the minimum count of tiles needed (assuming they get rotated) is 5 because these would be the situations for any given transition:  Every other tile is a rotation or symmetry of one of these. Every 1-point tile refers to a diagonal, and so on. In a top-down situation you might want to paint the full array of possible directions (15 total - 4 diagonals + 4 walls + 2 opposite + 4 convex + 1 full if I'm not missing anything). Sometimes you can get away with mirroring some. Starcraft for example will mirror the two bottom sides and the two top sides). The "null" tile would usually fall back to the "full" tile of the previous tile. Sometimes there's none the transition sprites have transparency and are layered over a flat background.  Incidently, I do want to point out that in my opinion, to this day, these are some of the most beautiful tiles 256 colors can draw. Back to how weird that grass tile looked in the beginning, when you paint the middle tile with the background color, you get the following scheme:  This now means that the transition tiles are back-to-back, and you get thin borders. With some creativity you can go crazy with it.  Issues Corner-based tiling has a lot of issues, though, most of which you can't really get around easily. The first big issue is that tiles are... widish. They need a lot of space for themselves. Because you can (usually) only have transition tiles between one tile to another, that means that every single tile always limits the existence of 25 (!) tiles. If the layer of the tile you just placed is x, because you need the furthermost corners of the adjacent tiles to belong to x-1, that means the tiles adjacent to those tiles can also only belong to the class of tiles that connect to x-1. So for example, if the space platform in Starcraft is x and the space is x-1, this is what happens when we place a tile that is x+1 in the middle of space:  Here's a particularly weird example:  This tile connects only to space platform - However, Starcraft forces a full tile around it because it's on a different level, it ends up affecting 49 tiles. Or rather, 45 since it skips the corners. Super weird. It's important to mention that none of these tile configurations, no matter how spacious they seem, allow you to build a single building. Design Decisions, or Getting Around the Issues I've studied a lot of tile systems this March and like I mentioned before, it seems like they're almost all unique in one way or another. I chose Starcraft as an example for this exact reason. There are many oddities in it. Buildings are placed in a square non-isometric grid. Which makes situations like, this, even though this turret fits perfectly, impossible:  Each quadrangular unit requires at least four tiles since the tiles are isometric, so a free, available tile surrounded by transitional tiles offers no real state for building, as you can see. This tessellated property of the isometric tiles as four effective triangles is present in present in some other ways. For example, the rocks from the cliff in this tile are outside the jurisdiction of the highground tileset:  Nevertheless, they're still there. This helps break the monotony of a tile-based system and helps create a more natural environment. There are many design decisions that seem to shift from game to game. How large is the transition? Again, another reason I picked up Starcraft is because of how it deals with this. Looking at the cliff, this is kinda how it looks:  Which can lead to some interesting tile placement:  Usually non-isometric games will pick a width and stick with it. So that cliff could look like any of these:  Note how these can wildly change the game design. For example, can you walk on the transition tiles, or not? It seems intuitive that you can't on C because if your character, say, in an RPG occupies an entire tile, then you'd be sitting with one leg on the low ground and one leg on the high-ground. With A, it seems like you could stand on it, if you came from left. While on E, that would only be the case if you came from the right. So do you go with A or E? A seems a good choice because E forces you to have every high ground to be large, but I've seen plenty of games who go with E. Something that seems so trivial can end up being a huge hassle! For The Sky Is Dead, I went with a corner-based system, with a few tweaks. Like Starcraft (and a bunch of other games) I subdivided the tiles, but since I'm doing 3D and non-isometric I subdivided them into a smaller 4x4 grid. I then use that 4x4 grid to place doodads and objects. I'll go in-depth about my solutions in a later update. For now I just wanted to talk a bit about tilesets since it seemed like a trivial thing at first and then I realized it's not. Being my first time playing with tilesets, I underestimated how much goes into them. Entire games revolve around this kind of stuff. And like I said earlier in this post, a lot of procedural games are really dependent on tilesets. Shmups are also usually dependent on tilesets, so it makes sense now in hindsight that I should give it a more careful approach. Hope you enjoyed the update! NEXT TIME: More tilesets! I have a bunch to talk about them! Elentor fucked around with this message at 06:44 on Apr 4, 2018 |
|
#
?
Apr 3, 2018 11:09
|
|
|
As always, very interesting stuff!
|
|
#
?
Apr 3, 2018 14:12
|
|
|
When you first mentioned Tilesets I thought this might have been coming. Starcraft is a pretty good case study on tilesets.
|
|
#
?
Apr 4, 2018 03:53
|
|
|
Oh yeah if theres one thing Blizzard does well, its hiring some of the most talented artists in the world. The Starcraft 2 amd Heroes of the Storm tilesets are insanely good.
|
|
#
?
Apr 4, 2018 06:12
|
|
|
Thanks guys. Yeah, Starcraft is pretty impressive and probably my favorite case study so far. The graphics themselves are ridiculous. Take a look at the limited palette of this gradient and how well it mixes these colors to create an insanely good looking asset:  Here's something extra. This is a really interesting read on the transition from WC to SC: https://www.codeofhonor.com/blog/the-starcraft-path-finding-hack
|
|
#
?
Apr 5, 2018 05:24
|
|
|
Chapter 27 - An Unexpected Milestone So uh. I halted tilesets for a bit because it was taking too much time. I'll get back to it (I need to) but I needed to move on for the moment to keep progress going, otherwise I'll not have any meaningful update for weeks. While resting from developing assets, I got procedural ship spawning working. It's a very long algorithm. I've been working on it for a while on Excel and Notepad but I wasn't sure how long it would take to implement in the game. I'm quite happy with how it turned out thus far because it was not easy. Although it's long and complex, it doesn't yield elaborate results, but it yields playable results and it's scalable. The core gameplay loop is in. So technically the game has everything except for item drops in-stage right now. It has a procedural universe, it has shops that change dynamically every stage, it has procedural stages with procedural ships. It has an interface. It doesn't have any obvious bug that I can see. The core functionalities left would be having a main menu and a save/load functionality. A main menu is trivial, and I've coded save/loads before, but I'd like to mature the data structure a bit more before delving into those. Other than that, I'd say the other functionality are the aforementioned item drops. Besides these, I'd say the "base game" is done. These might not be the most exciting screens I posted yet as they don't show any new content or asset, but thus far everything had at least something manually placed.   These are all there by themselves, and everything loops, and it's beautiful I'm so happy. The ships may not be distributed in an exciting way because I haven't gotten into varying their AI (which includes shooting back) yet, but the way they spawn across the stage has some logic behind them which I'd like to talk about. But first: A lot of ships For the amount of math and code typed in, I was surprised to see the code worked on the first try. I feel like over this project I really matured as a programmer, I remember that for many years I'd always run into a compile error or other, but things have been so smooth lately it's very scary. There was, however, a huge oversight. The first time I ran the stage the whole thing spawned 5000 ships with equipped weapons. That slowed down my PC severely (but didn't crash or give any memory error. It actually ran twice in the Unity Editor, so even if there is any memory leak right now, it's not huge!) so I think it's safe to say it's a hard cap to what we can do. A few stats After I fixed the ship amount, I ran into another issue which was the stage length. The test stage which is supposed to be 1-3 minutes long ran for 6 minutes and had 1000 ships, which is still way more than it should. I ran the 1000 ships test twice in the same session as the previous test, and my current version of the Unity Editor has a memory leak (it's an editor issue, the compiled game doesn't) so it successfully spawned 12 thousand enemy ships and probably around 100 thousand projectiles without crashing. Also, the stage with 1k ships did not run at peak performance but still ran at 90 or so FPS and is mostly bottlenecked by CPU. My CPU isn't bad but it isn't great either, so I think performance-wise things should be good. Loading time was 5 seconds for the game (Not on an SSD), and 2.5 seconds for the 1000 ships stage. During those 5 seconds the game is generating the universe, your ship, loading your database and procedurally creating the mesh and collision mesh of dozens of enemy ships to keep it cached in memory so that you don't have a lot of loading time. During those 2.5 seconds the game had to read the stage data-set and instantiate those 1000 ships and other stage elements. It could be faster, but it's way better than expected. Once I get that tuning part done the amount of ships will go down to an average of 100 per minute which is what my data on other shmups shows to be the sweet spot. So the amount of ships should range between 150 and 350. What's in the Ship Spawner There are many variables involved, but I want to talk about two ideas I had. The first is an attribute for each ship seed. It's called Spawn Gradient. It exists as a way to mimic the rhythmic variance that shmups have. In other words, if a stage has ships A,B,C and D, they'll not be equally distributed throughout the stage. To spice things up, there is a lot of variables involved other than the Spawn Gradient, but the gradient is a unique signature of each ship that defines how frequent that ship will appear throughout the stage. So a ship may have a curve that makes her appear early on and at the end, but not in the middle of a stage. Or it never appears except when the stage is 70% complete. Or it appears more frequently if you just entered a cave. Or if you entered an asteroid field mid stage. And so on. The second is a quadrant attribute called Ship Uniqueness. This is a pair of values that are used to define the frequency with which stage-unique ships will spawn. Right now there are three sets of ships which you can encounter in a stage: The Star-based Ships - Every quadrant in a star has a chance to run into this ship pool. The Quadrant-based Ships - Every stage in a quadrant has a high chance to run into this ship pool. The Stage-specific Ships - Every stage can spawn unique ships that will not be repeated. Through ship uniqueness, a quadrant can spawn different ratios of pre-existing or stage-specific ships. A quadrant may spawn a huge amount of both, a mixed amount of both, almost entirely (or entirely) pooled ships or entirely random ships. Since ships can drop themselves and ships also carry with them unique loot signatures, I'm hoping this will create places that players will find interesting to stop and farm, while also giving incentive to explore the universe. Even without the item drop system, from my first tests I really liked how it felt, as you start recognizing ships that spawn in a star system and suddenly the 100% random procedural game begins to feel concrete. It's really exciting. What's next? I'm taking a bit of a rest now. I wanted to get all the basics ready for April and although I got a month late because of tiles I'm overly excited that I had such a breakthrough, but I'm also tired as hell. Afterwards I want to implement the Alpha Universe Gen. in the game. Right now it looks like this Eldritch horror, with a bunch of similar tabs:  And again, it's a lot of math, but I'm confident that I can get it in in a reasonable time once I work on it. Once I put it in the universe will no longer spawn broken neon exoticity 500 ships, but it will be relatively balanced. Then I want to polish the space stage in every possible way. NEXT TIME: Either more stuff about tiles or I'll have finished the Universe Gen. Maybe even a video! Elentor fucked around with this message at 13:49 on Apr 18, 2018 |
|
#
?
Apr 9, 2018 13:57
|
|
|
That Spawn Gradient / Ship Uniqueness system sounds awesome!
|
|
#
?
Apr 9, 2018 14:37
|
|
|
I've been coding more of the procgen stuff related to stages. Most of it has been going quite smooth, other than a bug that took me 4 hours to solve and it was a single character of code.  I am, however, stuck in a really weird bug that concerns the passage of time. For some really weird reason the game is passing time at a significantly slower pace than real time. Since the physics are calculated per time passed and not per frame, this is really confusing to me.
|
|
#
?
Apr 18, 2018 13:48
|
|
|
And I solved the issue within seconds of posting in the thread. You guys are the best rubber duck a programmer could ask.
|
|
#
?
Apr 18, 2018 13:52
|
|
|
yay i helped
|
|
#
?
Apr 18, 2018 16:41
|
|
|
Captain Foo posted:yay i helped Thank you! 
|
|
#
?
Apr 18, 2018 17:54
|
|
|
So this means we're all getting in the credits and getting a cut of the profits, right? 
|
|
#
?
Apr 18, 2018 20:51
|
|
|
I'm happy to donate my share of profits back to Elentor so he can finish the game.
|
|
#
?
Apr 18, 2018 23:21
|
|
|
So I have something to ask you guys. I know this would be made a lot easier if I had a public alpha but I still don't think it's ready to put out there. If I'm being as open as a dev can ever be, I've been coding at a good pace to cover the fact that I haven't been modeling assets at a good pace. I'll get to it but until then things are kinda lacking the minimum polish I want to put things out there. However, something from my own testing that I worry about is the accruing of power over game time. And this has kinda been bothering me. 1) Right now your only progress comes through your items. This works fine in a game without roguelike or RPG elements, however the player may feel put at a disadvantage if he's not accruing any advantage other than credits in a stage. 2) Items sell for less than they're bought. I'm considering removing this or greatly retuning it to make it less punishing than RPGs usually are. I don't want players to feel uncomfortable making an upgrade because they might run into something better later on, but I also don't want currency management to be a complete non-issue. 3) Roguelikes tend to have character upgrades. RPGs tend to have character upgrades. Even Tyrian which is neither has some rare permanent, ship-independent upgrades. Now not to say that there are none, you find the occasional tool of the settler which grants you something. One of the tools of the settlers allows you to set a home to warp to for example. These are seldom combat-related buffs and are more like utility-focused. I don't hate level systems but I don't think they would fit. This whole thing isn't a huge issue, but something that I'd like to think about sooner rather than later.
|
|
#
?
Apr 20, 2018 11:24
|
|
|
Ad point 2, could you give items an extra property, "wear-level", ranging from 100 to 0. Items bought from a shop generally have wear-level 100 (full value), while most random drops have wear-level 0 (functional but not good resale value), and have item wear-level drop over time as you use them. At wear-level 100 an item sells back to a shop at its full price, but after having used it for a bit you decide it isn't worth its while, but wear-level has dropped to 90. That lets you sell it back for 95% of the purchase price, giving almost no punishment for trying out alternative options.
|
|
#
?
Apr 20, 2018 12:36
|
|
|
The only thing leveling up or whatever is going to do is act like a shop item you can't return. Have you played Cogmind? If not, spend some time with it or at least watch some videos. There are no skills - items just get better and as you progress, you get more slots to put them in (analogous to getting a new ship). To steal something from that, maybe once in a while (semi-regularly spaced), you come across a type of shop that can upgrade your existing ship in a few different ways. Maybe it's free but you can only pick one?
|
|
#
?
Apr 20, 2018 12:56
|
|
|
Regarding putting it out, I’d suggest making a closed alpha. It gives you peace of mind not having to worry about making the first release *perfect*. That’s entirely up to you, of course. Don’t release to Steam or whatever (as Jim Sterling says, you on;y get one first release so make that a good one). For progress, it depends on the game. It’s probably good to give some rare items (say playtime determined random drops) that allows you to explore things further away from the starting scenario or providing new drops once the player has learned the base set. BoA did it pretty well (rarer drops at harder levels, drops allowed permanently unlocking items that were harder to master but ‘necessary” for further progress).
|
|
#
?
Apr 20, 2018 13:16
|
|
|
Tyrian and its imitators usually make items resell for the same price you bought them for. Thus you never "lose" money, and your money effectively becomes your power cap / experience level. Between missions you can sell old gear and buy new gear, change your ship around, etc. and figure out what the best loadout is for the amount of money you currently have, without having to worry about wasting anything. That's the route I'd go with. If you want to be really kind, you can also let players replay old missions so they can grind for money if they want to, but the game should be balanced on the assumption that they don't do this. Like, assume that the player will get 75% of the money in each level, and balance the level difficulty around the kinds of loadouts they can get with that much money. Obviously this is tricky when so much of the game is procedurally-generated; you might need to vary that 75% heuristic based on how much of an outlier a given level is, or put in other bodges to try to keep your estimations on track. But the basic concept should be sound. If you want to have rare drops, you can make them sell for trivial cash, and give the player an inventory they can store items in, in addition to the slots they can equip items to. That way you can still have the "magic" of "oh cool, I found this weird rare item!" without forcing the player to have to decide whether to use or sell it.
|
|
#
?
Apr 20, 2018 15:17
|
|
|
I just replayed Breath of the Wild, so it's on my mind. The game has a very carefully designed division between permanent character upgrades, which are mostly health, defense, and utility, and the weapons, which are mostly all temporary. Using up weapons to find more weapons drives a big part of the core gameplay loop. That game's solution doesn't match this game at all, but I think it exhibits some interesting strategies. What if weapons can't be sold for money at all, but can be traded in for whatever stock a store currently has? Add a reasonably sharp inventory cap, which triggers at the end of level so you don't interrupt the actual game. You need to regularly throw away weapons that you won't use, and there's little reason not to trade them away if you see something you like even a little. Inventory expansion (as in BotW) becomes a valuable permanent character upgrade. Money drives other kinds of upgrades, where the tradeoffs are more obvious and major player regret is less likely. I'm very eager to play this game, but I'm most enthusiastic about the upgrade systems and story mode, so I won't beg for an open alpha right this minute.
|
|
#
?
Apr 20, 2018 17:25
|
|
|
Speaking of completely different strategies for player progression, one of my favorite progression strategies is simply getting better at the game. I LOVE going back to old things and completely wiping the floor with them, not because I have a better weapon, but because I'm just so much better at the game now. The first Mirrors Edge was great at this. It was easy to play but the skill ceiling was super high and so if I went and did time trials and got more skill, I could come back to the main game and feel like a badass. Platinum games work in a similar way. As another example, Horizon Zero Dawn does weapon upgrades in a really interesting way. Each type of weapon has normal / expensive / super expensive variants, but they don't do more damage as you move up the chain. They simply have more ammo types. You might start out with fire grenades, and then move to expensive and now you have fire and ice grenades, and then super expensive has fire, ice and shock grenades. You are upgrading your tactical options, not your power level. This does a great job of keeping the world dangerous, because I can't powercreep out the difficulty. Since this game is focused on procgen RNG for its weapon drops, instead of each weapon having a specific numerical damage number, you could do percentages. Like, your ship has a base damage amount (that you can upgrade) and you find super cool laser that does 120% of your base damage. Then you find a grenade that does 200% base damage but half the attack speed. That would avoid me running around with 2000 damage weapons and accidentally finding weapons that are completely below my power level and worthless.
|
|
#
?
Apr 20, 2018 17:51
|
|
|
TooMuchAbstraction posted:Tyrian and its imitators usually make items resell for the same price you bought them for. Thus you never "lose" money, and your money effectively becomes your power cap / experience level. Between missions you can sell old gear and buy new gear, change your ship around, etc. and figure out what the best loadout is for the amount of money you currently have, without having to worry about wasting anything. This is generally my opinion too. It sounds right for the style of game this is shaping up to be where everything is based on scavenging ships/items from what you fight and what you get is what you faced in the level. Another thing to help mitigate the procgen: the stage itself gives an item on it's first completion. Like one of those utility items you mentioned or a specific ship or a specific weapon so you will have a baseline of 'ok I know the player has access to these, so they should be able to handle this etc.'
|
|
#
?
Apr 20, 2018 23:49
|
|
|
I had a wacky idea that I'm thinking through as I type this. It's dumb for many reasons but I figured I'd type it up anyway. Items sell for more than you buy them for, increasing at an exponential rate (up to some cap.) A crappy blaster you buy at the start creeps up very slowly in value at first, but after a few stages it starts to go up more rapidly, and if you can manage to stay alive with that weak gun for long enough it'll be worth quite a pretty penny. When you trade it out for the latest and greatest, that new weapon has to start the value-gain over again, rising slowly at first and then with increasing rate. It therefore penalizes people for constantly upgrading: the best long-term strategy is to hold on to your weak items as long as possible, until you actually can't complete levels with them. Personal skill is placed more at the forefront since it lets you survive longer with the weak items and thus get the most profit out of them. Purchasing things is less a question of "can I afford it" and more "is it worth it right now?" Power is generally going to be acquired in large discrete jumps rather than a smooth curve, so people get a constant variation between easy and hard as they cycle items, with the size of the steps determined by how long they choose to keep old stuff around. Credits and items are still the only thing the player is accruing to power up, but in a very different way. The credits reflect player skill more than just a count of how many enemies they blew up, so players can take more pride in them. Any powerups you can get that are outside this value-calculus, like those settler items, are very valuable because they give you a short-term power boost without long-term drawbacks. Or maybe it only applies to weapons, and other items act normally? I'm seeing some major problems with this, though. First, it's counter-intuitive and will probably confuse new players. Second, it exacerbates the difficulty curve. People who are good at the game can get tons of money from holding on to basic weapons for a long time and break the late-game in half, while people who are struggling in the short-term and need upgrades are just getting penalized further. It could possibly be tuned so that players basically get to choose a relatively easy late-game at the expense of the early-game or vise versa, but that would be really hard to do with the procedural generation. The biggest issue, though, is that it discourages exploration and trying new things, since the best option is to just stick with what you've got. That's not good! Maybe it would make a good gimmick weapon, acting as an optional challenge in exchange for a lot of money if you can survive with it?
|
|
#
?
Apr 21, 2018 00:51
|
|
|
Karia posted:Maybe it would make a good gimmick weapon, acting as an optional challenge in exchange for a lot of money if you can survive with it? This is a decent idea. Start the player off with an "antique cannon" or something, and rarely spawn a shop that's an antiques dealer, which pays far more for antique weapons than other shops do. If you want to hold onto the thing until you find a dealer, you can, or you can just forget about it and play normally. Or maybe instead of starting the player with it, you just make "antique" a rare item affix, which has the sole property of making it more valuable to antiques dealers.
|
|
#
?
Apr 21, 2018 01:09
|
|
|
Karia posted:I had a wacky idea that I'm thinking through as I type this. It's dumb for many reasons but I figured I'd type it up anyway. This is a fun idea but yeah it wouldn't go well with the overall pacing. It's something I'll keep in mind, maybe for a challenge mode. TooMuchAbstraction posted:This is a decent idea. Start the player off with an "antique cannon" or something, and rarely spawn a shop that's an antiques dealer, which pays far more for antique weapons than other shops do. If you want to hold onto the thing until you find a dealer, you can, or you can just forget about it and play normally. I'm having Star Ocean 2 flashbacks. EponymousMrYar posted:This is generally my opinion too. It sounds right for the style of game this is shaping up to be where everything is based on scavenging ships/items from what you fight and what you get is what you faced in the level. This is a nice idea and gives me some other ideas. I think I'll add an exploration bonus similar to what you're describing that rewards visiting new places. But you also gave me an idea. Since there are item and ship drops I can tune the amount of drops and sell value of items so as to make buying new stuff not to be a significant loss. The average amount of items a player can buy should be a pretty easy to control value and I just need to define the curve and work backwards to tune the game for it.
|
|
#
?
Apr 21, 2018 06:56
|
|
|
A random thought, would price variation based on weapons/armor materials and technology, between different systems, be something to play with? E.g. in Alpha System, there is an abundance of Belcinium so you find lots of energy weapons based around that for cheap, but also everyone has shields effective against it, while in Yotta System those weapons are rare and fetch a good price, and most enemies also have poor protection against them. I guess that would be too difficult to balance with all the other factors already in play?
|
|
#
?
Apr 21, 2018 07:42
|
|
|
nielsm posted:A random thought, would price variation based on weapons/armor materials and technology, between different systems, be something to play with? E.g. in Alpha System, there is an abundance of Belcinium so you find lots of energy weapons based around that for cheap, but also everyone has shields effective against it, while in Yotta System those weapons are rare and fetch a good price, and most enemies also have poor protection against them. I guess that would be too difficult to balance with all the other factors already in play? I thought about that but I don't want to go any further in such a system because it seems at this point like feature creep. It's not a huge feature creep but from my own self-conscious I think of it as the kind of stuff someone would throw at a bullet list like "dynamic economy system" which is fine for a sandbox game but it's the kind of poo poo that would make me suspicious if it's a shmup. So basically me being too weary on the game industry. There's already a smaller version of that in. Some systems have higher tendency to spawn some types of shops. There are 17 types of shops and some shops will buy your ships/items at a different ratio. I could start detailing it and flushing it more and more but I won't for now because: 1) It's too easy and too much fun for a developer and it's easy to get lost in it. Seriously, working on economy systems, for a spreadsheet aficionado, is way too tempting. 2) I actually don't want people to play the game as a truck simulator. Nothing against it but in my mind I can see a lot of players going Elite: Dangerous on it and finding trade routes where they can flip items for a profit. Maybe 2 wouldn't be so bad because you still need to engage in fights every time you jump and who knows, maybe this could be a fun truck simulator, but it's still not something I want for now. I already feel like with the game as it is people might find ways to do it. nielsm posted:Ad point 2, could you give items an extra property, "wear-level", ranging from 100 to 0. Items bought from a shop generally have wear-level 100 (full value), while most random drops have wear-level 0 (functional but not good resale value), and have item wear-level drop over time as you use them. At wear-level 100 an item sells back to a shop at its full price, but after having used it for a bit you decide it isn't worth its while, but wear-level has dropped to 90. That lets you sell it back for 95% of the purchase price, giving almost no punishment for trying out alternative options. Uhhhhmmm this is really not a bad idea. Now that I think about it, it would hook with the system I already have in place reasonably well. I'll play around in my head and see how it goes, I'll have to change a few settings but I think this actually solves most of my problems. Thanks! Lechtansi posted:Since this game is focused on procgen RNG for its weapon drops, instead of each weapon having a specific numerical damage number, you could do percentages. Like, your ship has a base damage amount (that you can upgrade) and you find super cool laser that does 120% of your base damage. Then you find a grenade that does 200% base damage but half the attack speed. That would avoid me running around with 2000 damage weapons and accidentally finding weapons that are completely below my power level and worthless. The combat and itemization is as of now set in stone, if anything because I spent a lot of hours tuning it and testing it and if I were to change it I'd have to spend another dozens of hours retuning every item and reworking the combat and itemization classes which are literally thousands of lines of math. I think this game will involve a lot more dodging and trial-and-error than western shmups, depending on how feedback goes, so that might please you. Also, collision damage is pretty huge and systems with high threat receive an increase in damage done much higher than an increase in health so it motivates you to run them and dodge stuff rather than grind for gear, but I want the RPG element of getting stronger to be present. The gap between high and low isn't super present in the campaign (so you don't have to worry about getting lovely weapons), as I explain next. Alhireth-Hotep posted:I'm very eager to play this game, but I'm most enthusiastic about the upgrade systems and story mode, so I won't beg for an open alpha right this minute. Something that I've been noticing is that this genre forces you to effectively write two games and I never realized that until I saw the effort necessary. Think Diablo 3 and Path of Exile - the Campaign might use the same backend, but the endgame is completely different and involve a tuning of its own. They are two different games even if they use assets in common. I think the worst part still is the art creation time-wise but when it comes down to game design it's a bit of a pain. I think I posted this before but this is how the tuning is done right now: 1) There are 240 levels (you can fight stuff up to 260 in some situations but 240 is the cap for your items). The starting sector (A 100x100 area) is where the campaign happens and it ranges from level 0 to 80. Itemization and combat formulas are in. Universe formulas are defined (in that huge spreadsheet I showed last time) but not coded in yet. 2) There are pre-made shops spread across the campaign with accessible items and ships that provide a floor for how low your stats can be. Game already has the support for this (the initial shop is one of these). I haven't tuned all of the shops yet. Right now I have the script and design of the first chapter done, and three of these shops done. My idea is to have a premade Shop every two campaign stages. 3) While in the campaign you have what I call limited freedom to explore the map. 4) There's a bad luck prevention in your navigation that allow you to return to the starting zones. These systems are in, I actually refined them a few days ago. Navigation is a somewhat complicated algorithm because it involves a bunch of systems. You choose premade locations but these locations need to offer you a way to progress in the campaign, a way to progress back to the starting zone, and a way to mathematically guarantee that you can go anywhere you want once you're "free" while maintaining the appearance of randomness. To achieve the limited freedom, I'm using an algorithm I created years ago. It's based off of random walk which is typically used in games like Terraria/Minecraft to create caves and the likes. I instead create a weighted random walk that is pulled by magnetic forces creating a biased random walk. Some examples:  The entry point goes to a random point in each side of the map's boundaries:  To reinforce the apparent randomness the force of the magnet is influenced by a wave composed of multiple frequencies, and the sine of the signal dictates how strong the compass is. The power of the magnet increases with each iteration (in this case, the ever increasing value of the "bad luck" protection) and thus is bound to overpower the signal. I don't remember the value of the integral but on average the walk reaches its destination at magnet = 25% (maximum 200% to compensate for the negative value of the sine) meaning that the walk looks random at high frequency domains. What I like about this system is that it doesn't need to pre-establish a route towards anywhere, it only needs the vector of the destination and the bad luck protection. These images show a fully traced path but the system never needs to actually trace a path anywhere, so your decisions are not based on a pre-established path. Every time you choose a different stage the final random walk would look completely different but it'd still lead to the same place. 4b) Even if you can in theory go anywhere, it's still possible, theoretically, if your stats are impossibly bad and your stage selection poor, that you run into a very, very bad situation. So far I've done everything, both math-wise as well as in the design of the stage algorithms to avoid these kind of situations but at some point I'll just accept that they're part of the genre. I don't want to fill the game with extreme hand-holdings such as making stages easier if you fail at them a lot. 5) Re: Tuning of the campaign: As for numbers, these are some values: * A L80 Proton Emitter deals 3x the damage of a L0 Proton Emitter. * Some weapons are natively better than others and scale worse, and vice-versa, and some rare weapons are just better overall. Weapons are designed from scratch to follow the philosophy of perfect imbalance. But in general the maximum gap between weapon equivalency is a 20 level difference. * Weapon Traits close (or widen) that gap. * A full set of L0 weapons can kill a L80-100 ship, so as long as you can dodge stuff you can kill anything coming your way one ship at a time.
|
|
#
?
Apr 21, 2018 10:57
|
|
|
Elentor posted:4b) Even if you can in theory go anywhere, it's still possible, theoretically, if your stats are impossibly bad and your stage selection poor, that you run into a very, very bad situation. To a degree, this is a very key part of the roguelike and roguelite genres. Luck is always going to be a factor when any part of your progression, including the enemies you need to fight to progress, are randomly determined (I've been watching a friend try out a few randomizers lately with random map options, and they've had a run where the first or second room had a pretty tough set of enemies right out of the gate). What makes the luck based nature of these games workable (and enjoyable) is usually one or more of the following factors to ameliorate bad luck: 1. Player skill. The game is set up such that even with poor stats/equipment, the player's knowledge and skill attained over however many runs they've had to date is a huge asset just by itself. Though sometimes this comes down to knowing when to run away or knowing to keep ahold of literally everything you find early on because you know how it can be useful against randomly-spawned threatening things, or just to keep it out of the hands of gnomes. 2. Gradual accruing bonuses that carry over from playthrough to playthrough. Building up a town and/or depositing items in a persistent storage for use on future runs. 3. Quick turnover, and making it easy to get back to where you were. Usually accomplished by a game being short, sometimes accomplished by shortcuts. Heroes of Hammerwatch relies on all three. Spelunky mostly uses 1, but as the player dies and plays again, they can spend money inside a game to unlock shortcuts available outside of that particular run, so points 2 and 3 are valid here, too. Console roguelikes (probably most notably the Mysterious Dungeon series and any roguelike based on that series) tend to lean heavily on 2, as do the Digimon-raising Digimon World games, come to think of it, with inheritance, and completely sidestep 3 because you usually can't get game-overs. Tales of Maj'Eyal relies on 1 and 2 (progress far enough in one playthrough and you permanently get access to storage in all future playthroughs, complete certain conditions or quests and you get access to new classes, et cetera), but it can be pretty slow getting back to where you were in terms of progress. In this case I imagine it's mostly going to be 1, player skill, making progress easier as the player grows more familiar with the enemy AI, stage elements, and learns to recognise particular bullets, for possible examples. What situations do you think a player will get stuck in? Should they die, how much time will it take to get back to where they were previously? If the game ends up generating enemies that are impossible for the player to damage, or have a counter-type weapon that'll murder the player, can they just circumvent the issue by playing pacifist for the entire stage, or something slightly counter-intuitive but viable like that?
|
|
#
?
Apr 22, 2018 16:36
|
|
|
Feldherren posted:To a degree, this is a very key part of the roguelike and roguelite genres. Yeah, that's why I commented I'm not gonna go out of my way to fix it any more than I'm already doing, I accept that it's part of the genre and solving a math problem so that a player can never lose is way too much hand-holding for my taste. If things end up being unbalanced then I'll mess around but until then I'm not gonna pull my hair over it. Feldherren posted:Luck is always going to be a factor when any part of your progression, including the enemies you need to fight to progress, are randomly determined (I've been watching a friend try out a few randomizers lately with random map options, and they've had a run where the first or second room had a pretty tough set of enemies right out of the gate). What makes the luck based nature of these games workable (and enjoyable) is usually one or more of the following factors to ameliorate bad luck: Right now the biggest risk a player run is that the longer you deviate from the campaign, the higher the threat from the stages. This is similar to the Darkness in Kingsway, or a number of similar anti-grinding elements. I can't remember now but there was a space roguelike game that had an empire spreading its cover thus forcing you to keep on the run. Some games don't need any particular mechanic, Binding of Isaac at times made me not want to grind because of the risk involved in merely playing the game. Palace of the Dead in FFXIV offered a similar feeling, every second you're in a floor is a second you can trigger a trap and die. But in general, this "grinding requires a risk vs reward decision" is something very present in roguelikes and I want to keep it. My intention is that if a player follows the campaign and rushes it some of the stages might get difficult but not overly difficult, and they should all be doable with the tools the game provide you. I just finished implementing item wear levels as nielsm suggested and it really solved the economy problem perfectly because now a player can no longer gently caress up on a mathematical level by making campaign-sponsored upgrades. Which means any difficulty will come from execution and player skill. Campaign stages have a fixed threat and level and as such I can tune them to whatever I need to make them appropriately easy or hard. If a player, however, decides to grind before finishing the campaign, he or she can in theory do it so forever. This would be akin to running maps in PoE before finishing A10. However at some point you'll be running into high threat stages. At first it'll be, for example, 3 choices: Threat 0, Threat 0, Threat 4. Over time you might end up in a situation where the choices are all high threat and that might effectively be a game over for you if you can't run any of them. A possible solution to ameliorate the issue is to make it so every x attempts a stage rerolls a new layout with the same stats.
|
|
#
?
Apr 23, 2018 14:21
|
|
|
Elentor posted:Right now the biggest risk a player run is that the longer you deviate from the campaign, the higher the threat from the stages. This is similar to the Darkness in Kingsway, or a number of similar anti-grinding elements. I can't remember now but there was a space roguelike game that had an empire spreading its cover thus forcing you to keep on the run. Sil is a more traditional roguelike that has a similar concept. The game has 20 levels, arranged as sequentially deeper regions of a dungeon (so level one is 50' deep, level 2 is 100', etc.). It also has a "minimum depth" clock, which works out to IIRC 5000 turns per 50'. If you exceed the clock, then you can no longer go up staircases, and any staircase you take will crumble behind you until you're in front of the clock again (EDIT: to clarify, normally you can use staircases to generate new levels of an equivalent challenge rating). What this means, though, is that if you're skilled, you can rush past the early game without feeling like you're missing out on vital resources, and then do any grinding you need to do in the late game instead. Eventually the clock will catch up to you and force you to proceed to the endgame, of course. I guess what I'm saying is, there's some subtleties to how you push the player forwards. Keep a close eye on what the player's incentives are, and remember that there's a fairly large population of players that will identify opportunities to grind and then feel compelled to grind simply because the option is there. I.e. they are unable to "play suboptimally" by progressing before they have wrung every last advantage possible out of the game. A big part of game design is setting your game up so there's nothing that even looks like a boring-but-optimal strategy. TooMuchAbstraction fucked around with this message at 16:27 on Apr 23, 2018 |
|
#
?
Apr 23, 2018 15:44
|
|
|
Another interesting example of disencouraging grinding is Dungeon Crawl's food counter. While you could stay on early levels and farm the (very slow) respawns, you'd starve to death pretty quickly since the respawns don't provide anywhere close to enough meat to survive. It's a neat way of handling it organically, in a way that makes sense within the universe and uses existing mechanics. Of course, if you're playing as undead you don't need to eat. Those are dealt with by the dungeon increasing the likelihood of over-strength monsters spawning over time spent on a floor. Less organic (there's no real plot or explanation to Crawl), but effective. Sounds like that's more the route you're going, which makes sense since the threat level ties in to the campaign, so it does make sense in-universe.
|
|
#
?
Apr 23, 2018 16:22
|
|
|
TMA: Yeah it was FTL. Thanks for refreshing my memory. I agree with you guys on everything, ultimately things might not work the way I envision them at all so I'll have to retune the difficulty. Some stuff like the threat system is really trivial to tune or get rid off if doesn't work the way I want.
|
|
#
?
Apr 23, 2018 19:55
|
|
|
If it's not too difficult to add, I would love an "endless" mode. Believe it or not, some broken people like me play games for the grinding and don't want to ever finish the main story. Ask me about having a thousand hours in Bethesda games and still being on the tutorial mission. Also, breaking and/or steamrolling games is fun.
|
|
#
?
Apr 23, 2018 21:08
|
|
|
An endless mode will (likely) come out before the campaign is finished.
|
|
#
?
Apr 23, 2018 21:23
|
|
|
|
| # ? Apr 16, 2024 06:34 |
|
|
This is not chapter-worthy but I just wanted to leave it here because it's so drat cute. I added little ship models to the stage select map indicating where you are and they're adorable. 
Elentor fucked around with this message at 14:44 on Apr 25, 2018 |
|
#
?
Apr 25, 2018 14:40
|
|