|
Tyrian and Raptor? Nice.
|
#
?
Oct 17, 2017 06:37
|
|
|
|
| # ? Apr 19, 2024 06:00 |
|
|
Next update should come on the next few days. I've finished all the refactoring in the ship algorithm code, worked on some of the main faction ships. Here's the current LP Roadmap: 1) Factions, Ship List and Game Story I want to talk a bit about the actual game. Most of the stuff I've shown so far are proof-of-concepts because I believe that being able to show that you can produce something is important. But now that I got most of the hard part out of the way and I got a functional prototype, I want to talk about my plans for the future. 2) Video showing off some Concept Arts I plan to post a video of me drawing some of the ship silhouettes and talking about the factions and assorted stuff. One of the videos is already recorded. Should be fun. 3) ShipGen - Imperial Ships The process behind designing the ships used by the bad guys. 4) Ship DNA and Refactoring The process behind how the code works, and some samples showing off ship mixing. 5) Procedural Textures I'll play around with this and see if I can get a good result. If I do, I'll make a chapter about it. 6) The Game Dev Roadmap As soon as I get all of these systems in place, I think all that'll be left will be producing content. This should make easier for me to make a roadmap of the actual game with some estimated dates.
|
|
#
?
Oct 22, 2017 06:07
|
|
|
Chapter 11 - Factions and Story This Chapter is going to be a bit about the game lore. No technical stuff. Since I'm working on the ShipGen now I'll be implementing a few of the faction ship algorithms, so I thought this would be a good point to drop details about the game's background and flesh it out. Universe I want to make the story start with a bit of a familiar feel, hitting some of the notes that the 90's games hit. The main set pieces are all very familiar. There's an evil empire, you start the game having to escape your home planet being attacked. You're caught in the middle of a war. That's not to say there's not a vision behind these elements. The background is very fantastic, and not hard sci-fi, which I think suits the media well. I don't want to spoil things, but I do have a lot of things in mind for the campaign and the story so I'll let you know, without spoilers, some of the stuff written for the game lore. So let's delve into a bit of fiction, shall we? You You're one of the surviving settlers of a generation ship from Earth. Upon arrival at the common Sector, the settlers woke up the remaining crew from hibernation and started their colonies. Using some of the data in the ship to kickstart technology, throughout the decades the settlers spreaded throughout the sector. So far, so good. Due to unknown reasons, most of the original settlers that were not in hibernation are immortal. Somewhere in your thirties or forties, your body ceased to grow older. You cannot get sick either. You, in particular, are known as a Protector - a group of pilots who posited a theory that you're not only immortal in the sense that you cannot die of old age, but also that you cannot be shot down, and thus you're able to use combat in your favor to solve whatever conflict you deem necessary. This has been disproved since a lot of Protectors have been killed over time, though they were usually Pyrrhic victories and it takes an extraordinary amount of resources to murder one of you. The newer generations are not immortal. Needless to say, the newer generations - and most of those who didn't choose a career of violence - are not particularly happy with Protectors. You are a very, very old pilot, and given how many civilizations came and went, and how many calendars you've seen, at some point you stopped counting your age. In your mind you stick to the settler's system of measurement, and by now suspect you're a few, maybe five to six hundred Earth years old. Maybe a thousand, who knows? You could count if you put your mind to it, but it's not relevant for you anymore. The memories of your arrival are almost entirely gone. You try to keep it alive but it's been so long that you feel like it's a distant dream. You keep notes and backups of your diaries, but even as you read them you can no longer connect with the events. Words about an urgent transmission from Earth that shouldn't have ever been able to reach you. System malfunctions in the ship. The only sensation you distinctly remember is that, for a moment, you were sure you were going to die. There are many names by which the common folk refer to you, though usually behind your backs. Cheaters, The Protected, Meddlers. There are many who believe you and the other Protectors simply withhold technology that was shared by the Earth ancestors for your own personal benefits, your own glories, and that everyone should by birthright be immortal like you are. Your own daughter spent a good chunk of her life researching how to extend the human life spawn. Regardless of how hated you are, throughout the centuries, conflicts and factional disputes unavoidably appealed to Protectors for a quick solution. Because of that, over the course of History the list of enemies that a Protector has usually only grows. Most Protectors are seen as enemies of the state - whatever state it is, because odds are that you fought against it or one of its founders in the past. Eventually Protectors learn to stop meddling, but that for most of you came too little too late. For the past century you've been living a life of luxury protected by the planet you stuck to defend, but to the rest of the sector you are still a threat. From time to time, you play a few deathmatches with one of your friends. You should visit him, but you're one lazy spoiled old man these days and he's more than a few moons away. The Tools of the Settlers Regardless of cultural differences, one myth or conspiracy theory shared by all worlds is that of the tools of the settlers. The myth differs slightly, but it usually revolves around the fact that the original technology used for terraforming, ectogenesis, early space exploration, medicine, and other aspects of colonization have their whereabouts currently unknown, along with the original DNA databank and animal and vegetation samples from Earth. It's assumed that they've been stolen by the original settlers, likely owned by protectors or private companies that bought them long ago. The conspiracy theory states that whatever made you immortal is also one of these lost tools - something that you don't believe to be the case, but that you cannot disprove either. No one knows where the original generation ship is, even. The AI in your computer would probably be considered one of those fabled artifacts by the general public. You know some of your old colleagues had stolen some bits of tech themselves. Although you never cared for it, you're starting to wonder about the things you don't know lately. Idle hands are the devil's workshop. Space Oddity You do, however, know that some things are off, and some of the general population is starting to figure it out as well. You've been to the corners of the sector and beyond, and you know why most of the colonies coexist a few star systems from each other. Things get weird out there. Not alien-weird, although you wouldn't be surprised if aliens also existed. But the idea of aliens don't scare you as much as the inconsistencies that trouble your mind. The little things. The further away you move from the common sector, the weirder things get. You swear you once saw a star moving way too fast in the depths of the space, but that might have been a lens flare. You once saw in your ship's history that the thermal regulator had the heater operating at maximum capacity, right around the time you flew close to a white star. That has to be a glitch, but your AI swears things are a-okay. You also have two "tools of the settlers" that you never revealed to the public - a picture of Earth, taken by one of their ancient probes, and a picture of the Earth's night sky, in case you ever lost your way. You keep it in your cockpit at all times, just so you never forget: It's full of stars. Stars that don't match the ones you know. Galaxies that don't match the universe you know. Wherever you are, when you look at the night sky you don't see a fraction of the stars that the Earth folk saw. The sky is dead. Campaign: The game mixes the free form exploration with the campaign. The campaign has a beginning, a middle, and an end. You start off playing a few campaign missions before you're tossed at open space (though I do want to implement an option that allows you to skip the campaign entirely when making a new game). I want the plot to be there, but presented non-intrusively. Something between Path of Exile and Dark Souls. A player should be able to just enter the game, blow poo poo up, and Alt-F4 without having to watch cutscenes. The tools of the settlers are a bit of a MacGuffin, and some of the story revolves around them. They're an umbrella term for the relics of the past that tie to your investigation into what the hell happened. Each one of them has a point, an actual functionality and a reason to be. The main campaign is divided in 5 chapters. These chapters have 5 to 8 maps each. I've written 54 mini-stories or extra chapters that would serve as side-quests to fill in the rest of the space. The idea is to make the main campaign first and then update the game over time with these extra chapters. They may be fillers in the sense that they're side-quests but they're not fillers in the sense of being a non-story - that's what the open world procedural element of the game is for. I like to think of them as an anthology of sorts, some show a bit more of the universe's backstory, some show plot elements that converge back to the main plot. Some should only be available in far away sectors and are used to show you oddities. Factions: There are 9 Factions total that you get to kill. Names are not yet final and are mostly based off their archetypes. Regions in the game are controlled by different factions and as you leave the initial zone out to explore you'll meet them. Some of them are harder to find than others, the Mining Guild for example has a pretty decent coverage across multiple sectors, the Empire is mostly centered around their dominion, Independents are everywhere, the Blood Tribes live far away from the initial area, and so on. Empire:  The main enemy faction. There are plenty of self-titled Empires in the Sector, but our main faction gained traction after it eliminated 8 Protectors in a single sweep and with that obtained allegiance of a sizable part of the sector, thus becoming the largest entity known. You're the only one that escaped. Aesthetics: I want empire ships to have lots of wings with a galvanized plate look. Otherwise, most of the ships you've seen so far are what I have in mind for the Empire. The initial player ship has a bit of an Empire look, although it uses a custom algorithm. Ships Stats: Standard Ships. Balanced offense and defense. They're the reference to which the other ships are compared. Independents:  Umbrella term for all other factions that are currently not controlled by the Empire, that don't get to have their own names referenced by you. You're too cool to care about them. Most of them are not very fond of you either. Aesthetics: Some bulkier, blockier ships, similar to the ships generated right now. An interesting feature of the independents is that, since they're different backwater groups, they can have different semi-randomized color schemes that change depending on where you are. Ships Stats: Slightly lower defenses, slightly more traits. Mining Guild:  Once an independent organization that provided services for all folks, the Mining Guild has pledged their loyalty to the Empire and has cut transactions with the other factions. The Mining Guild is a huge behemoth of an organization with their own shipyards and defenses, and they made their wealth by being the pioneers in exploring the sector, mapping the richest areas and taking control of them. Because the Mining Guild started with heavy investments in exploration and long-distance travel, their ships have some of the highest jump range. Despite the name, the Mining Guild is a military powerhouse that disguises itself as a (until now) neutral entrepreneurship to avoid conflicts. This way, they've managed to secure more and more systems and build an impressive army while the other factions have continued culling themselves for the past centuries. Aesthetics: Bright Yellow bulky parts like real-like mining equipment. Lots of tanks of fuel for the extended operations. Less aerodynamic-looking ships. Ship Stats: Very similar to reference, slightly more energy and less speed. Junk Gangs:  Smaller factions that usually engage in smaller skirmishes with the other major groups to steal stuff. Junk Gangs are notorious for favoring living in space stations, moons and ships rather than establishing full blown colonies. Aesthetics: Because they stay extended periods of time in space, Junk Gang Ships tend to feature huge solar panels. They're called Junk Gangs because of the dirty look on their ships, not because they make their ships out of stolen junkyard parts. Which they do. Junk Gangs ship can end up featuring random parts from some of the other factions. Ship Stats: Junk Gang fighters have very similar stats to the Imperial ships, with slightly weaker armor and higher energy regeneration. Junk Gang ships, however, can also very frequently come as the Scavenger-type, which are weaker but way more energy efficient, and have greatly increased item/currency pickup range in stage. Drones:  An experiment that got out of control by a now defunct company, Drones occupy a sizable chunk of both charted and uncharted space. The consensus seems to be that they're an AI that got out of control, while some speculate that they're still to this day controlled by their original owners, or someone else. Drones seem to be able to replicate and show signs of controlling their own populational growth. They will defend their territories, but have have thus far avoided conflict and they try to keep distance from human colonies. Aesthetics: Shuma-Gorath, Protoss, the Machines from Matrix, Vel'Koz. Ship Stats: Balanced Stats, but slightly tendence to have exotic weapon mounts (most other ships have code that normalize them somewhat). They have less "protections" against wild RNG, let's put it this way. Drones are very, very rare drops because they're not supposed to be pilotable. Positronics:  A high-tech company that followed on the Mining Guild footsteps to explore the sector and eventually founded some colonies of their own. Name not final but it's not gonna be any less 80's/90's than this, so that's a placeholder until I find something equally over-the-top. Think tech company like Omnicorp/Cyberdyne. The Positronics fund technological research. They publicly hold a fair amount of settler's tools and use the technology obtained by them to further procure relics. It's unknown what their ultimate motivations are. While they initially started a company, they became self-sustaining and have closed their doors to the outside world for a few decades. It's highly suspected that they provide high-tech weapons for the Empire. Aesthetics: Positronic Ships are whiteish in color, with light cold hues. They have round shapes and parts that are not directly connected to each other, but held together by magnetism and/or magic. Ship Stats: Considerably higher shields than any other faction. The ships are slightly heavier to maneauver and bigger. Positronic ships are also much rarer to drop. Rogues  The l33t h4x0rs of the universe. The Rogues are one of the junk gangs that's notable enough to be worthy of attention. Rogues tend to intercept communications between the factions and use it to provide themselves (and sometimes other gangs) with intel. Because of that, they have acquired far more goods than one would expect. It's suspected that they have a couple of settler's tools in their possession. Their ships have some very unique technology that makes them a fast growing threat of which the other factions are starting to be wary. Aesthetics: Rogues have dark, edgy ships with some TRON-like neon green lights. Ship Stats: Rogue Ships come with a trait that allows them to leech shield while they attack. They have very high shield like Positronic ships and are slightly more nimble than other vessels, but make up for it by being extremely fragile in other aspects. Goldmob:  A coalition of sharks, lenders and financial manipulators. They're affiliated with the Empire. Their ships have been spotted and posted online multiple times, but despite their garishness they're not very public, so some treat them as a myth. Some speculate they found a planet made of gold and that's where they build their ships, some say they work behind the scenes to crash markets or to make trades between the Empire and the Independents, and some say they're just the work of a magnate who wants to see people speculating about his designs. Aesthetics: Picture ProcGen ships where the model blocks are made of parts from cars and limousines. Also they're painted Gold. Hell, they're possibly made of Gold. Ship Stats: Higher health, but slower ships. Gold is heavy! Blood Tribes  While most other factions ships are only slightly different of each other, The Blood Tribes go all-in on their gimmick. They have a bit of an "Orcs in Space" feel and have the most different ships, both aesthetic and stat-wise. They're pretty metal. Aesthetics: The ships look like they're made of wood mixed with metal plates and decorated with blades, spikes, flags, ropes and assorted ornaments. Ship Stats: No Shield Slightly Increased physical defenses (HP/Armor) Increased Melee Damage Increased AoE Damage Bigger, Slower Ships Higher Weapon Budget, Less Traits Ships bleed when hit. Both yours and the enemy's. NEXT TIME: Videos wherein I paint stuff! More artwork and a lot of talking!
|
|
#
?
Oct 25, 2017 17:37
|
|
|
I think it would be better word choice to say "Your sky is dead" instead of "The sky is dead" because the latter sounds like an empty starless sky. Interesting concepts though!
|
|
#
?
Oct 25, 2017 21:16
|
|
|
Random crazy 80s/90s tech name suggestions I pulled out of my head just now (mostly to fuel the 'throw something out and see if it sticks' mode of thought): Electromite (Electron Dynamite  )DynAccel (Dynamic Acceleration) Could also go with Acceldyne or Acedyne. Gravible (Gravity Variable ) )Also it makes thematic sense for the Blood Tribe to be out in the weird with their gimmick. 'If it bleeds we can kill it' indeed! CrazySalamander posted:I think it would be better word choice to say "Your sky is dead" instead of "The sky is dead" because the latter sounds like an empty starless sky. Interesting concepts though! Or 'That sky is dead.' EponymousMrYar fucked around with this message at 03:11 on Oct 26, 2017 |
|
#
?
Oct 25, 2017 21:45
|
|
|
CrazySalamander posted:I think it would be better word choice to say "Your sky is dead" instead of "The sky is dead" because the latter sounds like an empty starless sky. Interesting concepts though! That's what I mean. Compared to the pictures you have from Earth, you see an empty starless sky. You don't know whether you're in a really, really far away place and Earth is still business as usual, if you're in a future so distant that the stars are now extremely far apart from each other, or if the stars just... vanished. EponymousMrYar posted:Random crazy 80s/90s tech name suggestions I pulled out of my head just now (mostly to fuel the 'throw something out and see if it sticks' mode of thought): These are pretty good names. When you say taken, do you mean the other ones are actually unused?
|
|
#
?
Oct 26, 2017 00:51
|
|
|
Elentor posted:These are pretty good names. When you say taken, do you mean the other ones are actually unused? Macrotech and Particle Solutions are also taken by that metric (being the first ones I forgot to check )Electromite and Dynaccel are a bit iffy. Electromite could use a few more permutations (Tromite? Maybe. ) Acceldyne and Acedyne are fine although Acedyne might be someone's name? Gravible and Omnimite are indeed unused.
|
|
#
?
Oct 26, 2017 03:10
|
|
|
Elentor posted:That's what I mean. Compared to the pictures you have from Earth, you see an empty starless sky. You don't know whether you're in a really, really far away place and Earth is still business as usual, if you're in a future so distant that the stars are now extremely far apart from each other, or if the stars just... vanished. So people can't look up in the sky and see the other colonies? Like, there's something acting as an interstellar fog?
|
|
#
?
Oct 26, 2017 04:09
|
|
|
CrazySalamander posted:So people can't look up in the sky and see the other colonies? Like, there's something acting as an interstellar fog? You can actually see the other colonies quite easily, especially while in space. You can see some stars that are very far away as well with telescopes, but the amount of stars is a tiny fraction of the ones in the (real) observable universe. Edit: There's no Via Lactea in the background, or any concentrated cluster of stars for that matter. Elentor fucked around with this message at 05:34 on Oct 26, 2017 |
|
#
?
Oct 26, 2017 04:54
|
|
|
I'm getting a Solar Winds vibe here, and I dig it.
|
|
#
?
Oct 26, 2017 05:19
|
|
|
EponymousMrYar, I'm gonna take some of those ideas and implement them. Thanks!
|
|
#
?
Oct 27, 2017 02:49
|
|
|
Meanwhile, I've totally taken some of your ideas about organization and getting ideas down coherently for my own projects. Spreadsheets. What a novel idea 
|
|
#
?
Oct 27, 2017 03:38
|
|
|
Heads up as usual, next chapter should be coming in 2 or 3 days. I'm including a bunch of different things in it because the past week has been crazy, should include a bit more themes than usual.
|
|
#
?
Nov 6, 2017 19:04
|
|
|
Chapter 12 - Too Many Hooks Let me open this with something straight: Working on User Interface feels like a neverending story. No matter what you do, there's always something to do. It's not even that hard - it's just laborious. Makes sense, right? A huge chunk of the game is the interface since that's how the player interacts with stuff. Of course, if you're making a simple platform game then that might not be the case. In fact, the games I worked by myself in the past had fairly minimalist interfaces so it's never been an issue. Cue a procedural game with RPG elements, an inventory system, a bunch of crazy stuff on the menu. I've been wanting to have some more complete things to show, but right now I'm in the middle of a huge chain and I'm having to work on a bunch of different things that depend on each other. So let's take a look at some of my woes. From the start. Programs: We're now gonna talk about programs. Outside of both sponsored and non-sponsored YT channels dedicated to review things, I rarely see anyone saying anything about this sort of stuff. It's been a fad for a while now for programs to become subscription-based. You probably know this, but in case you don't: There's a significant amount of software that can no longer be bought. Instead, you pay a monthly/yearly subscription and gain access to it. While that's understandable since it's a much better business model from their perspective, it can also be very straining. So let's talk about which programs I'm using. I'm not gonna go in detail about which ones are subscription-based or not. This is just a list of the pieces of software, not including the OS, that I use frequently: Image Editing: Photoshop, Substance Painter 3D Modeling: Maya LT, ZBrush, World Machine Procedural Texturing: Filterforge, Substance Designer, Quixel Suite Texture Baking: xNormal, Crazybump Texture Database: Megascans Sound Editing: Audacity Music Authoring: Guitar Pro, REAPER, Native Instrument Samplers Video Capture: OBS Studio Video Editing: OpenShot Engine: Unity IDE: Visual Studio Important Stuff: Notepad, Excel Some of these are competing products which I feel like have features the other don't. I've used a ton of programs and between features, stuff crashing, price tags, ease to use, these ended up being my programs of choice. There are more programs that I'm not mentioning because they're considerably less relevant for the project at hand, but of these at least 14 are programs that I'm using very frequently. Luckily a bunch of these are free and some are just stuff for which I own old licenses. There's a lot of expenses all over though. Unity assets alone stack up nicely over time and you kinda need them. I could probably talk a lot about this alone and I probably will but once I start writing I can't shut the hell up as you can see from this chapter's size, so I'll leave it to another day. Anyways. Roadmaps: I like Gantt Charts. This is one of those things I really like that people are moving out of nowadays. I like charts and graphs and I like being able to see all the deadlines I'm missing. I think I got far enough that I should be making good estimates of release dates. This also helps me, as an independent developer, to know when I'm spending too much time on a feature and it's time to move on. "I don't this will end up in development hell" is probably something that occurred at least once in every project that ended up in development hell. So I decided to give it a shot and take a look at the project management options out there. Oh boy, everything is on the cloud right now. 8 years ago I remember having a bunch of accessible offline solutions to do this kind of stuff. They're mostly gone now! A bunch of good and useful Excel templates vanished over the past few years and were replaced with some real basic stuff that I honestly can't see anyone using. That was a bit disappointing, but eh. And being web tools means they're all also behind subscriptions, most of which are very expensive which makes sense, most of the people paying for this kind of service have a far bigger budget than I do. One of the new kids on the block is hacknplan.com. It's a Project Management tool specifically for Game Design. Cool uh? I mean, it did look pretty cool, and people talked about it on IRC a lot. The price is a lot more reasonable than the other tools, but it's still yet another subscription. I'm not gonna lie, I do miss being able to just buy my licenses. And you know, what? Timelines, Gantt Charts and Kanban boards aren't particularly necessary when I'm the only one doing stuff. In fact, we don't need anything fancy at all. I've got Excel. I believe in Excel. So I got to my first sheet:  Historically I tend to undershoot deadlines by 1-2 days. That's because I'm usually considering the time I need to do these things on a vacuum, and that's really never the case because there's really only so much glucose we can metabolize in one day. 1-2 days is not a lot when I'm doing long tasks but when I'm doing a series of small tasks I need some time to breathe. Also writing LP chapters take at least one day in general, something I've had plenty of time to learn in the FFVII LP. After reworking the sheet I figured I'd need about one extra month to do all the things I wanted, which is fine by me. Interface, more like Inyourface Let's talk a bit about the schedule. Notice that a good chunk of it is User Interface. I don't remember which dev said it, but I once read that your game only really starts coming together when you're putting real work on the interface. The reason is two-fold: 1) Unless you're making an ultra-modern or arty game with no interface, the interface makes your game feels like a game and not just a prototype. Even if it's a placeholder interface, it sort of gives you the 2) The interface hooks up to internal stuff. When said internal stuff isn't implemented, designing the interface helps you figuring out stuff that might be important sooner rather than later. If you're making Sonic, you have Rings, Lives and Score. Now the Score isn't a huge priority but coming from the arcade era where people care about high-scores, let's say you don't understand yet how little people will care about score in Sonic. So now you need to: * Art: Make the art for the interface elements. Typography, color schemes, pixel art, all of these are involved. * Code: Make sure to add the score variable to the enemies. * Design: Decide which enemies give you points, and if it's all the same. * Design: Decide the reward system for the Score. Is it an extra life? If so, we need to go back. * Design: On average, how often should the player get an extra-life? What is the density of elements that give you points? This way we can calculate how much score things will give you. * Code: Make sure there's a life system in action. * Code: Probably make sure restart/reset are working and that game variables are not leaking when the stage or the game resets. This stuff happens all the time. Not long ago someone found out some variables that aren't reset when you restart Final Fantasy VII and you can break the game with a "New Game+" thanks to that. Since we're talking about Sonic, there are palette swaps that can occur because of variables not being reset when you restart the game. * Art: Make a dying Sonic animation. * Code: Hook up that dying Sonic animation. * Code: Make sure the event system that allows for that dying animation doesn't interact weirdly with other systems. A lot of games don't do that. Which is why you can die twice simultaneously on some Sonic games, you can see the Nexus exploding twice on LoL, etc. * Code: Make a ring system, hook the ring system to Death, etc. * Code: If there isn't a collision and damage system in place to hurt you/allow you to get rings, you'll need that as well. This is pretty much huge in itself and a huge part of the game physics. * Sound: Make a dying sound effect. * Sound: Make a ring sound effect: * Sound: Make an Extra life jingle. * Art: Make a ring art if it doesn't exist yet. * Art: Make a ring collect effect. These are just 17 elements I can think of. There are way more involved. Now a bunch of these are a core part of the game so you'll have to get to them either way, but you can see how three simple interface hooks can trigger a huge chain of events. Some games are almost entirely played through the interface. Some games are just interfaces. On RPG games, the interface hooks up to a huge amount of elements from the internal combat mechanism. Since my game has such a heavy amount of RPG elements, I quickly found out that to be the case. As soon as I started working on the interface my thought was "holy moly, there's a lot of things missing". Some of which is simple stuff, like Item Icons. I just needed to write a hook for it on the database, make a few default icons, 2 minutes of code and done. And then I started to look at the things that were missing and a bunch of them are part of systems that, while well defined in my design documents, were not well defined in the code. I could keep adding things assortedly but I'd need to rewrite them later. And, well... Refactoring: There are very few things that can be quite as motivating as looking at a code and thinking "I'm the one who's gonna have to fix this later". One of the keystones of development that people very often talk about is not to fix what isn't broken, but I think there are many reserves about that when you're dealing with certain technologies. For example, memory leaks. There are so many games filled with memory leaks, and once you have a robust game filled with many different procedural systems all sorta interacting with each other, it can be a genuine pain to track from where the memory leaks are coming. In case you don't know, a memory leak is, to put it simply, when discarded memory isn't being released from the program. So if I generate, say, a procedural ship for a stage, you move on to the next stage, and the game doesn't release the older ship from memory, that leak will make the memory allocation of the game to increase over time without ever stabilizing. Eventually, it will crash. Other things are code maintainability. Right now Project SpaceProc as it's internally called has 22,800 lines of code. If I stay too long away from a class I might start forgetting how it works, so I put comments, I make variable names intuitive. In general, I try to make my code as obvious and intuitive as possible even if comments were removed. I should be able to follow it just from reading and understand what it does. So you can see how it's an issue when some of the code is just spaghetti. That can get nasty. And no matter how much attention I give to code legibility sometimes things just get messy, or the logic is spread out across multiple classes, I don't like it. So over the past two weeks I worked on a bunch of internal stuff which would make for a very brief and boring Update Log, but it involved about 5000 lines of code rewritten, a bunch of it removed, and a much cleaner code in general. Specifically: 1) A much needed refactoring of the Procedural Ship Generation. This is how it all started since you guys wanted me working on it. My first "I'd rather do more now than a lot more later" started with working on the Imperial ships. I could just do them right now, but I knew I wanted to convert my spaceships to a DNA system, so if I did them now before the conversion I'd just have to rewrite more code later. So instead I worked on the DNA system. And holy poo poo, this time the actual script code looks so much cleaner. I know people like to bash on Visual Studio's Maintainability Index but even it agrees with me. The Ship Generator went from a score of 52% maintainability to 100%. 2) My interface code was a mess. Now it's a mess that makes sense. All of the main menu is unified and there's a lot less spaghetti code around. I wanted to make an interface to visualize the ships in-game and I thought I could just write the interface for it instead of a debug class since hey, I'm gonna need to do it anyway, right? Eventually the player is gonna need to change ships. Again, it was a case of "I want to make this right and proper now because I >will< have to deal with this later if I don't". It wasn't a matter of maybe or if, it was a matter of when. The less I have to rewrite later the better. 3) The combat code was a mess. I sorta prototyped the stages because I wanted to see how combat would feel with procedural ships. I greatly enjoyed it but the combat was mostly hacked together. Luckily I have an okay experience working on combat systems. So I unified the formulas, put everything in the same place and started implementing other systems I had designed but that weren't in game. Chain of Events: This is the chain of events that resulted from my not wanting to leave things half-implemented. From start to finish: * Imperial Ship Generation * ShipGen Refactoring * Ship Combining * Shop * Interface for Equipping Ships * Debugging Ship Stats * Panels for Ship Stats * Coding in Missing Ship Stats * Refactoring Ship Stats * Refactoring Combat Which ultimately turned into the refactoring of the ship generation scripting, interface and combat as I mentioned before. There's still a bunch of stuff I might have to rework someday but they're not relevant right now and nothing I write depends on them, so there's no need to waste any more time. Renewed Roadmap: After getting a "feel" of the tasks, I think I can do a better estimate of how I'm gonna work on The Sky is Dead. Oh poo poo, this is the first time I mention it by name, right? Well there you have it, Project SpaceProc is now The Sky is Dead. So I came up with this. It's a bit of a huge text dump, but I think it's a pretty solid plan. Anselm Eickhoff, a dev who posted a long while ago about Citybound, a SimCity-like game said something about one of his latest development videos that he found, as a single game developer, better to separate the tasks monthly. I think this model works way better for his current model than it would for mine, but there are things to take from it and I think it's a good inspiration. So I split my current development in four months. The first three months I'll work on the remaining backbone of the game, then the first pre-made full playable content to test if everything is working. Afterwards there'll be two months of working on the immediate procedural algorithms for stages, with a possible second alpha release. 1) November: Stage Hub Interface & Integration 1.1) Shop 1.1.1) Basic Shop Functions 1.1.2) Add Premade Procedural Shop Stats 1.1.3) Hook Shop into Stage Spawning 1.1.4) Create Databases for Item and Weapon list presets. 1.1.5) Create Aesthetic Procedural Shop Details 1.2) Changing Ship 1.3) Changing Items 1.4) Input Management 1.5) Ship Panel Data 1.6) Item Panel Data 1.7) Star System Map 1.8) Area Panel (Simple) 1.8.1) Faction Influence in Areas 2) December: Ship Generation, Models and Ship Artwork 2.1) Refining the Imperial Ship Generation 2.2) Making the ShipGen Algorithm for other Imperial Ship Classes 2.3) Experimental: Ship Model Skins 2.4) Experimental: Ship Pre-Textured Model Parts 2.5) Experimental: Ship Procedural Textures 3) January: Preliminary Content 3.1) Making some Imperial Weapons 3.2) Making some Imperial Accessories 3.3) Item Drop System 3.4) Working on some Weapon and Item Icons 3.5) Adding Debuffs, Status Ailments in Combat 3.6) Completing Weapon Importing File Format 3.7) Completing Custom Ship Importing File Format 3.8) Tile Map Loading System 3.9) Add Layered Ship System for Turrets and Bases 4) February: Test Campaign Stage 4.1) Make the ship AIs and raw stage 4.2) Hook in active events 4.3) Create Custom artwork and sound for the events 4.4) Create Tile Map 4.5) Add in Custom Buildings and Turrets * * Possible first Alpha release.* * 5) March: Extended Content 5.1) Filling in other Imperial weapons 5.1.1) Custom Weapon Artwork 5.1.2) Custom Projectile Artworks 5.1.3) Custom Script for Bizarre Weapons 5.2) Working on the Procedural Space Map * * Possible second Alpha release. * * 6) April: Universe Generation 6.1) Importing Baseline Star-Map 6.2) Faction-Spreading Algorithms 6.3) Star Jumping and Travelling 6.4) Fill in All Biome DNA data. 6.5) Area Panel (Detailed) 6.5.1) Procedural Biome Planet Artwork (Basic) 6.6) Error Handling for Missing Factions/Content 7) Future: 7.1) Campaign Handling and Missions System 7.2) Other Menus 7.2.1) Main Menu 7.2.2) Settings Menu 7.3) Factional Ship Algorithms 7.3.1) Factional Ship Artwork 7.4) Factional Buildings 7.5) Procedural Biome Stage Generation 7.6) Procedural Biome Stage Artwork 7.7) Procedural Biome Planet Artwork (All) 7.8) Main Campaign - First Chapter 7.9) Main Campaign - The whole thing 8) Far Future: 8.1) Side Missions 8.2) Alternate Game Modes 8.3) Unlikely Online Content 8.4) Station Creation Each topic has a priority and an estimated amount of days to complete in my sheet. Stuff that I don't complete that have low priority will be moved to a backburner. Hopefully I can get the important work in time. NEXT TIME: Ships, for real! Interface Screenshots! Combat Mechanics! Elentor fucked around with this message at 23:30 on Nov 11, 2017 |
|
#
?
Nov 11, 2017 23:24
|
|
|
I love seeing updates to this thread and I am finding it really interesting. Keep up the great work!
|
|
#
?
Nov 13, 2017 04:37
|
|
|
I need to learn more about this ~600 year-old immortal who has suddenly realised that there is something fundamentally wrong with his universe. Ideally a series of 50,000 or more (please more) word novels set in this universe. I can *just* imagine that moment of looking up from an image of Earth's infinite starfield of a night sky to your own, and just quaking beneath its terrifying finity. On the whole "we don't know where the colony ship is" thing, did you ever play Freelancer? In-game lore says one of the original colony ships went missing, but it is in the game. Found it by accident once running from some pirates into a nebula. Thing was massive. Not sure why I brought this up but your post reminded me of it.
|
|
#
?
Nov 13, 2017 06:32
|
|
|
Elentor posted:Some games are almost entirely played through the interface. Some games are just interfaces. On RPG games, the interface hooks up to a huge amount of elements from the internal combat mechanism. I'm going through this just on a conceptual 'obviously I want this which means I'm going to have to have these variables and they're going to have to do this this and this' level at the moment. All of those nice intuitive things that seem like they'd be pretty simple can actually be kind of a pain. It is helping me figure out some things for combat mechanics and formulas at least!
|
|
#
?
Nov 13, 2017 07:42
|
|
|
Phrosphor posted:I love seeing updates to this thread and I am finding it really interesting. Keep up the great work! Thanks! RickVoid posted:I need to learn more about this ~600 year-old immortal who has suddenly realised that there is something fundamentally wrong with his universe. Ideally a series of 50,000 or more (please more) word novels set in this universe. Hah I was actually surprised at how positive of a reaction I had to the story! I'm hopeful that the in-game content will be good enough for people interested in the campaign. I have the beginning, middle and end planned. If all goes according to plan the end should be pretty cool. EponymousMrYar posted:I'm going through this just on a conceptual 'obviously I want this which means I'm going to have to have these variables and they're going to have to do this this and this' level at the moment. All of those nice intuitive things that seem like they'd be pretty simple can actually be kind of a pain. Yeah, I never had to show so much before. And when I look at it, even with all my backburner lists, logs and what not, I still think "man I don't want to have to keep track of what's missing" at times. I was forced to nail down the combat mechanics pretty hard.
|
|
#
?
Nov 13, 2017 16:25
|
|
|
Here's a micro-update, just to share some of the things I've been working. Ship Comparer. You can see the stats and how they, well, compare. You also get to see the ship's estimated EHP, which automatically calculates the effective health pool taking the armor, resistances, evasions and other stats in consideration. When comparing two ships, the estimated DPS will automatically pull all the highest raw DPS items from your inventory to fill in weapon slots that your old ship doesn't have enabled, this way you can compare the ships at their best, intangible stats notwithstanding. Holding Control disables this feature while comparing.  Holding Alt shows the difference in % values. Also, you don't have to directly access the shop to buy stuff, you can buy items from any inventory screen. There's a hotkey to buy the item, and a hotkey to automatically buy and equip it.  Showing that the comparer functions also work with equipment.
|
|
#
?
Nov 15, 2017 05:45
|
|
|
One last bit of a teaser: First model rotating/zooming feature I wrote. Zooming in to see the ships inside the game is pretty cool. And you can leave the ship spinning.
|
|
#
?
Nov 16, 2017 06:52
|
|
|
This is looking pretty cool! I really like it having both flat value and percentage comparisons.
|
|
#
?
Nov 17, 2017 05:18
|
|
|
Chapter 13 - Ship DNA & Imperial Fighters This Month so far: This has been a very intense month. I'm almost done with the interface stuff, but there was so much stuff to do. I also fixed so many bugs that I got to find through being able to visualize the ship stats. I think overall this was my most productive month so far. Either way, I promised I'd show ships. And I already explained last chapter how working on ships took me to the GUI. Before I show you my GUI work next chapter, we're gonna take a look at ships. The DNA System: The original Ship Generator works like this: Each algorithms has its own functions, and the functions do stuff. Each algorithm calls for the functions manually, like this: quote:EmpireFighter() { Each function in turn creates at runtime a model with a bunch of instructions, in a way that was very verbose. I mean, it's still verbose, but it was even more verbose before. Something like this: quote:AddBody() { There were 22 Instruction Types to help define what, which, where and how each part will connect and what alterations will be made to it. The DNA system came with a small rework in the verbosity of the system, but more importantly it reworked the way that the instructions are passed. Now the algorithm does not tell you what to do in which order. It instead creates a DNA sequence, and then the Ship Generator takes that DNA sequence and creates a model from it. The DNA sequence contains some chromosomes, which in turn contain genes which hold the instructions. It's a very generalized system that can be used to create and combine anything. The Ship's chromosomes are: quote:[Cockpit, Main Body, Appendages, Greeble] The cool thing is that the genes can contain, rather than the individual instructions (which they can), pointers to the individual functions that can generate the instructions. So for example, let's say that the game iterates through 3 "AddBody" functions like before, and this is in the Main Body chromosome. quote:[Main Body:] Now you can theoretically mix it with a different algorithm. And have something like quote:[EmpireFighter.AddBody(), MiningGuild.AddBody(), EmpireFighter.AddBody(), MiningGuild.AddFuelTanks()] The genes can also have extendable or replaceable instructions. Since AddBody() itself will add random values for ConnectToSide, a gene can get the final value (say, Side.Back) and force the AddBody function to use it. Thus the specific idiosyncrasies of a ship can be preserved. Still a bit verbose, but here's a sample of the code: quote:DNAGene AddAppendage() Anyway, here are some of the first ships from the first batch of Imperial Ships.  You can see they're using some wing models that the ships weren't using before. I was happy with the initial result, though there's still a lot of room for improvement. Plans for the future Besides all the other Ship Generator To-Do I've already posted, some stuff to keep in mind: Fix offset - You'll see in the video that some parts kinda float. Not a huge issue, but I'd like to fix it. Add Engines - I'm curious as to how I'm gonna integrate items with ships. For the two non-weapon slots, Generator and Defenses, it would be cool if they had 3D graphics that fit onto your ship like armor on a character. So for the engines I'm still wondering whether Add a few more instructions - In particular, the ability to cherry pick individual models from the pool and to perform more than one set of rotational instructions on them. Add more interesting color schemes to the ships. Not all ships have to look the same. I have a lot of ideas as to how to implement more interesting texture variation within the same faction which I'll try to implement next month. To me this is really important, because as much as I like each individual ship, seeing the same color schemes over and over can be a bit tiresome. Texture work is going to be a huge undertaking in on itself. Bugs: I didn't actually encounter many bugs with the DNA system overhaul, to my surprise, because the whole thing was an incredibly complex change over the existing system. I was honestly expecting it to blow up spectacularly and it was weird that it worked right out of the box. The fact that the original script when ported worked flawlessly shows that. Not gonna lie mang, it was super weird seeing it work. Code just isn't supposed to work this way. You're supposed to see things break horribly and slowly find the cause. NEXT TIME: More ships! Item Shop! Ship stats! Elentor fucked around with this message at 12:20 on Jul 31, 2020 |
|
#
?
Nov 25, 2017 08:04
|
|
|
Elentor posted:One last bit of a teaser: As an EVE Online survivor, I can confirm that ship spinning is as critical a feature as being able to compare EHP. Thanks for the update 
|
|
#
?
Nov 25, 2017 08:18
|
|
|
This is all so cool. As a programmer in spe, this is all very interesting and exciting. 
|
|
#
?
Nov 25, 2017 08:43
|
|
|
Anticheese posted:As an EVE Online survivor, I can confirm that ship spinning is as critical a feature as being able to compare EHP. Thanks for the update I honestly started coding it just for fun and then I got really invested in it. The first moment I maximized the panel and saw the ship within an in-game context it felt a lot better than I was imagining. Afterwards I did a lot of tuning to give it a satisfactory feeling. It's crazy how some small things like this kinda tie the interface together. I feel like breaking your board in Hearthstone is as part of the game as the game itself. -Anders posted:This is all so cool. As a programmer in spe, this is all very interesting and exciting. I'm glad to serve as a positive inspiration. This still is a very humbling experience to me because I still feel very clueless as to what I should or should not be doing, but everyone in IRC/Discord/Gamedev says that you pretty much never stop learning or progressing, and that it's all part of programming looking back and thinking "wtf" at the stuff you coded last year. Elentor fucked around with this message at 01:17 on Nov 26, 2017 |
|
#
?
Nov 25, 2017 13:28
|
|
|
Here's something I found recently that I'll be including in my RNG post: https://blogs.unity3d.com/2015/01/07/a-primer-on-repeatable-random-numbers/ It's a pretty good read.
|
|
#
?
Nov 26, 2017 14:17
|
|
|
Elentor posted:Here's something I found recently that I'll be including in my RNG post:
|
|
#
?
Nov 27, 2017 02:44
|
|
|
FractalSandwich posted:Great, another article going on about the theoretical pitfalls of randomness without providing a single example of how it's ever affected anything in the real world. What point is he trying to make, exactly, apart from "maybe don't manually reseed your PRNG with consecutive numbers", which seems like a pretty trivial observation? Say, for instance, you have a game world and you're using procedural heightfield. You want to know the height above sea level at a specific latitude and longitude (x, y), but you don't actually want to store that value permanently. You need to be able to do the computation height(x,y) without needing to know anything about the height anywhere other than at x and y. He's saying RNGs are a very poor tool for that sort of situation. They're fine at generating a heightfield texture from scratch that you store, but often pretty crap if you want to just statelessly evaluate the field. That's not a particularly new insight, but since people occasionally do try to use RNGs for this sort of thing it's probably a point worth repeating. I can't really speak to the quality of his xxHash function. Making a hash function is pretty easy so I've seen a few different ones over the years that have worked, and a few that have not. I can say that the quality of your hash function and how it stands up to being sliced and projected in different ways absolutely matters for the visual appearance when doing procedural anything. A poorly chosen hashing will yield immediately repeating patterns and generally look like arse.
|
|
#
?
Nov 27, 2017 05:04
|
|
|
FractalSandwich posted:Great, another article going on about the theoretical pitfalls of randomness without providing a single example of how it's ever affected anything in the real world. What point is he trying to make, exactly, apart from "maybe don't manually reseed your PRNG with consecutive numbers", which seems like a pretty trivial observation? I apologize if you found the link redundant. I think there's no single unified article on PRNG that makes complete sense and gives someone a full idea, unfortunately. It's why my post is filled with references and so many links. Even then I missed some things which others pointed out. The entire reason I started talking about PRNG was because of the stuff I ran into, though to be fair I absolutely love doing my own tests and running statistics on the quality of the solutions. Elentor fucked around with this message at 05:37 on Nov 27, 2017 |
|
#
?
Nov 27, 2017 05:30
|
|
|
Elentor posted:I apologize if you found the link redundant. I think there's no single unified article on PRNG that makes complete sense and gives someone a full idea, unfortunately. It's why my post is filled with references and so many links. Even then I missed some things which others pointed out. He does give the example of a world generated in sections that needs to be broken up to save memory, but he doesn't at all justify why, in the real world, you wouldn't just choose or generate an arbitrary large number to use as the seed for each section instead of using consecutive ones. What kind of game are you making where you don't pre-design or persist any data about these areas at all, including a single int32 to remember them by, but still want to go back to them later? FractalSandwich fucked around with this message at 07:03 on Nov 27, 2017 |
|
#
?
Nov 27, 2017 06:24
|
|
|
FractalSandwich posted:What kind of game are you making where you don't pre-design or persist any data about these areas at all, including a single int32 to remember them by, but still want to go back to them later? A lot of games that followed the Procedural Generation hype relied overly much on it, to the point where most of their pre-design was 'set up some rules and let the game build itself.' Very few of those games actually stuck to the landing and got out of Early Access hell because they had thought farther than 'procedural generate EVERYTHING!'
|
|
#
?
Nov 27, 2017 07:32
|
|
|
At this point, as soon as I get the remaining systems out of the way, I want to focus on a playable self-contained campaign first and foremost rather than infinite content exactly because of that. Diablo and Binding of Isaac comes to mind. I figure if I can make a fun playable game first everything will follow, rather than if I make procedural systems everything will follow. Especially since the most important procedural system I needed is almost done. Elentor fucked around with this message at 08:23 on Nov 27, 2017 |
|
#
?
Nov 27, 2017 08:17
|
|
|
Chapter 14 - Spaceship Bonanza, Part I So yeah, this chapter. The next few chapters deal with the schedule and the interface (finally, I swear!), before I finally get on to wrapping up the spaceship generator. I haven't gotten around to it yet, but I will very soon, which makes this the last chapter wherein I talk about the current iteration of the generator. It might be that it won't change much afterwards, or it might change a lot, it will depend on how much progress I can pack up in the upcoming 20-30 days. So what I'm gonna do here is - I baked dozens of ships like last time. And I'll talk about them this time via text. Let's see some spaceships and have some fun going over the minutiae of the generator. One thing - the first time I saw these ships and recorded the video, it was a bit of a blind run. It's too bad that the audio was crap because it'd be an interesting reaction video. Anyway, let's go! Ship #1   Right in the first ship of the batch we see a somewhat unfortunate cockpit placement. I actually don't mind it much. Ship #2   But this is something that happens from time to time. It's not relevant in the top-down view and some ships, like this, look fine. These ships would fit well in an EVE Online universe where you see your ship via a camera, and sci-fi universes where windows are just structural weaknesses. But it would be an issue if this were a first person dogfighter. Solving the cockpit problem can be doable a couple of ways but the most obvious ones are heavy (like a boolean exclusion area). There are other ways that I might visit in the far, far future (maybe adding a function that checks if an object occludes with an area on top of the cockpit and, if so, find another connector). I'd rather, in the meanwhile, focus on less brute-force solutions that rely on better algorithms. Ship #3   There's not a lot of cockpit variation (I think there are 15 or so cockpits right now) and some lines of code to avoid clutter near them already, so a lot of the detail goes to the sides and back of the ship. Ship #4   Not all cockpit details are bad, though. That little greeble on top is adorable. Ship #5    That back there is another really interesting formation. It kinda looks like a custom-designed engine, which is something that's happening organically in a lot of these ships, so it makes it really hard for me to decide how I'm gonna handle the actual engines. Ship #6  This ship kinda sucks but at least it's called Carbonated Energy. Ship #7    This ship looks fantastic.   It's one of those designs I'll totally steal and use it as a reference to draw a ship someday. Maybe for this game even. Ship #8   This ship is also absolutely fantastic. It looks like a better version of the Underground Cooperative. It's one of my favorite ships.   That cylinder on the back with some randomized details remind me a lot of Corellian Ships. I was so happy to find out that stuff like this could pop up. This is one of those ships that make me want to fly it in a big space simulator. Ship #9   This ship on the other hand screams Shmup. This ship looks so cool.   That bug you see with the floating doodad is something that happens with overly detailed ships. I think it has to do with the greeble running out of spawn points and staying on the origin point. This is something I'll look into. Ship #10   The level of symmetry on this ship is amazing, but that flat concrete block above and below the cockpit annoys me. I need to change that model.  That model is literally just a box. When I made it I was thinking of adding very simple geometric forms that could be used upon which for other objects to sit. But after thousands of ships seen, most of the time it just ends up as this big appendage hanging somewhere as an eyesore. Even then this ship looks pretty cool. Ship #11  Meh. Ship #12   One of the weirder designs. Ship #13  This ship is interesting because of the slightly tilted modules on the back. That's a bit of an uncommon occurrence which I hope to fix in the future. There's not enough angular variation of the module placement right now. Ship #14  One of the really bad designs. Showcases how some of these blocks need rework. Ship #15  This is a fun design. The two claws next to the cockpit remind me of those Egyptian Beetle Symbols, since they're usually coupled with large wings to the sides as well. Ship #16  Okay.  Well, that's something different for sure.  Ship #17  Rock Magnets. How do they work?  All jokes aside, it's a busy but neat design. Ship #18   Now we're talking. We're going from a bunch of meh designs from early on to really good stuff.   I don't know what else to say about it. This is a great design. Makes me want to do an HD remaster of these model parts to see how this ship would look like when properly rendered with good graphics. It makes me really wanna fly it.  Also as a happy coincidence, this ship has nice weapon mounts. It shoots from the two wings simultaneously, even though they're not symmetrical. A happy accident. NEXT TIME: More ships! Elentor fucked around with this message at 12:19 on Jul 31, 2020 |
|
#
?
Dec 7, 2017 22:26
|
|
|
Chapter 15 - Spaceship Bonanza, Part II Continuing our gallery of virtual spacecrafts. Ship #19  Some ships really just need a credit card. Ship #20    This ship is called Convoluted Dynamite.   It's great.   I mean, I do tend to prefer more traditional designs, but this is one of those models that really stuck with me for some reason. This ship has a lot of personality. I like it. Ship #21  The gun gray material seen here isn't particularly common. This ship has a lot of statistical oddities in its generation, like the gigantic greeble, but I think the end result looks good enough that it gives me ideas to improve the generator. Ship #22  I hope you like wings. Ship #23  I loved this ship from the get-go.  This round part here is another example of something that's a happy accident. It's a bunch of different rare parts appropriately juxtaposed. It's a great design that, once again, could be much improved by that huge chunk of nothing being removed. But all in due time. Ship #24  The Hatch Controller looks inconspicuous from above, but it has these pretty crazy patterns going on. This is a nice case of symmetry groups in action. Ship #25  This ship looks fine from above...  But I think this is the worst case scenario of the generator being crazy. It's bound to happen and it's fine that extreme cases such as this one are rare, but holy molly did it go haywire. Ship #26  The Industrial Gulch on the other hand looks super cute.  And it has very nice weapon mounts as well. A great design all around. Ship #27  Nothing quite like a ship with a good hairdo. Ship #28  This ship is not quite right. Ship #29   That cockpit is hiding because it knows what lies in the depths of the space. It has seen things. Ship #30  This ship looks genuinely mad.  Like, angry for real. It's a good design, even if it doesn't make any sense whatsoever. But it looks awesome. Ship #31  Cute bomber-like ship. Ship #32  I present to you guys, a fan that got stuck.  No joke, I actually wondered about moving parts for ships after seeing this. It would be a bit hard to implement in the current architecture but who knows, it could look glorious. Ship #33  The return of the blocked cockpit. Ship #34   You know what? I like this ship. It suffers from a case of "overly elongated block that really could use more details" connecting to the cockpit, but if I fix that the rest of it looks fantastic. Ship #35  Last, but not least - I think this is the best ship generated so far.  This is the kind of result that I wanted, but I didn't want to overfit the generator. It could produce something like this by hand if I forcefully hand-picked the parts and made it tighter. I wanted to generalize it so that it could generate something wacky, but also this.  But I honestly didn't think it was ready to generate this. So when I saw this ship I was really surprised. It easily looks like something I could put on the cover, or have it as the main ship of the game, as it is. I thought it'd take me a lot more iterations to get something so clean. So yeah, I'm really happy with it. In Conclusion Well, that's it! I didn't cover all the ships on the video, especially the Spaceship Bonanza 3, so if you still want to see some more, feel free to take a look at them. They're very quick (6-7 minutes) and you can see the ships in a lot more angles. Do you have any suggestions for stuff for me to implement in the ship generator? Like features, details, model parts, texture ideas, feel free to suggest anything because the time is now. As soon as I wrap up the current GUI content I'll be working for a solid month on it testing things out and see what sticks. NEXT TIME: Words! Systems! Stuff that I did during November!
|
|
#
?
Dec 9, 2017 15:03
|
|
|
I'd like to maybe see some colour randomization, just to see what garish combinations the generator could come up with. And who knows, you might stumble into a nice new colour scheme for one of the factions!
|
|
#
?
Dec 9, 2017 16:40
|
|
|
biosterous posted:I'd like to maybe see some colour randomization, just to see what garish combinations the generator could come up with. And who knows, you might stumble into a nice new colour scheme for one of the factions! At least on a conceptual level. You'd probably get a whole lot of crazy eyesores but some of them could be just crazy enough to work!
|
|
#
?
Dec 9, 2017 23:51
|
|
|
Elentor posted:Ship #16 I actually kinda like this weird brick. If nothing else it might make a good starting point for the "mini-boss-capital ship" type enemies you tend to see in this style of game.
|
|
#
?
Dec 10, 2017 03:16
|
|
|
Yeah that one looks like some kind of corvette or something, I'd keep it.
|
|
#
?
Dec 10, 2017 08:41
|
|
|
MShadowy posted:I actually kinda like this weird brick. If nothing else it might make a good starting point for the "mini-boss-capital ship" type enemies you tend to see in this style of game. Dreadwroth posted:Yeah that one looks like some kind of corvette or something, I'd keep it. I think these algorithms are still gonna change so much that except for the Spoony Goon, none of these specific ships are likely to exist by the time we reach Alpha. However I'll try to model the Corvette generator in such a way that blockier ships like this one can pop up. I didn't consider it as a base for capital ships so thanks for the feedback. biosterous posted:I'd like to maybe see some colour randomization, just to see what garish combinations the generator could come up with. And who knows, you might stumble into a nice new colour scheme for one of the factions! Yeah I don't like how uniform the colors look right now. I have a few plans that involve mixing multiple randomized pre-baked textures (almost guaranteed that it should work) and a possible way to add fixed per-model baked textures. The later might prove too costly, either memory-wise or loading-wise. If it adds less than 1ms per ship I'll do it. Other ideas involve adding more variable color schemes per ship, and a bunch of other crap to spice it up. We'll see how it goes. I don't like how samey they look because of the flat texture and similar colors. There's already some color variation going on but they're oh so very subtle. But let's take a look at the existing functionality. Right now the ships have four colors. They're all based on the vertex coloration of the ship, as I've explained somewhere in this long rear end thread. So there's a color for R,G,B and a color for RGB=0 which is reserved for the cockpit (so the game knows what to dye black). quote:v4A = new Vector4( For almost every operation in the game I use HSV rather than RGB. For whomever is not familiar, HSV stands for Hue, Saturation and Value. H means stuff like Red, Yellow, and so on, and ranges from 0f to 360f (as in degrees, because it treats colors as a color wheel, since colors eventually cycle back to the origin. So 0f = 360f = Red. Saturation means how intense the color is and ranges from 0 to 1. A value of 0 means that there's no color tint, and thus H is irrelevant for the color at hand since the color is going to be a pure grey. A value of 1 means the color at its strongest. V stands for Value, and stands for how bright the color is, where 0 is black and 1 means the color will be at its strongest. In HSV, a high saturation means that the V will refer to how strong the color is (so a red will be a strong red). There's also HSL, where L stands for Lightness, in which case a L of 1 will always mean the color is white. Wikipedia as usual has a nice article about it. I choose HSV because it suits what I'm trying to do better. The Offset function is an extension I made for the random class that takes an original value and offsets it by -/+ a value. So if I want a red (0 degrees) that can range from any color between magenta (300f) and yellow (60f), like this:  I can do a random.Offset(0f, 60f). This would be equal to the more common function random.Range(-60f, 60f). The reason I wrote an Offset function is that it's more intuitive, this way I can simply put the point of origin (like, say, a yellow) and how much it will deviate from it. Offset01 works the same way, but clamps the value between 0 and 1. What that piece of code is doing is taking a dark grey and giving it a slight greenish tint. It has a range a bit like this:  Which is, admittedly, a bit too conservative. But I find that playing with colors using the HSV range instead of RGB gives a lot of more leeway to making things that may or may not look garish, on purpose. quote:ShipColor shipColorA = new ShipColor(TextureOps.HSVtoColor(v4A)); TextureOps is my custom script for, well, Texture Operations. It contains blending modes from Photoshop, Contrast and Brightness with the options to use the same algorithms as Photoshop and Filter Forge so I can replicate them (and I'd like to thank the Filter Forge crew for providing them to me via email support, as it made my life a lot easier. Some of these functions would have been a pain to reverse-engineer). In this case, it's using TextureOps to convert HSV to a RGB color. Unity also has a HSVtoRGB function but mine uses 4 values which is preserved in the alpha channel, so it's more like HSVA to RGBA. Also, it interprets negative H values as wrapping back to violet and so on. The Alpha being passed is never used in the color itself - instead it's a holder for how dominant that color is going to be when mixing algorithms. EponymousMrYar posted:At least on a conceptual level. You'd probably get a whole lot of crazy eyesores but some of them could be just crazy enough to work! Curiously enough I've been refreshing my memory on color theory, reading some of the old books I had. I've been trying to come up with a procedural color scheme tool and in the process I >think< I can improve a bit on the current colors. Elentor fucked around with this message at 18:54 on Dec 10, 2017 |
|
#
?
Dec 10, 2017 18:45
|
|
|
|
| # ? Apr 19, 2024 06:00 |
|
|
While working on the weapons I'm wondering if I should try to add or not weapon mount graphics to the ships. This is a bit of a weird issue. I'm gonna be doing weapon models for the icons and artworks anyway. A lot of Shmups do that, but don't end up using the graphics anywhere else. Implementing it wouldn't be hard. On the other hand, it could look very weird in-game with the guns being relatively small to the screen size. Also most of the guns are aligned in the XZ plane so they cannot shoot upwards/downwards (after all the gameplay is 2D). Some weapon mounts however would not match the particle position.
|
|
#
?
Dec 11, 2017 21:55
|
|