|
Elentor posted:Not functional, but it's a start I want Stages to have traits (which will show under the "Mission" tag), like random map modifiers in Path of Exile, so that space is left blank for that. I haven't decided on the traits yet, but I'm considering stuff like "Stage is at Night" so your solar-powered gear won't be as useful, maybe wackier stuff. Unmapped Minefield: bad news for everyone! Survey Data Available: high value asteroids marked Most Wanted: high value enemies marked Sand / Micrometeors / High Radiation: various survivability debuffs Convoluted Space: asteroids and enemies wall-wrap Mirror Anomaly: fight your own ship history Solar Storm / Bombardment: avoid damage zones - marked as they're incoming Proving Grounds: prototype buff to ship during mission - test equipment may have bugs, payout bonus if encountered Space Race: enemies face same direction as you, don't shoot, ones faster than you come from bottom of screen Elentor posted:https://www.youtube.com/watch?v=2bzMsCJHqDM
|
#
?
Sep 5, 2017 14:47
|
|
|
|
| # ? Apr 24, 2024 21:05 |
|
|
Fish Noise posted:Enemy Minefield: bad news for you! Jesus gently caress these are some good thoughts but Mirror Anomaly is one really fantastic idea.
|
|
#
?
Sep 5, 2017 14:57
|
|
|
Almost got enough content for a new update. Should be coming out this weekend. 
|
|
#
?
Sep 13, 2017 04:21
|
|
|
Elentor posted:Almost got enough content for a new update. Should be coming out this weekend. 
|
|
#
?
Sep 13, 2017 06:29
|
|
|
Alright, sorry for the huge delay. Working on the Ship behaviors has been a huge task, though in all fairness 3 weeks seems like a reasonable time frame for it. But the whole thing is done! At least something functional enough. I'm writing the next chapters already and got a bunch of work done on the game, so the next 3 chapters are already planned. Should come out relatively soon (tm).
|
|
#
?
Sep 25, 2017 20:27
|
|
|
Chapter 9 - Ship AI, Part I For the past three weeks I've been working on Ship AIs, which are the most important part of the game at this point. I say "AI" in the loosest sense, it's more behavior/patterns. Basically how the enemy ships are gonna move. This isn't a big issue when making a traditional Shmup because I can assign the patterns manually, but since this is a procedural Shmup, I needed to split the traditional ship behavior from the genre into separate variables. So the first thing I decided on is how to spawn the enemies. Enemies spawn based on level duration and they spawn on a fixed offscreen position. I split them in two major groups: Top/Down and Right/Left and created the Spawning Behavior class. These are the first elements to be part of the Spawning Behavior:  Screen Position -> Which part of the screen are the enemies gonna spawn? This ranges from 0 to 1. So enemies spawning from the Top at 0 will spawn at the leftmost corner, 1 at the rightmost corner. Angle -> The initial angle of the ship. Can either be absolute in Euler Angles or looking towards a pre-defined screen position, so that in theory a ship can spawn facing the player, for example. Afterwards I included ship amount so that a single instruction can spawn multiple ships. This is really useful because ships usually come in multiples in Shmups.  Amount -> How many ships are gonna spawn. OffsetX -> The distance between each ship from each other in the X axis. OffsetY -> The distance between each ship from each other in the Y axis. Basically, a spawn delay. This already makes things a lot better. I added a second mechanism to duplicate the original group with the same values - amount and offset.  Finally I added Symmetry, which is applied dead last.  *Center of Symmetry -> Which point of the screen is the symmetry going to happen. This allows me to make ships "escorting" a different ship, for example. This sounds like pretty much everything we need to get started. Let's try it out. https://youtu.be/JCe1fpdRZi0 Alright! Second, we need to get these ships moving. So we're now gonna deal with the MovementBehavior. SpeedXY -> The X and Y values for speed. RelativeToTransform -> Whether the speed is absolute (that is, Speed X means the speed across the screen's width, for example) or relative to the object's matrix (in which case X means going to the ship's right/left). IsAffectedByScrolling -> Whether the ship has a "fixed" movement speed across the screen or if it's affected by the scrolling speed.  SpeedMod -> A delegate that allows for custom functions to be passed. It receives the base Speed, Ship Position and Rotation, how long the ship has been alive, how long has it been since the stage started and a bunch more stuff. Which allows us to do stuff like a basic deceleration: code:code:code:https://youtu.be/22q_IuicfRs I think these cover pretty much everything I can think of for now, when it comes down to spawning and shooting. So now let's test some assorted patterns. All of these are made by hand for debugging purposes, no procedural stuff yet other than a few random spawning positions. https://www.youtube.com/watch?v=UGX0pSsPjY8 NEXT TIME: More Enemy Behaviors! Shooting!
|
|
#
?
Sep 29, 2017 01:03
|
|
|
Here's something unrelated, but pretty neat: https://www.pathofexile.com/forum/view-thread/1998012 A bug on Path of Exile's procedural level generation rendered the entire map unwalkable because it reversed the walkable with the unwalkable areas. Pretty short, but nice read.
|
|
#
?
Sep 29, 2017 03:44
|
|
|
Playing with AI behaviors is fun for the crazy things that happen when you throw stuff at the wall to see if it sticks (like the Unholy abomination shown.)Elentor posted:Here's something unrelated, but pretty neat: This reminds me of my first ever programming snafu (that I found hilarious:) a basic 'underline all instances of a string from another static string' program in C++, only because I forgot a ; I ended up replacing the stuff to be underlined with just the underlines. Those mistakes never stop happening, even when it takes a particular edge case to trigger an oversight 
|
|
#
?
Sep 29, 2017 10:46
|
|
|
Programming oversights are great, I'm glad when the devs are open about it. I'm kinda curious about GGG's implementation, I actually wish I could see their map algorithm editor/viewer now. Speaking of underlines, I've had some similar oversights when designing the random name generator. One of my iterations yielded stuff like this: B__A A B AA_B A_B_A AA 0 A_B __ A _ B _ A I don't even remember what the hell happened back there.
|
|
#
?
Sep 29, 2017 14:18
|
|
|
Did you leave a copy of Waterloo in the neutral net input?
|
|
#
?
Sep 29, 2017 14:25
|
|
|
In college, one of my professors once related the most horrifying bug I've ever considered the prospect of having to be the one to debug. It was in a dogfighting game, where they discovered that if you flew directly at a plane that was flying towards you, the AI would just launch the enemy plane straight down and crash into the ground immediately. The twist? It only happened with certain video cards.
|
|
#
?
Sep 29, 2017 14:31
|
|
|
ProfessorProf posted:In college, one of my professors once related the most horrifying bug I've ever considered the prospect of having to be the one to debug. It was in a dogfighting game, where they discovered that if you flew directly at a plane that was flying towards you, the AI would just launch the enemy plane straight down and crash into the ground immediately. How did that even happen?  Something messed up with using Compute Shaders to run the AI, or some more obscure low-level bug?
|
|
#
?
Sep 29, 2017 15:23
|
|
|
I suppose it could have something to do with framerate, if the AI updates were affected by how quickly a frame could be rendered. How old was this game?
|
|
#
?
Sep 29, 2017 15:26
|
|
|
No clue, he didn't say what game it was. The class would've been somewhere around 2008, so before then.
|
|
#
?
Sep 29, 2017 15:33
|
|
|
TooMuchAbstraction posted:I suppose it could have something to do with framerate, if the AI updates were affected by how quickly a frame could be rendered. How old was this game? Remember, the initial PC Release of Dark Souls tied several checks to frame refresh, including weapon and armor durability. It's a pretty common bodge to avoid creating an independent clock.
|
|
#
?
Sep 29, 2017 16:17
|
|
|
Yeah, that's a shame. A lot of games, especially ones that are released for console, tie physics and other calculations to frame refresh. Makes things tougher than necessary later on when they want to release a port.
|
|
#
?
Sep 29, 2017 18:09
|
|
|
Here's a bit of a live posting: I've been trying to solve a very weird bug that's occurring in my game. It would have taken me a while to find it if not for the Let's Play, as writing the chapters force me to debug a lot more stuff than usual for the posted content. So this occurs in the debug shooting scene. I was playing with Ship Behaviors since the next chapter is about enemy ships shooting, when I realized that the ships just don't look right. They don't really feel right. Then I pinpointed the bug to this: Sideway ships, while not moving sideways, don't animate their weapon turrets properly. If they're moving in any way, whether the speed is set to 1, 0.5 or -0.1, then it's fine. But if the horizontal speed is set to 0, the weapon mounts just don't work properly. This is a pretty crazy bug, given that none of the shooting or weapon code refers to the ship speed. I have an idea of what's causing it, but that's what I've been up to in the meanwhile.
|
|
#
?
Oct 5, 2017 02:54
|
|
|
Oh boy, bugs tied to one thing despite not actually being referenced! You should see if vertical ships have the same problem (having them come in from the side for example.)
|
|
#
?
Oct 5, 2017 03:06
|
|
|
I just found out the code for the weapon rotations was flat out wrong, the kind of which was super fast to recognize how wrong it was, which does bring me to three questions: 1) Why the hell I wrote it 2) No, seriously, why 3) Why was it working before? 3 is pretty much the scariest thing. I tested each weapon animation individually and even recorded videos in my other thread, but they were not supposed to work. This is some ghost story stuff. Anyway I fixed the most glaring issue (which solved the problem temporarily both for speed.x = 0 and speed.x != 0) but the code is still based on some wrong math which I'll rework. Luckily, it's nothing too complicated. Whatever made it work before, however, is what scares me. EponymousMrYar posted:Oh boy, bugs tied to one thing despite not actually being referenced! Looking at the code, I think vertical ships were part of the problem. I think a mix of two things messed up the code: The ship's sideway movement animation, and the fact that some weapon turrets are aligned differently, especially on vertical ships. Elentor fucked around with this message at 03:22 on Oct 5, 2017 |
|
#
?
Oct 5, 2017 03:16
|
|
|
Chapter 10 - Ship AI, Part II Shooting The ShootingBehavior is a bit different. It contains a few simple instructions that allows me to add a weapon to a ship, alterate the weapon stats and control in a simple way when it shoots. The basic functionality of each Behavior is adding a weapon and setting a damage and cooldown multipliers for the damage. The ShootingBehavior allows for the override of a ship's stats though, so I can turn any ship into whatever I want for the campaign. It offers control over the Weapon Animation, Rotation (so that I can make a ship that always shoots down or at the player) and, if I want, override of the Weapon's Cooldown and Damage. In the future I intend to add in custom functions to decide whether or not to shoot, but for now I added the following five variables: Timer - The minimum amount of time before the ship starts shooting, and for how long it will shoot. Angle - Which angle in front of the ship the player needs to be in order to trigger a Shoot(). Min DistanceX - The horizontal distance in which the player needs to be in order to trigger a Shoot(). Min DistanceY - Same as the above, but vertically. Min Distance - Same as the above, but considering both axis, taking the absolute distance into account. Alright! With these I can make pretty much everything I need short of a multi-phase boss. So what else do we need? Injecting Custom Stats I've also been working on ways to override the ship stats. Again, the reason I'm doing this is for campaign stuff, it's pretty useful to be able to arbitrarily decide or modify a ship. The reason this merits mentioning is because of the current internal pipeline. There's a ShipSeed, which is a serializable structure that holds the number of the Seed as well as other parameters, such as the Faction and Ship Class (so that the same value yield different results based on those, since they'll hold different algorithms). The ShipSeed then is passed through the Ship Generator and it becomes the ShipData, which holds the actual content for the Ship. This is a bit of a complicated process because some of the data is dependent on the actual model generated. I think I mentioned this earlier, but the model size can increase the ship HP, for example. The current system allows for more complex interactions, some of which I intend to implement in the future when I add affixes to ships and items. Point being that the ShipData isn't saved (at least not now) and is stored entirely in memory. Remember how in Diablo 1 you could hack your unique items to your heart's content but no matter what you did, once you saved and loaded the game they'd revert back to normal? It's the same principle. Stuff like HP and Shield isn't stored in the "savable" data format, so if someone were to edit the memory of the game and change their ship's HP, that information would not be saved. What is saved and what isn't vary from game to game. In my case, you don't really need your HP to be saved because the process with which it's generated is (if I don't mess up) always the same and you can never have less than maximum HP between sessions. Your characters in FF7 have their HP saved, for example, because the minimum HP can be different from the maximum HP, and the maximum HP is incremented by a random roll every level, so two Level 50 characters can have different HP values. I mean, theoretically you could save things that are not the HP directly (like a... seed) but it'd be overkill. Anyway, the reason I'm explaining this is because at some point I realized that I needed to be able to change ship stats at will for the previously stated reason (campaign editing) and "well, why can't you just do it then?" is a valid question, but I don't want to change the current structure too drastically. I don't want to add a bunch of optional variables to ShipSeed controlling each thing I might or might not want to change. One of the thing I realized though is that I already have a system to modify things, the affixes system. So what I can do is facultatively add hidden affixes that change things the way I want. I can add an optional Health Multiplier, for example. This seems the best way to do things for now, though I'm still working some of the details. Testing Stuff Now that we have everything we need, let's inject some of the ships from the previous debug with a few shooting behaviors. https://www.youtube.com/watch?v=1BARyQxknGI A few bug fixes here and there, and we got the ships working as intended, and the performance is pretty good. I think with this out of the way the game has almost all of the internal systems complete. I think it still needs a few things added to item modifiers, a shooting AI delegate function and some more state machine features, and that's it. Before we move on, though, I want to talk about the "few bug fixes here and there". I encountered a very weird bug in the making of this video. These ships are supposed to have their weapons rotating all over, but this is what happened instead: https://www.youtube.com/watch?v=Lem33XdsOcc So this is pretty weird and definitely not what is supposed to happen at all. After testing a bit, I found out that if the ship's horizontal speed is set to anything other than 0, the turrets worked. Somewhat. But the ship speed isn't referenced anywhere at all in any of the code related to shooting. Spooky! Something that exists in the code is a vector normalization that forces projectiles to move on a plane. In other words, the Y axis of projectiles should always be 0 while maintaining the proper vector speed. I decided to remove that code to see what happened. https://www.youtube.com/watch?v=DDlaiXxzS2M Hmm okay. So we can now see the problem plain as day. The turret is rotating in the wrong axis. Looking at the code I saw this gem: code: This is the mount and its axes. Right now we're telling it to rotate on the right axis, and it is doing exactly that:  To rotate the way we want, we need to rotate it on the Up vector, so that's the important thing to change. The reason why the turret worked when horizontal speed was different than zero is because the ship is animated to tilt sideways, and the small tilt gave enough Up rotation to the turrets to look like they were working. Anyway, there's another problem at hand. What happens if the ship is vertical and the weapon is mounted sideways?  Things are gonna get messed up again. In fact, the old code would have worked perfectly for weapons aligned this way, while the new code won't. This is because the current code is rotating the mount in Local space, and we want our Up always to face the same direction. We want to rotate in World space. Fortunately the Rotate functions allows us to do just that by putting Space.World at the end: code:After I fixed it, everything works as intended: https://www.youtube.com/watch?v=EHvz9zXgc08 And with that, we conclude this update. What's Next? This time you help me decide what I'm gonna do next. I've been having fun testing out the content that I have and I want to give it a polish, plus the past month and a half has pretty much been coding internal systems and stuff that are, to be blunt, a bit boring. So now let's play around with content and graphics. Plus, I might record a video of the process since I think some of these can be kinda chill to watch. 1) Adding some new weapons. Lots of art involved and probably some custom scripts for them. 2) Working on Procedural Ship Textures. Right now they're kinda bland. I have some ideas on how to spice them up. Really interested in seeing how far I can push them. 3) Working on better Ship Gen. Algorithms. I'll have to do this eventually because each Faction should have a different algorithm. In the meanwhile, I intend to play a bit more with the menu GUI and add more functionality to it, so that later on I can implement shops and allow the player to change ships and weapons. Elentor fucked around with this message at 22:28 on Oct 6, 2017 |
|
#
?
Oct 6, 2017 22:26
|
|
|
Do some weapons, perhaps some missile types with cool particle effect trails.
|
|
#
?
Oct 6, 2017 22:38
|
|
|
Wait, is that a vote? I kinda like the 3D projectiles. Maybe you could have some ships fire tracking missiles that go into the background/foreground and then turn around and try to slam through the player.
|
|
#
?
Oct 6, 2017 23:09
|
|
|
TooMuchAbstraction posted:Wait, is that a vote? Yeah missiles that get fired up towards the camera in a ballistic arc kind of way could look cool.
|
|
#
?
Oct 6, 2017 23:20
|
|
|
TooMuchAbstraction posted:Wait, is that a vote? Yup, it's a vote! I'm open for suggestions.
|
|
#
?
Oct 6, 2017 23:41
|
|
|
Textures! I wanna see if that reverse-engineered Dominions RNG has any practical applications. 
|
|
#
?
Oct 6, 2017 23:46
|
|
|
Elentor posted:Yup, it's a vote! I'm open for suggestions. Okay, then let's improve the ship generator, because IMO that's the coolest part of your project and I want to see how far it can be pushed.
|
|
#
?
Oct 7, 2017 00:25
|
|
|
3: Improve Ship Generator. The more you look at it, the better it'll be (and the more bugs you'll squash along the way!)
|
|
#
?
Oct 7, 2017 02:56
|
|
|
God i hope I don't have to find any new bugs in the ship generator haha. Which, I know, it's a pipe dream.
|
|
#
?
Oct 7, 2017 03:36
|
|
|
3. ShipgenTooMuchAbstraction posted:I kinda like the 3D projectiles. Maybe you could have some ships fire tracking missiles that go into the background/foreground and then turn around and try to slam through the player. nielsm posted:Yeah missiles that get fired up towards the camera in a ballistic arc kind of way could look cool. Also something to make sure they're not blocking the view. Probably. It's a bit of a "Is this Raptor/Tyrian or is this Jets N Guns?" question.
|
|
#
?
Oct 7, 2017 05:51
|
|
|
I have some pretty crazy ideas re: weapons but I don't think they'll be very intrusive. Hopefully. Otherwise I agree, if I make something like a missile that curves upwards I'll keep in mind not to make something that is needlessly blocking the view.
|
|
#
?
Oct 7, 2017 18:11
|
|
|
Elentor posted:I have some pretty crazy ideas re: weapons but I don't think they'll be very intrusive. Hopefully. Otherwise I agree, if I make something like a missile that curves upwards I'll keep in mind not to make something that is needlessly blocking the view. This may sound stupid, but maybe have them arc down instead of up, so that the the curve is away from the player, they get smaller (which has the twin benefits of being less obtrusive and harder to see), and puts them below the other projectiles, meaning they are effectively blocking it instead. That said I have no opinion on what direction you should take this in, I'm just patiently waiting to throw money at this.
|
|
#
?
Oct 8, 2017 06:05
|
|
|
It doesn't sound stupid, don't worry. I think it's less intrusive but it also misses the "oomph" of something falling and crashing I think, which is part of the coolness factor of a vertical curved arc.
|
|
#
?
Oct 8, 2017 07:30
|
|
|
They're both potentially useful. Background projectiles can linger longer without being a UI problem, letting you do stuff like have an enemy spam a dozen into the background and the player has to remember what order they were fired in to dodge effectively. Foreground projectiles probably shouldn't linger much at all, but can be punchier and, since they don't take long to "go off", be more directly worked into bullet streams.
|
|
#
?
Oct 8, 2017 14:31
|
|
|
Player projectiles arcing up could perhaps be saved for some sort of ultimate attacks you don't get to use very often. Speaking of that, to what extent do you plan for the armory to be generated vs. static?
|
|
#
?
Oct 8, 2017 15:39
|
|
|
nielsm posted:Player projectiles arcing up could perhaps be saved for some sort of ultimate attacks you don't get to use very often. You mean whether the ships and items are preset? I'd say 95% of the ships will be generated. I'll punctuate the campaign with some shops selling preset slightly-below-average ships for the players that are unlucky but that's it. There are concepts for really rare "unique ships" that are static but are generated from a different DNA that can be mixed with other ships. This isn't high priority right now but I like the idea of being able to mix ships and I think it'd be pretty surprising if the player found out he can mix with unique ships as well. I don't intend to include procedural weapons. Maybe if I figure out something that can work really well... the thing with procedural ships is that I think most procedural systems can be kinda boring if not implemented properly, and I had this entire fleshed out thing in mind for the ships that I felt was worth the shot and it worked. There's something cool about the idea of proc ships and you being able to fly them and what not, at least for me it was a very nice gameplay fantasy, and having tested it, it still is. The first moment I got these ships working it was super neat. I think if I were to do, say, procedural weapons, it'd be in an FPS environment. Like it's the point of the game, and everything is fleshed out around them, and the game has super realistic physics and sometimes you just get a crazy weapon that forces you to adjust to an exotic bullet trajectory. Like a game with really fleshed out physics. That might be a super boring game, or it might be super interesting, but that's the kind of procedural weapons that I'd be curious to try out. There's probably a way to do the same in a Shmup, it's not like there are huge limitations, but I also feel like unless I do an exceedingly good job at making a robust procedural itemization, it might dilute a bit the gameplay. I like exploring things in Binding of Isaac and while there's a huge RNG involved, the items are all unique and peculiar, they all have a strong aesthetic and personality. I think most procedural games need to have an anchor, and I like what I have planned for the items so far. Right now I intend weapons to have up to 2 random affixes, like Diablo magic items. Weapons also drop with an item level soft-scaling with the area you're in. This means: 1) Weapons have a baseline level required to drop. The chances drop radically if you're in an area below that level. 2) Weapons drops slightly decrease as the weapon base level falls under the area level. 3) Weapons can drop with a level rolled between their base level and the area level. This means that the possible list of weapon drops increase the higher the area level, and also that low-level weapon bases become slightly more uncommon, but that it's still possible for a player to roll a nice low-tier weapon with a high item level if they're lucky. I'm not homogenizing the drops because I find things extremely boring if there's no excitement in a rare drop and this way even a low-tier weapon can be exciting if it's one you enjoy. Weapons of same tier also have different drop rates and I think I mentioned before, but some weapons can only drop in environments of certain exoticity levels. Speaking of homogenization, the stats of weapons of the same level are not too far off each other but they're not homogenized, I'm purposely adding some slight differences between them to spice things up. I think it can be doable to change some of the projectile textures based on the affixes. Some ideas that I scrapped were that the weapons themselves would have appearances (as in 3D models) and these would also feature a bit of the model generator to add details so that they were kinda procedural, but I decided against it for a myriad of reasons.
|
|
#
?
Oct 8, 2017 19:33
|
|
|
I'm currently working on the Ship Generator. In preparation for what I intend to be the final system, I'm writing a few design documents: 1) The general guidelines for each Faction and their art direction. 2) The Ship Classes. I can't have a single algorithm to generate the ships, otherwise stages will look pretty flat. 2b) Should I allow the player to play ships of different classes? This would be something almost akin to an Easter Egg. Have for example some of the large enemy ships be extremely rare drops and be less than optimal because of the size, but playable. Not "less than optimal" as in trying to control a Star Destroyer in X-Wing Alliance, but still feel like you stumbled on something different. 3) Segmenting the ship generation into chunks that can be mixed between different algorithms. 4) Considering adding skins and stuff that would replace the basic blocks of the ships. This way I can use the same blocks to attain different results.
|
|
#
?
Oct 11, 2017 21:23
|
|
|
Elentor posted:2b) Should I allow the player to play ships of different classes? This would be something almost akin to an Easter Egg. Have for example some of the large enemy ships be extremely rare drops and be less than optimal because of the size, but playable. Not "less than optimal" as in trying to control a Star Destroyer in X-Wing Alliance, but still feel like you stumbled on something different. I really liked what FTL did, starting you out with a single ship, and as you played through to lots of different situations your unlocked more playable ships from other factions/races.
|
|
#
?
Oct 11, 2017 21:32
|
|
|
Elentor posted:2b) Should I allow the player to play ships of different classes? This would be something almost akin to an Easter Egg. Have for example some of the large enemy ships be extremely rare drops and be less than optimal because of the size, but playable. Not "less than optimal" as in trying to control a Star Destroyer in X-Wing Alliance, but still feel like you stumbled on something different. Except by making them optional and occasional surprises, this sounds potentially even more fun, especially since players won't get locked into something that makes them scream FLY YOU PIG in a mission that basically everybody dreads.
|
|
#
?
Oct 11, 2017 22:49
|
|
|
nielsm posted:I really liked what FTL did, starting you out with a single ship, and as you played through to lots of different situations your unlocked more playable ships from other factions/races. What I mean is more akin to playing ships that immediately don't look like they should be playable. It'd be really easy for me to implement. For instance, playing ships from the other factions is planned. But factions have multiple algorithms for ship generation. Here's a rough example: 1) Drones (tiny ships, low health) 2) Fighter (the playable class) 3) Heavy Fighters (larger fighters) 4) Corvettes (Far larger ships, less "aerodynamic" look) 5) Frigates (Even larger than corvettes) 6) Boss (huge monstrosities) So if we were playing Raptor these would be the enemy fighters:  And this would be, say, a Corvette:  The idea is that some of the different ship classes from each faction could also be available for the player to use, either through an easter egg/secret event,as a rare drop, or both. So that in this case you'd play a corvette (although probably scaled down a bit, so that if your ship is 1x size and a corvette is 3x, you'd play a ship of ~1.7x size for example) and feel more or less like a mini-boss. The game would not be tuned for them long term, so my idea would be that they have power spikes to make you feel super good but that eventually you'd need to replace them for a smaller, down-to-earth ship again. Fish Noise posted:Immediately, the locked ship missions from Jets'n'Guns come to mind, where you could only fly the mission-specific ship: maybe your spacesuit with giant guns strapped on, maybe an unarmed piece of poo poo pirate ship through an obstacle course, maybe a cargo ship you stole and transferred some guns onto... Yeah, they would be optional, treated like regular items. I already want the starter ship to be unsalable so that the player can't be locked out of a regular ship. But the idea is that they'd be rare gimmicks, maybe even something that at first glance would make a savvy player feel like he stumbled upon a bug and that the ship generator gave him something that should be NPC-only. I'm not sure if I mentioned this before but I also want ships to have a very small chance to be able to drop themselves when you kill them, so anything that you see on screen can potentially be played by you without having to rely on the luck of rolling the exact seed of an enemy ship on your next drop.
|
|
#
?
Oct 12, 2017 01:26
|
|
|
|
| # ? Apr 24, 2024 21:05 |
|
|
At the moment I'm working day and night on the Ship Generator. The hard part is done (I think). As soon as I finish refactoring the code I'll do some testing, work on the algorithms, then post an update. Next batch of updates are about the factions, the faction ships, the ship generator and how things will be looking after this new set of features.
|
|
#
?
Oct 17, 2017 06:01
|
|