Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«13 »
  • Post
  • Reply
Elentor
Dec 14, 2004





Hi there, and welcome to a slightly different Let's Play.

In this thread we're going to talk about not just Games, but Game Development. A huge part of the focus will be ProcGen and Art, but we'll cover other topics as well. In the process, you'll see some of my projects, tech-demos, and whatever miscellania I see fit to throw.

This thread started with my Procedural Generation demos in Unity, but it's hard to isolate GameDev to a single topic, so over the first year we ended up covering a myriad of subjects and are broadening the theme up a little.


Procedural Generation? Unity?

Procedural Generation, or ProcGen for short, is the concept of creating content from a set of instructions (or procedures). It's an umbrella term that encompasses a lot of different things, but in games it has been used as a synonym for randomly generating seemingly infinite content. Minecraft, Terraria, Starbound, No Man's Sky, Diablo, Binding of Isaac are some popular ProcGen games. The worlds generated in Minecraft, Terraria and NMS are examples of procedural generation. Basically - making stuff out of math.

Unity is a game engine. Some famous games made in Unity that you might have heard of include Hearthstone, Superhot, I Am Setsuna, Pokémon GO, Pillars of Eternity.

Writing ProcGen snippets is something that I really enjoy doing. So I've decided to do something slightly different.


What is this thread about?

I posted some of my procedural content some months ago in the Making Games Megathread. It all started with a program I wrote to procedurally generate starship models. It's something that had been on my head for a few years that I thought would be neat, if anything to be able to find cool silhouettes for my own hand-drawn stuff. After posting it in a couple places the general consensus was that I should use it on my own instead of selling the tool.

I thought how cool would it be to play a shmup where you find/buy procedural, sometimes oddly-shaped ships, and play with them. So a huge chunk of this thread is dedicated to making a prototype Shmup. In addition, I'll be posting about general GameDev, as well as past and current projects of smaller scopes. Some are finished, some are not, some are ongoing. I intend to take you for a ride as we cover Game Development. Instead of a traditional Let's Play where I play through a game, I'll follow the structure of a SSLP to post about developing said projects.

I thought it'd be neat to talk about the dev. process and write about it in a way that is entertaining to a non-developer. I don't consider myself an expert at anything, so I'm prone to making mistakes, but I'll try to cover a little bit of everything as we go.


What am I working on?

* Procedural Spaceship Generator - Finished. Covered almost entirely from start to finish if you include all my SA posts. Goes all the way up to Chapter 21. If you want a sum-up, you can read the post-mortem on Reddit here.
* ProcGen Shmup - Got all the backend tech done. The bulk of the thread covers this. Currently on hiatus due to needing extensive artwork which I'm postponing due to an arm injury.
* Basic Turn-Based JRPG - Early stages. Something far less graphic-intensive using the extensive Shmup backend I built.


Your feedback:

To err is human, so your feedback, criticism, ideas, are all welcome. Over the course of my last LP I read a lot of constructive feedback. I imagine a lot of people reading this thread have varying degrees of game development understanding and some things might fly over their head. If you didn't understand something, by all means, feel free to ask. I'll try to make everything as easy to understand as possible but I might miss some things. Do not be afraid to point out when I do. Feel free to ask anything, and I'll do my best to answer.


So how long is the LP gonna last?

As for the thread - I don't know how long this whole thing will take. A few of the thread content won't be in-sync with what I'm developing, but if you followed my previous Let's Play you know I'm unlikely to get off the train we're in, even if said train slows down considerably. I've planned a decent amount of content beforehand so that I can guarantee you at least a good 20 chapters.

Whether the end result is good or not, this thread will document some of it. Whether I make an unfun bug-infested prototype that crashes and burns, a complete and fun game, or something in-between, you'll have followed some of the thought process. And if anything, I hope my posts and crude concept art can entertain you.


So without further ado, let's start shall we?


Content:

Chapter 1 - The Pitch
Chapter 2 - Planning
Chapter 3 - The Ship Generator, Part I
Chapter 4 - The Ship Generator, Part II
Chapter 5 - The Ship Generator, Part III
Chapter 6 - Delving into RNGs
Chapter 7 - What is in a Name?
Chapter 8 - Hub Interface
Chapter 9 - Ship AI, Part I
Chapter 10 - Ship AI, Part II
Chapter 11 - Factions and Story
Chapter 12 - Too Many Hooks
Chapter 13 - Ship DNA & Imperial Fighters
Chapter 14 - Spaceship Bonanza, Part I
Chapter 15 - Spaceship Bonanza, Part II
Chapter 16 - Hard Work & Some Stats
Chapter 17 - Facing the Interface, Part I
Chapter 18 - Facing the Interface, Part II
Chapter 19 - Improving the ShipGen: Collisions
Chapter 20 - Improving the ShipGen: Greeble
Chapter 21 - Improving the ShipGen: Model Replacement
Chapter 22 - Sketchbook
Chapter 23 - Bugs, Testing and Oversights
Chapter 24 - A Bunch of Stuff
Chapter 25 - Faction Weaponry: Independents
Bonus Chapter - Weapon Ideas, Part I
Bonus Chapter - What I've been up to and personal bits
Bonus Chapter - Making of a Rock
Chapter 26 - Tilesets, Part I
Chapter 27 - An Unexpected Milestone
Chapter 28 - Inner Universe, Part I
Chapter 29 - Inner Universe, Part II
Chapter 30 - Inner Universe, Part III
Bonus Chapter - Overhead and Upcoming Content
Chapter 31 - Real-Time Rendering, Part I
Chapter 32 - Real-Time Rendering, Part II
Chapter 33 - Real-Time Rendering, Part III
Bonus Chapter - The Elephant in the Room, Part I
Bonus Chapter - The Elephant in the Room, Part II
Chapter 34 - I think I accidentally made an RPG, Part I
Chapter 35 - Real-Time Rendering, Part IV
Chapter 36 - Real-Time Rendering, Part V
Bonus Chapter - On Life
Chapter 37 - Real-Time Rendering, Part VI


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Content Per Subject:


Ship ProcGen:
It's a program that generates spaceships, automatically. This is where it all started.

Post Mortem: https://www.reddit.com/r/Unity3D/co...ation_in_unity/
Chapter 3 - The Ship Generator, Part I
Chapter 4 - The Ship Generator, Part II
Chapter 5 - The Ship Generator, Part III
Chapter 7 - What is in a Name?
Chapter 13 - Ship DNA & Imperial Fighters
Chapter 14 - Spaceship Bonanza, Part I
Chapter 15 - Spaceship Bonanza, Part II
Chapter 19 - Improving the ShipGen: Collisions
Chapter 20 - Improving the ShipGen: Greeble
Chapter 21 - Improving the ShipGen: Model Replacement
Bonus Chapter - On Life


Assorted ProcGen Stuff:
ProcGen-themed chapters that are not related to the Ship Generator.

Chapter 7 - What is in a Name?
Chapter 28 - Inner Universe, Part I
Chapter 29 - Inner Universe, Part II
Chapter 30 - Inner Universe, Part III


Shmup:
Wherein I talk about my Shmup Project: The Sky is Dead.

Chapter 1 - The Pitch
Chapter 2 - Planning
Chapter 3 - The Ship Generator, Part I
Chapter 4 - The Ship Generator, Part II
Chapter 5 - The Ship Generator, Part III
Chapter 6 - Delving into RNGs
Chapter 7 - What is in a Name?
Chapter 8 - Hub Interface
Chapter 9 - Ship AI, Part I
Chapter 10 - Ship AI, Part II
Chapter 11 - Factions and Story
Chapter 12 - Too Many Hooks
Chapter 13 - Ship DNA & Imperial Fighters
Chapter 14 - Spaceship Bonanza, Part I
Chapter 15 - Spaceship Bonanza, Part II
Chapter 16 - Hard Work & Some Stats
Chapter 17 - Facing the Interface, Part I
Chapter 18 - Facing the Interface, Part II
Chapter 19 - Improving the ShipGen: Collisions
Chapter 20 - Improving the ShipGen: Greeble
Chapter 21 - Improving the ShipGen: Model Replacement
Chapter 22 - Sketchbook
Chapter 23 - Bugs, Testing and Oversights
Chapter 24 - A Bunch of Stuff
Chapter 25 - Faction Weaponry: Independents
Bonus Chapter - Weapon Ideas, Part I
Chapter 27 - An Unexpected Milestone
Chapter 28 - Inner Universe, Part I
Chapter 29 - Inner Universe, Part II
Chapter 30 - Inner Universe, Part III


Game Rendering:
Wherein I talk about Real-Time Rendering and all things behind the scenes that make pixels appear in your favorite video-games. I usually use WoW, Final Fantasies Path of Exile, 16-bit and 32-bit era games as references.

Chapter 31 - Real-Time Rendering, Part I
Chapter 32 - Real-Time Rendering, Part II
Chapter 33 - Real-Time Rendering, Part III
Bonus Chapter - Making of a Rock
Bonus Chapter - The Elephant in the Room, Part I
Bonus Chapter - The Elephant in the Room, Part II
Chapter 35 - Real-Time Rendering, Part IV
Chapter 36 - Real-Time Rendering, Part V
Chapter 37 - Real-Time Rendering, Part VI

Elentor fucked around with this message at Oct 20, 2018 around 23:51

Adbot
ADBOT LOVES YOU

Elentor
Dec 14, 2004



Chapter 1 - The Pitch

While everything started with a pet project, and the ProcGen systems are a huge part of the game, I think it's more important to talk first about what the game is about, and my vision of how it's gonna be played.

I've worked on multiple procedural systems in the past as a Technical Artist, though they've all been mostly graphical and not related to gameplay. This is going to be the first time I make an actual procgen game. So I'm sailing blind across a few waters. So the first thing I did was to work on a few design documents and a not so few spreadsheets. After a few weeks of brainstorming, I came up with some ideas that I really liked and decided that I was ready to start the project.


The Basics:

You enter a stage and kills stuff. After the stage, you get back to the hub (think Tyrian), equip/buy items/ships with points you made from killing enemies, and select the next stage. Rinse and repeat. Stages last around 150 seconds.




The Details:

You start the game with a pre-determined, fixed ship. Afterwards you get to change your ship either by picking up as an item drop from a dead ship in a stage, acquiring it from the campaign, or buying it in a shop. Some stages have shops, others don't. They usually sell wares related to the faction that owns the quadrant you're in.

There are multiple factions. The factions control different parts of the universe. Each faction has its own ship gen algorithm and ship stats, as well as loot table for different weapons. The idea is that you feel super excited when you get the chance to engage in a planet controlled by an uncommon faction because who knows? You might get one of the cool ships from that faction.

There are four different types of weapons (Primary, Secondary, Active and Passive). Primary Weapons deal a lot of damage but cost energy, Secondary Weapons deal less damage but don't cost energy. Active Weapons have long cooldowns/charges and Passive Weapons are like trinkets that do their own thing. You can have up to two of each equipped, up to 8 slots. Which slots are available vary from ship to ship.

Customization in general should be pretty fun to implement. I have various ideas that range from merging ships, to having your (and other players') highest level Ironman ships being available from rare special vendors. Who knows if I'll get to them, but the possibilities are pretty great.


The Campaign:

The campaign mode places you at the same location with the same pre-determined items every time you start a game, and things branch from there. The universe is procedurally generated and split like this:

100x100 Sectors > 10x10 Star Systems > 10x10 Quadrants for a total of 100 million quadrants.

At any given moment you're in a quadrant, and the quadrant settings (like if it's a planet or deep space, and what is the planet's biome) yield a pool of possible maps that will be used to generate the stage you'll play.

After each stage, you get to pick the next area to move from a pool of 2-4 choices. The universe has a fixed seed, so over time you'll get to know a few famliar planets. I think it'd be cool to unlock different starting points over time though. Getting out of a Star System should be easy, but moving out of the initial sector should take some time. Because of the fixed seed, I'll play with the seeding a lot until I get an interesting, cherry-picked starting sector, and try to organically build some lore around it thinking of how the initial explorers would have approached it.

At any given time you're following a Campaign Storyline. These shouldn't prevent you from doing freeform exploration if you want to grind, explore or do whatever, but they'll give you access to certain landmarks and campaign-related stages. There's the main campaign storyline and other campaigns that you randomly unlock as you explore the universe. Think of it as an anthology of sorts.


The Setting:

I'll talk more about the game story in a future update, but for now, some key elements:

* The game is not hard sci-fi and has elements of fantasy. Both staples like sound in space (no one is gonna complain about that in a Shmup, right?) to far more surrealistic elements. These range from simple things like Futurama's "you can't go faster than the speed of light so we increased the speed of light" to the insane stuff in Rick and Morty.
* The game is set in the far future, in a different galaxy being colonized by the survivors of a generation ship.
* Outside of the arrival point, the laws of physics seem to grow increasingly weirder. It's generally accepted in-universe that the laws of physics are not universal and, as such, it's extremely dangerous to travel very far from the local cluster of stars.
* The surviving generation of the generation ship is immortal (as in they don't age), and no one knows why. You're one of the immortal pilots who belong to that group that arrived centuries ago. There are very few survivors - three centuries, gang conflicts and interplanetary wars gives you plenty of time and ways to die.
* The story involves you finding out about the space oddities and what terrible secrets are hidden in the uncharted areas. Here there be dragons.


RPG Elements:

There are some RPG elements. Your ship and your items have levels that are based on the level and threat of the stages you're playing. Not all levels are made equal - Places can have higher threat than usual for any given level, in exchange of possibly better rewards. There's no character level or experience bar, though.

I'm still thinking of possible account-wide unlocks, like the ones in Binding of Isaac. The two features that I have in mind are unlocking different start places and have old ships appearing for sale, but I'll see if I can come up with more stuff.


Randomness:

I don't like how random parameters in certain game systems are equidistributed - I think it's satisfying for an artist to make sure that everyone will see everything you make, but that makes for a very boring game. Imagine that every planet has a random 24-bit RGB value that affects its terrain color and a random RGB value for its sky color. That yields a total of 281 trillion combinations, which ultimately is a big but meaningless number - as soon as you travel through 20 or so planets you'll strongly suspect that the color combinations are entirely random. Once you figure out the pattern, the sensation of discovery is not as strong because you understand that these 281 trillion combinations are part of the same system. The planet that is entirely pitch black will probably be amusing, but the vast majority will be more of the same.

Almost nothing the project is equidistributed, everything has weights manually placed that I think are important to give the player a sense of discovery and curiosity.

The main trap in this system is that players might not be aware that there is stuff to discover. I'm not making an exploration game primarily, my goal is to have the core gameplay loop interesting enough for the player to want to play, but it would still be interesting to avoid that trap. This probably involves forcing some kind of variation early on, to make the first stages interesting.


Exoticity:

As you leave your starting bubble, the average level of exoticity increases.

Exoticity is a value that affects the weirdness of things. It's one of the elements that I thought when designing the game that would spice things up. Exoticity is only loosely tied up with the difficulty of a quadrant so it's possible to visit exotic places early on or play the endgame in non-exotic areas.

To bring back the planet metaphor and how exoticity works - if you tie up exoticity to, say, a lush forest planet, then most forest planets are gonna be fairly green, with parameters that vary, but that yield a biome that should be recognizable. You might see a rare lush forest that has almost no water in the surface for example. But in a planet with high exoticity, some of the forest is glowy neon pink and the ocean is magma. Things become more surreal and less physically likely as the exoticity increases.



The first immediate integration with the gameplay are the loot tables. Weapons drop based on their rarity, their base level and their exoticity. Weapons dropped cale with the enemy level, but they have a base level range which makes some weapons more common early on, and although they scale they're not normalized. Some weapons are better than others by design.



Some weapons, however, can only drop after a certain exoticity threshold. So while the first weapons are the typical proton emitter, pulse blaster and [insert generic name here], finding an exotic quadrant can yield you stuff like the container grabber - a giant hand that grabs the nearest enemy ship and flails it around dealing collision damage. Or Pickaxe Rotors.

Basically, some really weird poo poo.




And with that, we conclude this update.


NEXT TIME:

Expectations! Planning! Details about Pre-Production!

Elentor fucked around with this message at Nov 1, 2017 around 11:51

Kanthulhu
Apr 8, 2009
NO ONE SPOIL GAME OF THRONES FOR ME!

IF SOMEONE TELLS ME THAT OBERYN MARTELL AND THE MOUNTAIN DIE THIS SEASON, I'M GOING TO BE PISSED.

BUT NOT HALF AS PISSED AS I'D BE IF SOMEONE WERE TO SPOIL VARYS KILLING A LANISTER!!!


(Dany shits in a field)

cool

WombatCyborg
Apr 2, 2011


Definitely curious to see how this goes, I'd like the chance to have a high level view of how you build a game, might give me the direction and motivation to start on some of my passion projects. How are you planning on distributing the game once it's finished, if at all?

AweStriker
Oct 6, 2014



I love this idea and can't wait to see where you're going to take it.

I suppose you've also got a feedback and ideation mechanism too, depending on how active this thread intends to be with it.

Monk E
May 19, 2009


This is neat never been a huge fan of generated content but I've never seen it applied to a shump before and as a fan of the genre it's cool to see someone try something new with it and being able to see its construction is a nice bonus.

TooMuchAbstraction
Oct 14, 2012

My fingers are set to vibrate


Anyone interested in this thread may also be interested in the Making Games Megathread, which is a general "chat about what we're doing in this space" kind of thread.

EagerSleeper
Feb 3, 2010

by R. Guyovich


I love procedurally generated games so I'm looking forward to this.

Elentor
Dec 14, 2004



WombatCyborg posted:

Definitely curious to see how this goes, I'd like the chance to have a high level view of how you build a game, might give me the direction and motivation to start on some of my passion projects. How are you planning on distributing the game once it's finished, if at all?

If I ever get to the end of it, Steam Direct. It's relatively cheap and simple.

Monk E posted:

This is neat never been a huge fan of generated content but I've never seen it applied to a shump before and as a fan of the genre it's cool to see someone try something new with it and being able to see its construction is a nice bonus.

Yeah, as far as I know there hasn't been a procgen shmup yet. Again, I might be wrong, but I haven't heard of any.

TooMuchAbstraction posted:

Anyone interested in this thread may also be interested in the Making Games Megathread, which is a general "chat about what we're doing in this space" kind of thread.

Seconding that, the Making Games Megathread is great.


AweStriker posted:

I love this idea and can't wait to see where you're going to take it.

I suppose you've also got a feedback and ideation mechanism too, depending on how active this thread intends to be with it.

I have a pretty solid vision at this point of what I want to do and how I am going to do it, but people can always point out better ways, criticize my current solution, or simply downright provide feedback that I don't think should ever be ignored, like "this isn't fun" after play-testing. The priorities are:

1) Making something fun
2) Preserving the implementation of the current mechanics
3) Preserving the planning of the overall game mechanics
4) Preserving the original, high level vision

Which means I'll try to do, to the extent of my ability, to make something fun within the current game design and will be willing to accommodate changes that affect the low level experience (like bugs, interface issues, some quality of life changes). If that doesn't yield satisfactory results I'm open to fine-tuning mechanics based on feedback - things like damage tuning, frequency of enemy spawns, game formulas in general. This is almost guaranteed to happen, because I've never seen an alpha or beta without constant iterations on game mechanics, so I consider these very essential feedbacks once I have something out there for people to test.

To a lesser extent, I'll see if I should make changes to how these systems work together. I'll prioritize the more immediate issues before changing that level of game design. With that said, I'm always open to ideas and suggestions.

Last, if everything else fails, I'll try to readjust the entire concept. If for example the campaign is fun and great but people actually unanimously hate the procgen elements, I might turn it into a more standard Shmup with a fixed single-player campaign. Or, if the opposite happens, I might turn the game into something more free-form and give the player more exploratory options.

Elentor fucked around with this message at Aug 14, 2017 around 20:30

CJacobs
Apr 17, 2011

Be mindful of
psychological rejection.


Fascinating idea, definitely going to be following this thread and eventually following this game!

TheGreatEvilKing
Mar 28, 2016



This looks good. I look forward to seeing where it goes.

Elentor
Dec 14, 2004



Chapter 2 - Planning

Starting off:

Before starting a project I like to plan as much of it as I can. I write some game design documents, I doodle some concepts of how I envision something to work (you'll see a lot of those), then I start working on them spreadsheets. Oh yeah, spreadsheets.

There's no way around them.

I like spreadsheets because I can test numbers and formulae on them as I go and they're a great way to structurize my thoughts. Nowadays I like to plan ahead the high-level structure of my code as well so I don't have any unpleasant surprises along the way. Though most of it has been heavily compartmentalized since as a Technical Artist I work on solutions that have to be easy-to-use and to integrate. Tying it all together in a single game is something I haven't done in a while.

A lot of the early spreadsheets end up being train-of-thoughts. Instead of drawing, I type things. When I'm satisfied with them, I create a document describing the mechanic and make another spreadsheet detailing it. Because a lot of these are train-of-thoughts, I don't polish them as much as you'd hope, so they're not overly presentable. Still, if you're curious, I'll make another update showing some of them off, but here's an example of a spreadsheet I made for the Ship Generator. Since I actually pulled it off and made the thing, I consider it a success.



Overall I created 18 text documents and 19 Excel files for the project for a total of 67 tabs, not including files being used for the game database. There's one about this LP too, though if you saw how I ended my last Let's Play this should come as no surprise.


Art:

I'm not gonna go wild here - going solo, it's more realistic to keep things low-poly and as simple as possible. The fantasy of making a super ultra HD game is fun, but not feasible. I suppose this is true for most indies.

I'm gonna try to go for that raw polygon look that minimalist games go for, where the models aren't super smoothed out. I figure that's a good start as I polish things out. If I see I can do more complex models and get out with it, I'll go for it, but this is my fallback plan.

Still, no matter how simplistic the art direction, the project might still need a huge number of assets.


Assets:

Let's get down to the nightmarish part: I estimate 1200-1300 3D models will be needed, which is why I wanted to keep the art direction simple. Out of these models, I've already made some 250, most of which pertaining to the ship generator.



Most of the heavy-weight 3D model content I'll leave to the end and use some cube placeholders. Some of it, however, is tied to the procedural generation. I can make 200-300 models a month, so I imagine it'll take me 5 months to finish this side of the artwork.

I haven't assessed how many individual textures I'll need, but I've assessed the texture generators, and most of the separate textures will be created by procedural snippets, some of which I already have. I do want, however, to work eventually on the interface and give it a final special polish.


Production:

One of the thing that I think makes the good procgen games is that they get their priorities straight. They seem to me to be games that work with a fixed seed if you're playing them the first time. Some of the less popular procgen games seem to lack direction. This is some hard stuff to do.

Ultimately I think it's important to list a few goals and move up in ambition as I reach them instead of working on everything at once. Time is a limited resource, and as much as I want to spend a few months working on beautiful procgen planets, I'm a single dev and prioritizing gameplay is gonna be my focus once I get the basics down. That and doing some heavy playtesting between the bigger goals.

Milestones:

1) A simple, one-note procedural stage where you can play with a ship.
2) A hub where you can equip and upgrade your ship in-between stages to add item functionality.
3) A complete biome that generates an actually interesting procedural stage. This is the part that will make or break the project and the core gameplay loop being fun is highly dependent on it.
4) A full procedural universe with multiple maps and biomes.
4b) Assess if I should do a preliminary graphic pass or if it won't be worth the time. Maybe take a week to play around and see what I can do to improve. Possibly try to implement my planet generator into it (which I show some screenshots in this post).
5) A single-player campaign integrated with the procedural content.
6) Support for multiple stories and quests that unlock as you go.
7) Work on graphic improvements and other systems. Implement content from 4b if I had skipped it.
8) Polish the interface and user experience.
9) If everything else is peachy, possibly add alternate game modes (Time attack with a fixed seed, Arcade Mode, Ironman Mode, multiple difficulties).

Right now I'm somewhere between 1 and 2. I've got something working, and what I believe that would have been the hardest part (code-wise) out of the way. So while there's still a long way to go, we still have to do some catch-up, and see how everything started.


NEXT TIME:

Procedural models! Sketches! Actual Spaceships!


Qs & As:

This is where I retroactively post answers to replies that between this update and the next, for future readers/reference:

EponymousMrYar posted:

Seems interesting.

100 million locations to get maps from seems a bit huge (then again it is a universe) so I hope you start small and then scale it up because it's rather easy to get tired of the sheer size of things when what you mainly want to do is follow some breadcrumbs, since those are typically big 'SOMETHING INTERESTING IS HERE' beacons.

Yeah, I'm not thinking purely of numbers at this point. 100m locations seem huge but I want to concentrate on a smaller experience, and you'll end up being taken to some places more than others. So think of 100m quadrants as a 10k x 10k tile map rather than a vast infinite universe. There are 2D MMOs that fall within that range.

Ultimately you'll be playing from a pool of ~30 different maps. These have to have high replayability by themselves, like the 4 tilesets from Diablo 1 had, or the 100 or so endgame maps from Path of Exile have. Having a gigabazillion things can be pretty boring if they're all the same, so I don't want it to be, and I don't want the scope of the game to be some overwhelming behemoth that doesn't deliver.

Most of the game is gonna be situated in the local sector, with 100 stars and some 880 planets. As soon as I decide on the seed, I'm gonna start manually placing things on it. Landmarks, naming some planets, adding backstory and seeing how and why things should connect. You'll be seeing a lot of the same places over time and grow familiar with them.

Systems have 4 to 16 planets for an average of ~8.77 planets per system, not counting moons, and ~15.47 counting moons. 15 out of 100 may seem small, but only a small fraction of a 10x10 map is deep space, most of the tiles are adjacent to a planet or a moon. After each stage, you get a pool of 2-4 choices where to go next, mostly from adjacent quadrants (but sometimes from quadrants 2-3 units away). These choices are weighted towards civilized space, but I'll place some pockets of deep dark areas in the map where some more obscure factions may live.

code:
Iterations: 300000
--------------
Planets: 8.78%
Moons: 6.70%
Orbital Space: 39.76%
--------------
Civilized Space: 55.23326%
Deep Space: 44.76674%
Celestial Bodies: 15.47771%
About the choices you have when moving around:

* One of the options will always be 100% random.

* One of the options is moderately weighted towards your current vector taking in consideration the past 5 jumps, excluding campaign-enforced jumps. This is also lightly weighted towards civilized space.

* One of the options is weighted your quest objective, or failing that weighted towards random planets/moons around you.

* If available, the last option is random between weighted towards civilized space, or lightly weighted towards the origin so you can backtrack.


About the size being too huge when dealing with the campaign:

* Campaign stages always have a special icon in the stage select.

* If the campaign you're currently playing requires you to be in a specific planet, one of the choices will be weighted towards the direction of the planet. If you go too long without getting to it, one of the choices will be the campaign stage.

* If the campaign requires a "certain type of planet" (like a planet controlled by a certain faction, or a gas giant), the first planet that matches the criteria within a certain range will feature the campaign stage. Similarly, if you go too long, one of the choices will eventually be the nearest planet that meets the criteria.


Some of the campaigns unlock special features that relate to your map transportation, like the Windsurfing Board (allows your ship to choose one additional destination), the Space-Stretching Slingshot (Allows you to return to a quadrant of your choice at anytime, but the further away from it the more you're stretching the slingshot. Eventually you'll be forced back to the original place), the Personal Wormhole (Links two star systems together so that you can jump from one to the other whenever you're within one of them) and the Warp Beacon (Allows you to always go back to where it's placed, but it cannot be moved and Warp Beacons are fairly rare to acquire). Additionally, there are a few Jump Gates scattered around in the local sector that allow you to travel from certain star systems, these can be activated when you're within a 3 unit range of them.

Elentor fucked around with this message at Aug 22, 2017 around 00:15

Captain Foo
May 11, 2004

devil on your shoulder





Clever Betty

Looking forward to following this!

EponymousMrYar
Jan 4, 2015

The enemy of my enemy is my enemy.


Seems interesting.

100 million locations to get maps from seems a bit huge (then again it is a universe) so I hope you start small and then scale it up because it's rather easy to get tired of the sheer size of things when what you mainly want to do is follow some breadcrumbs, since those are typically big 'SOMETHING INTERESTING IS HERE' beacons.

Elentor
Dec 14, 2004



EponymousMrYar posted:

Seems interesting.

100 million locations to get maps from seems a bit huge (then again it is a universe) so I hope you start small and then scale it up because it's rather easy to get tired of the sheer size of things when what you mainly want to do is follow some breadcrumbs, since those are typically big 'SOMETHING INTERESTING IS HERE' beacons.

Yeah, I'm not thinking purely of numbers at this point. 100m locations seem huge but I want to concentrate on a smaller experience, and you'll end up being taken to some places more than others. So think of 100m quadrants as a 10k x 10k tile map rather than a vast infinite universe. There are 2D MMOs that fall within that range.

Ultimately you'll be playing from a pool of ~30 different maps. These have to have high replayability by themselves, like the 4 tilesets from Diablo 1 had, or the 100 or so endgame maps from Path of Exile have. Having a gigabazillion things can be pretty boring if they're all the same, so I don't want it to be, and I don't want the scope of the game to be some overwhelming behemoth that doesn't deliver.

Most of the game is gonna be situated in the local sector, with 100 stars and some 880 planets. As soon as I decide on the seed, I'm gonna start manually placing things on it. Landmarks, naming some planets, adding backstory and seeing how and why things should connect. You'll be seeing a lot of the same places over time and grow familiar with them.

Systems have 4 to 16 planets for an average of ~8.77 planets per system, not counting moons, and ~15.47 counting moons. 15 out of 100 may seem small, but only a small fraction of a 10x10 map is deep space, most of the tiles are adjacent to a planet or a moon. After each stage, you get a pool of 2-4 choices where to go next, mostly from adjacent quadrants (but sometimes from quadrants 2-3 units away). These choices are weighted towards civilized space, but I'll place some pockets of deep dark areas in the map where some more obscure factions may live.

code:
Iterations: 300000
--------------
Planets: 8.78%
Moons: 6.70%
Orbital Space: 39.76%
--------------
Civilized Space: 55.23326%
Deep Space: 44.76674%
Celestial Bodies: 15.47771%
About the choices you have when moving around:

* One of the options will always be 100% random.

* One of the options is moderately weighted towards your current vector taking in consideration the past 5 jumps, excluding campaign-enforced jumps. This is also lightly weighted towards civilized space.

* One of the options is weighted your quest objective, or failing that weighted towards random planets/moons around you.

* If available, the last option is random between weighted towards civilized space, or lightly weighted towards the origin so you can backtrack.


About the size being too huge when dealing with the campaign:

* Campaign stages always have a special icon in the stage select.

* If the campaign you're currently playing requires you to be in a specific planet, one of the choices will be weighted towards the direction of the planet. If you go too long without getting to it, one of the choices will be the campaign stage.

* If the campaign requires a "certain type of planet" (like a planet controlled by a certain faction, or a gas giant), the first planet that matches the criteria within a certain range will feature the campaign stage. Similarly, if you go too long, one of the choices will eventually be the nearest planet that meets the criteria.


Some of the campaigns unlock special features that relate to your map transportation, like the Windsurfing Board (allows your ship to choose one additional destination), the Space-Stretching Slingshot (Allows you to return to a quadrant of your choice at anytime, but the further away from it the more you're stretching the slingshot. Eventually you'll be forced back to the original place), the Personal Wormhole (Links two star systems together so that you can jump from one to the other whenever you're within one of them) and the Warp Beacon (Allows you to always go back to where it's placed, but it cannot be moved and Warp Beacons are fairly rare to acquire). Additionally, there are a few Jump Gates scattered around in the local sector that allow you to travel from certain star systems, these can be activated when you're within a 3 unit range of them.

Elentor fucked around with this message at Aug 18, 2017 around 20:20

Angry_Ed
Mar 30, 2010


This is a really cool idea, and I look forward to seeing more.

HerpicleOmnicron5
May 31, 2013

How did this smug dummkopf ever make general?


This is bloody fascinating. There is a kinda procgen shmup, Monolith. I say kinda because it's very much the Binding of Isaac rooms'n'bosses formula.

EponymousMrYar
Jan 4, 2015

The enemy of my enemy is my enemy.


Elentor posted:

Yeah, I'm not thinking purely of numbers at this point. 100m locations seem huge but I want to concentrate on a smaller experience, and you'll end up being taken to some places more than others. So think of 100m quadrants as a 10k x 10k tile map rather than a vast infinite universe. There are 2D MMOs that fall within that range.

That's a lot more digestible than what I thought you were going for because yeah, having each quadrant be a tile makes a lot more sense. The way you described it in the OP had me thinking that the Quadrant was the smallest tile map containing the individual tiles that you actually 'walked' around on.

Also having the random encounter table essentially be shmup layouts but with backgrounds relevant to what you're actually walking around sounds neat

Elentor
Dec 14, 2004



HerpicleOmnicron5 posted:

This is bloody fascinating. There is a kinda procgen shmup, Monolith. I say kinda because it's very much the Binding of Isaac rooms'n'bosses formula.

Didn't know about Monolith. Indeed reminds me a lot of Binding of Isaac, which is also one of my inspirations, though I'm going for the auto-scroller genre like Raiden.


EponymousMrYar posted:

That's a lot more digestible than what I thought you were going for because yeah, having each quadrant be a tile makes a lot more sense. The way you described it in the OP had me thinking that the Quadrant was the smallest tile map containing the individual tiles that you actually 'walked' around on.

Also having the random encounter table essentially be shmup layouts but with backgrounds relevant to what you're actually walking around sounds neat

Thanks! I hope it works.

The idea is that each quadrant can contain 2-3 maps (even if the biome, in theory, can spawn more. The amount of different maps per quadrant is limited and their odds are also random on a per-quadrant basis, so that you won't see everything there is to see in one single planet for example).

Elentor
Dec 14, 2004



Chapter 3 - The Ship Generator, Part I

Like I said before, the first thing I did was a snippet to generate ships. Since the generator came before the idea of integrating it in a Shmup, I think we need to talk about it first.


The Idea:

"Is creativity a limited resource?"

This is the question that ignited a long chat I had with a close friend of mine who's an Art History professor. We were talking about how someone might run out of ideas. Ultimately we reached the conclusion that someone might stagnate or find his comfort zone, but there are very few artists who can reinvent themselves. It's not that necessary, really - once you find something that works, why change? Everyone can recognize an H.R. Giger painting from a mile away.

My musician friends seem to think that stagnation is more forgiving to visual artists. No one cares if every mass-produced design from certain artists all look more or less the same, but if a music doesn't sound awesome and it's just filler, then no one will care about them. I brought this subject to a friend of mine who's a concept artist, and he disagreed - he thinks everyone notices when a character designer is just repeating a formula and that my composer friend was comparing apples and oranges. She should instead compare a movie character designer with, say, a movie composer.

I thought a bit about it, and I got back to where it all started, the feeling that some movie composers got a bit stale over time, but they can still produce great themes. This has always seemed somewhat magical to me, because I absolutely struggle with music composition. The idea of someone being able to mass produce music as they will is like magic. As a child, however, I could draw spaceships for hours. Drawing spaceships came as naturally to me as breathing. I'm not saying they were great spaceships, but it was a soothing experience, one with which I had no struggles.

So at times I think, what if I just created a procedural music generator? That's not new waters. I wouldn't make one of those fancy genetic evolution algorithms either, I'd just make one that understood the rules and popped out something. Sometimes I like to think that some pop music is already made this way. Someone, somewhere, figured out every sequence of notes that can evoke an emotional response and built a machine that does that. I put that idea in the back of my head - maybe someday I'll get to it. But I like how magical music is to me, to this day. For all the 5 years of music theory I studied I could never see any of it mathematically, it was all sensations, a beautiful synesthesia that encompassed everything. Maybe creating music isn't for me, but appreciating it surely is.

But then I realized - what about spaceships? I've seen one or two procedural spaceship generators, but it's not like I had access to their code either. But I love math and I've always seen math as art, and this notion incited something in me. I really wanted to make an algorithm to create spaceships. Something that could make some generic silhouettes at first, maybe to give me some ideas even, if I ever ran out of them. But then I realized that I could try to make a program robust enough so that the algorithms themselves would be the art. A canvas wherein I could play and eventually, in the future, create ships in many different styles.


Planning:

So I had a few goals in mind:

* It had to be modular and independent of any game mechanic. Later I went on to add support for external generic parameters so that the program can now support arbitrary game mechanics.
* It had to support fixed seeds to repeat models.
* It had to, somehow, deal with textures and generate them as well.
* It had to eventually support multiple themes so the same ship could have different skins. This is so I can make the original blocks very simple and basic, and eventually replace them with high-definition versions without needing to change the whole thing again.

I brainstormed for a few days about how to do it. The first step was deciding the method on which the 3D model would be generated - if the models would be made parametrically (so every single polygon would be procedural) or by combining premade set pieces (like toy blocks). The former would add more functionality in the long run but also needlessly complicated to get started, so I settled with doing the latter. As a spoiler, I have thus far implemented parametrical spheres (for Planets) so in theory you can make a ship pulling a randomly-generated asteroid with a rope. I still hope to add more procedural mesh functionality in the far future, but for now the generator uses blocks. So I had to make them blocks interesting.

With that out of the way, the second step was to look for references. Colin Cantwell, the magnificent artist behind 2001 and Star Wars spaceships. Ralph McQuarrie's style and paintings that are also very representative of the overall Star Wars style. And then Kunio Okawara, of Gundam fame, known for his legendary mechanical works. These and many others are legends, and great references upon which to expand. Before I got into making crazy spaceships I had first to make something that resembled a spaceship.

I ended up segmenting the blocks into 15 different folders:

code:
Appendage (General)
Appendage (Round)
Body (Blocks)
Body (General)
Body (Round)
Cockpit
Doodad (Antenna)
Doodad (Greeble - High Freq)
Doodad (Greeble - Low Freq)
Doodad (Mechanical Parts)
Doodad (Panels)
Engine
Tank
Wing (General)
Wing (Panels)
And started sketching parts. I didn't think at the time I'd be posting these, but since this is a Let's Dev, I want to open up as much as possible.










Modeling the Parts

In total I drew 241 parts. So I modeled those 241 parts in a software called Maya LT. They may seem very simplistic - and they are, but when you're modeling 241 of them they can become tiresome very quickly. On top of that I wasn't just modeling the parts. Encoded in the model are other models that indicate where objects are allowed to connect where. For example, here's a model and the contact planes:



The contact planes have names that encode properties. Their names can be used to assign symmetry groups (so a body knows where to put symmetrical wings), to exclude objects, if the object can connect to the center of the contact plane or any of the surface area, and so on. Models have 4 to 12 contact planes.

A lot of these were done blind, but I was really happy with the preliminary result once I got the program working. I had to do a lot of tweaks, but not nearly as many as I expected.

The worst part of modeling is doing a process called UV Mapping. If you don't know what it is, then you're one happy person. To sum it up - UV Mapping is mapping the polygons of a 3D object into a 2D plane so that when you apply a texture to it, the object knows where each pixel of the texture goes. I'm not gonna go in detail yet, but know that I've met a grand total of two artists who enjoy UV mapping. Everyone hates UV mapping.

It took me a little over 30 days (32 I think) to finish all the parts. Ultimately I ended up with a little over 250 parts because I saw some models could be adapted for some quick and easy variations.


Coloring the Model

You may notice that some of the sketched parts have colors. Around this time I played with the idea that I'd bake some of the colored parts of a model in the mesh through vertex colors. If you don't know what this means, it means coloring the actual polygons instead of using a texture - a lot of games in the PS1/N64 era did that. A lot of the 3D enemies in FF7 were vertex-colored.

Now, the interesting thing is that the colors don't necessarily need to show. Nowadays the model is rendered through what is called a Pixel Shader, a program that is run on your video card whose sole purpose (most of the time) is to decide which color goes into which pixel of your screen.

There is a lot to talk about Pixel Shaders, but what you need to know for now is that most of them will flat out ignore the vertex color. But the information is still there. So here was my idea - Let's say we want stripes in the wing. I can encode the stripes as polygons and paint them, say, red. I can then create a shader with two colors, A and B, and tell the shader to paint every red vertex with the color B. And since that Color B can be any color, the stripes don't need to be red, they can be blue, black or whatever.

So I made the following scheme:
code:
Pitch Black - Cockpit
Red - Color A
Green - Color B
Blue - Color C
Whichever channel has the highest color value is picked. Here's an example of how the model looks like before the shader is applied:



Skipping ahead a little, in the final shader I included a color value that is multiplied on top of vertex color. This color value is randomized for each model. The result is that some models may show the colored strips in the wings, for example, while others not.




NEXT TIME:

How the generator works! The first ship outputs! Linear Algebra!

Elentor fucked around with this message at Aug 22, 2017 around 00:42

Captain Foo
May 11, 2004

devil on your shoulder





Clever Betty

Looks really cool I don't have a lot to add to this, not being an artist, but I appreciate your excellent writing and ability to explain your thought process.

Elentor
Dec 14, 2004



Chapter 4 - The Ship Generator, Part II


Programming the Generator

I started coding the generator in Unity. I first thought of coding it using just a few basic shapes (like cubes) as writing the base first and then filling it in with content seeing logical, but I realized very quickly that wasn't such a great idea in this case. It seemed so simple at first - I just need to link objects, but there was so much complexity involved in deciding what goes where and why that I realized that even if I found a way to debug it with simple geometric shapes, it would be a huge undertaking rewriting the whole algorithm to make it look good. I modeled a few shapes at first to test with a very primitive version of the generator but I still wasn't satisfied with the results. So I did the models and started writing the more complex functions now that I had 250 models to test them.

I'll be honest in saying that writing the ship generator was easily the hardest thing I've ever done code-wise, by a huge margin. Something about it seemed so simple at first, but I was met with:

* Bugs in Unity's code on some more obscure rotation functions.
* Things in Unity's documentation that were just outright wrong or outdated.
* A crazy amount of linear algebra.

In case you took good decisions with your life so that you don't know - 3D rotations are hard. 3D rotations are one of the hardest things out there, mainly because you cannot do them intuitively or you run into gimbal locks. So an Irish guy named William Hamilton in 1843 found out that in order to do 3D rotations effectively you need at least four dimensions. And not just any four dimensions - four dimensions extending the complex loving numbers. He named these four-dimensional complex numbers Quaternions. These motherfuckers are hard, and whenever they're mentioned in a thread programmers rush in to say how alien quaternions are. So how weird are quaternions? Hell, let's see the Wikipedia Quotations on them.

quote:

"Quaternions came from Hamilton after his really good work had been done; and, though beautifully ingenious, have been an unmixed evil to those who have touched them in any way, including Clerk Maxwell." — W. Thompson, Lord Kelvin. (1892).

quote:

"... quaternions appear to exude an air of nineteenth century decay, as a rather unsuccessful species in the struggle-for-life of mathematical ideas. Mathematicians, admittedly, still keep a warm place in their hearts for the remarkable algebraic properties of quaternions but, alas, such enthusiasm means little to the harder-headed physical scientist." — Simon L. Altmann. (1986).

My own anecdotes about quaternions involve a 3D engine programmer who said he "just copied the math from the books and never attempted to understand them" and an energy engineer who just told me "lol nope".

If you don't know Numberphile, they're a pretty great and entertaining channel. They have a video about Quaternions that is pretty decent and will go in detail.

So why am I bringing quaternions? Because seriously, screw quaternions.




I don't really remember what I was trying to solve when I drew this. It's very hard to convey the challenges I faced in designing the generator. There's 1.78Mb of code there that is mostly math, that's enough linear algebra for the rest of my life. I imagine a lot of it would be trivial to a mathematician or an engineer, but I'm glad I did it. I think I know a lot more now than I did before.

Along the way I also found out that some functions in Unity's documentation were downright wrong, though I believe they have since updated them. This made the whole thing extra hard as I'm relying on some of Unity's functions regarding the transformation matrices, which are yet another way to handle rotations.

Eventually it all started working and it put this out in the world.



That doesn't look a lot like a ship, but it worked. As soon as I got that I started working on symmetries.



There were lots of bugs back then with the code that defined symmetry. I wanted the generator to be able to recursively spread objects symmetrically to generate more complex shapes. Finally, I had a breakthrough - the first objects that looked like spaceships started coming out.



Around this point I was very satisfied with the functionality. The generator works. It took me about a month of code to write all the necessary functions, but it works!


To showcase how it works, I think it'd be nice to try to replicate a ship with which we might be familiar. So if I wanted to make, say, something similar to a B-Wing - a Vertical ship with a cockpit on the top. Excluding weapons because I hasn't modeled any yet. Let's see how we could split it.



There are multiple ways to approach it, but here's a simple one that I wrote:

quote:

Add Cockpit
Add Body to a Bottom Connector of the Cockpit
Add Wings to the Body:
* Rotate Wings around the Connector Normal until the wings are horizontally-aligned
Add an Extension to a Bottom Connector of the Body
Add a Wing to the Extension
* Rotate Wings until the size of the frontal axis is at its highest, so that it's aligned like a fin.

These are the instructions passed to the generator. The actual code is a bit verbose, I can show some of it if there's interest or even try to replicate a ship of your choosing with some codes, but here are some of the results for the B-Wing.



Our very own B-Wing-like ships, using some of the basic blocks! It's possible to do a lot better - in the B-Wing diagram, 2 and 4 are symmetrical shapes connected to 3, which is also doable. But it was very easy to get something that followed the general structure. We can even add a few more details to it if we want!




NEXT TIME:

Wrapping up the generator! Adding color, textures and more complex shapes!

Elentor fucked around with this message at Aug 25, 2017 around 00:06

TooMuchAbstraction
Oct 14, 2012

My fingers are set to vibrate


The ship generator is the Interesting Problem underlying this game for me. It's one of the coolest things I've seen in a long time. Good job on muscling through the hard math to achieve your goals.

Elentor
Dec 14, 2004



Thanks a lot man. It certainly was the interesting problem for me as well when I started. There are still more functions I want to write and I'm regularly updating it, but I got so happy the first time the thing just worked.

EponymousMrYar
Jan 4, 2015

The enemy of my enemy is my enemy.


gently caress Quaternions, every time I think of a 3d game idea I run into them and it's like 'THIS IS YOUR BRICK WALL ONLY THE BRICKS ARE MADE OF EVEN MORE BRICKS THAT ROTATE AND TRANSLATE ON A PLANE OF DO NOT PASS'

EponymousMrYar fucked around with this message at Aug 24, 2017 around 22:56

biosterous
Feb 23, 2013



Please don't actually use the [code] tag with long text lines, it always leads to broken tables

Those are some rad looking ships, though!

biosterous fucked around with this message at Aug 24, 2017 around 23:54

Elentor
Dec 14, 2004



biosterous posted:

Please don't actually use the [code] tag with long text lines, it always leads to broken tables

Those are some rad looking ships, though!

Oh, sorry, didn't even think of that. I hope it's better now!


EponymousMrYar posted:

gently caress Quaternions, every time I think of a 3d game idea I run into them and it's like 'THIS IS YOUR BRICK WALL ONLY THE BRICKS ARE MADE OF EVEN MORE BRICKS THAT ROTATE AND TRANSLATE ON A PLANE OF DO NOT PASS'

I love the official Unity documentation for Quaternions. They're almost begging you not to touch them.

quote:

They are based on complex numbers and are not easy to understand intuitively. You almost never access or modify individual Quaternion components (x,y,z,w)

quote:

W component of the Quaternion. Don't modify this directly unless you know quaternions inside out.

biosterous
Feb 23, 2013



It is better, thank you!

KillHour
Oct 28, 2007

Wake up and
smell the murder.


Aren't you using Unity? Why are you even working with Quaternions directly instead of using the built-in functions?

Elentor
Dec 14, 2004



KillHour posted:

Aren't you using Unity? Why are you even working with Quaternions directly instead of using the built-in functions?

This is a good question. There are three reasons:

1) I had to understand some math related to Quaternion Lerping to do some more advanced functions. It wasn't a matter of copy-pasting the math, I figured out that understanding it would give me more tools in the more abstract sense. It ended up being really useful.
2) Because some functions weren't, at the time, working as advertised and the documentation wasn't right. I believe this has since been fixed.
3) Because all the math related to the conversion between Quaternions and Transformation Matrices aren't threadable.

KillHour
Oct 28, 2007

Wake up and
smell the murder.


Elentor posted:

conversion between Quaternions and Transformation Matrices

TooMuchAbstraction
Oct 14, 2012

My fingers are set to vibrate


Elentor posted:

3) Because all the math related to the conversion between Quaternions and Transformation Matrices aren't threadable.

How does the ship generator leverage threading? That doesn't seem like a trivially parallelizable task. Or did you want to be generating multiple ships simultaneously?

Anticheese
Feb 13, 2008

$60,000,000 sexbot


Figuring out transformation matrices was enough of a pain when I was trying to add twin thruster trails to a couple of spaceship sprites! This is fascinating stuff, OP.

Elentor
Dec 14, 2004



TooMuchAbstraction posted:

How does the ship generator leverage threading? That doesn't seem like a trivially parallelizable task. Or did you want to be generating multiple ships simultaneously?

The idea is to pre-load ships for the upcoming stages since the enemies are also randomly generated, so we have to minimize loading. As it stands right now, my current prototype has 0 loading screens other than the initial startup. It won't be like this forever, but it's looking good so far.

Kurieg
Jul 19, 2012



I just read the wikipedia article on Quaternions.

quote:

Unlike multiplication of real or complex numbers, multiplication of quaternions is not commutative. For example, ij = k, while ji = −k. The noncommutativity of multiplication has some unexpected consequences, among them that polynomial equations over the quaternions can have more distinct solutions than the degree of the polynomial. The equation z2 + 1 = 0, for instance, has infinitely many quaternion solutions
how?

KillHour
Oct 28, 2007

Wake up and
smell the murder.


Kurieg posted:

I just read the wikipedia article on Quaternions.

how?


Grab a Rubik's Cube and hold it with the white side up. Now rotate the whole thing 90* towards you and then 90* to the right. Now start from white again and first rotate it 90* to the right then 90* towards you. See the difference? If you perform the rotations in a different order, you end up in a different place.

Edit for images:

Start



Up



Right



vs.

Start



Right



Up

KillHour fucked around with this message at Aug 28, 2017 around 19:20

Kurieg
Jul 19, 2012



I suppose that makes sense, but it's also not something that my brain would interpret as multiplication I guess.

Elentor
Dec 14, 2004



Kurieg posted:

I suppose that makes sense, but it's also not something that my brain would interpret as multiplication I guess.

That's because the whole thing is in the plane of complex numbers. Multiplication and rotation are kinda the same there. When you multiply 1 by i for example, you're rotating counter-clockwise 90 degrees.

code:
       i
       |
-1_____|_____1
       |
       |
      -i
Starting from 1:
1 * i = i. So you rotated 90 degrees.
i * i = -1 as we know, so you rotated 90 degrees again. Plus, now you know why i * i = -1 in a way that fits a more general rule.
-1 * i = -i
And last, -i * i = 1.

There are lots of geometric consequences that are extrapolated from this rule, but it should make it easier for you to see how a four-dimensional version of this would have attributes similar to the Rubik's Cube example.

Elentor fucked around with this message at Aug 29, 2017 around 03:01

Elentor
Dec 14, 2004



Wrapping up my next update, I should be posting tomorrow/Friday at most.

Adbot
ADBOT LOVES YOU

Elentor
Dec 14, 2004



Chapter 5 - The Ship Generator, Part III


Let's talk about getting the ships in the game and how their components work. This chapter is about bridging the models generated with the abstract ship concept from my game. Which is not that complicated - a shmup ship moves and shoots things. It has a Health pool and in this case, can equip multiple weapons.

As soon as I finished the basic generator I knew what I wanted to do - getting those ships shooting. Here's something about game genres: It's very easy to prototype a Shmup. Don't take me wrong - it's not easy to make any kind of full game from start to finish. As soon as you get anywhere past the initial prototype, programming a videogame gets convoluted quickly. Then you have to polish the user experience, create thousands of art/sound content, iron out bugs, constantly iterate on the gameplay to make it fun, it's a nightmare. Whenever you see a complete product, you can be sure that it was made on top of sweat and tears.

There are, however, some games that are easier than others to get a tech-demo going for. You can do a basic shmup by adding WASD/Arrow key controls to an object, make it shoot another object when you press a shoot button, and make it so that object destroys itself and an enemy object when they collide. If you iterate on it, you get Space Invaders.

Some genres are pretty easy to get started due to the ease of the available tools. First Person Puzzle games have a plethora of assets to kickstart you. Unity itself has a 3D Point-and-click adventure game script ready to be used that supports all basic commands of a would-be telltale game.

And just so you know - Speaking from experience, text games, depending on their genre, are not particularly easy to get rolling. I mean it.

Either way, it's very easy to get some basic code that will make a ship that moves and shoot something.

https://www.youtube.com/watch?v=lBQA6JqN9lg

This was the first test, from a little over a month ago. It took months to make the ship generator, and 10 minutes to make the little ship do that, but it was a start. The first step towards a game.

Afterwards, I wrote a small Debug Script that allowed me to change ships at will and visualize their stats. This is the video that got me really excited about the project:

https://www.youtube.com/watch?v=vMOMcL3Y1A4



Simple as it was, there was something incredibly satisfying about seeing these small random ships shooting. There was a lot of work to do, but man was I happy about the prospect.


Generating the Ship Entities

A bit of the workflow of how the ships are generated:

ShipSeed - Contains the Seed of the ship, the Level, the Faction, the Ship Class as well as other informations such as the Version (so that if I alterate the generation algorithms in the future, the game doesn't change your existing ships).

I've been talking a lot about seeds, so in case you don't know: A seed is a value that when used will kickstart the Random Number Generator into generating other numbers. Unless something is awfully wrong, every seed should result in the RNG yielding the same sequence of numbers afterwards. So the seed is ultimately a simple number that blossoms into, well, everything else. You can start a ship with a seed of 0 and every time you initiate the Ship of seed 0, it'll be the same ship. Or the seed might be 12005, or 21860719. You get the gist.

The ShipSeed then gets the appropriate Model Generation algorithm from the Faction and creates a Ship from the seed value. Currently there's only one ShipGen Algorithm, but the plan is to make it so each faction has different looking ships from each other.

After the Model is generated, we populate the ShipSettings with relevant stuff like Ship Health, Armor, and so on. This process is not decoupled from the Model which is why it comes after the model (and also why versioning the ship seeds is important). For example - while everything is a bit random, a ship's health on average will be higher if the ship's model is bulkier.

Afterwards the ship is assigned a random name, which is in itself enough content for a separate chapter. Maybe not a huge chapter, but a chapter nevertheless. We are talking about procedural content, after all.

Weapons:

The main reason I wanted to integrate the model with the actual settings is to be able to assign some of the weapon slots to actual connectors on the ship model.

Here's me playing with adjusting the weapon mounts to fit on the ship correctly:



And here's a ship that spawned with one too many mounts.



The weapon mounts can then be assigned to the weapon slots. If there are not enough mounts in the ship model, the weapon slots will default to some fixed coordinates underneath the ship. Otherwise, they'll use the mounts connected on the ship's body. This is super exciting, because a single Weapon Slot can split your weapon into multiple mounts for a 4-way X-wing-like alternating weapon, for example.

https://www.youtube.com/watch?v=GNl_O8SrQVk

Afterwards I added more exotic weapon mount animations. I didn't expect it to work so nicely, you can almost feel like you're the boss of a bullet hell.

https://www.youtube.com/watch?v=Ks27WQ0m6TY
https://www.youtube.com/watch?v=QTHG7O0suQE

If you want a more detailed info on the Weapon Mounts, check my Update Log here.


Greebles and what not:

Greebles are the name given to those small, high-frequency fine details in spaceships. Not all spaceships have greeble, but some of the more popular ones in Sci-Fi do. I'll start to refer to high-frequency details as HF for short. The Millenium Falcon is almost entirely greeble.



Hell, most of the larger Star Wars ships are heavily covered with greeble. Although I added a big red arrow pointing to an area that is almost entirely greeble, the rest of the Star Destroyer's plates are also covered with high frequency details. In reality, you'd probably want to cover all of the exposed cables with something. But that wouldn't look very cool, right?

Creating Greeble, in general, is not an easy task. Greeble has to resemble something, so the more references of actual engineering parts, cables and real-life HF doodads, the better the greeble.

It's particularly easy to make bad greeble. If you type greeble on google images you'll see mostly small panels crammed together to give the illusion of detail. Compare some of the results you find with this:



For greeble I favored modeling some 50 parts manually and adding on top of the ship instead of just resorting to a texture, although I'll probably end up playing with textures eventually.



One of the more recent features I added was decoupling greebles from the standard stream of RNG. This way I can add extra details to a ship without influencing the rest of the ship stats. For example, a cool tidbit I added is that ships can get more detailed the higher their level:



The Underground Foundation is currently my favorite ship. I'll probably keep it as the starting ship, and allow the player to spend some of its starting credits to buy an updated version in the first stage.




This is made so that in the future, when given the option to upgrade your ship, you might see a cosmetic change in it. TheWhiteDragon suggested that there be also a way to keep the previous appearance, which I'm keeping in mind.

In the meanwhile, TooMuchAbstracton asked how a ship would look like if we took it up to eleven. So let's take a look at the Underground Foundation, our current mascot, with way too much poo poo crammed in, shall we?







And with that, we conclude this update.


NEXT TIME:

RNG! Randomness! Numbers! Generation!

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«13 »