Sburb Development Project Thread

[Okasen]

Care to actually point out where my math goes wrong? Because the method I used was 100 * 99 = 990 (for every item being combined with one other unique one, multiplied by two to account for && and ||) and then, if we were to allow taking each of those 990 result items and alchemizing them with another of the 990, then you get 990 * 989 = 979,110 and so on until it's ridiculous.

Well, for one thing: 100 * 99 is 9900, not 990.

Damn, that must be an incredibly embarrassing mistake to make while acting indignant over someone insulting your impeccable maths skills.

Well fuck, that is indeed incredibly embarrassing.

I can multiply I swear.

[Tyrannic]

Of course, that means EVERYONE was wrong since darkDetective said Okasen was blowing things out of proportion, when in actuality continuing down that same chain of logic you get 9900 * 9899 = 98,000,100.

Well, yes, maybe, sort of.

By the method he used, Okasen was actually underselling the issue. As darkDetective has yet to show his work for this problem, however... what can really be said? There are a whole bunch of factors I can think of that would simplify or complicate alchemy, respectively decreasing or increasing the number of available items. It is possible that darkDetective has tweaked these variables to produce a set of possible combinations that is neither woefully inadequate nor completely outside the realm of possibility. He might already have done so in this thread, but I have no intention of reading through all of those blocks of text to find out. I only appeared because somebody made a mathematical error. I am like some kind of maths fairy. I fly from forum to forum, pointing out people's mistakes and leaving shame under their pillows.

[Thedude3445]

As an outsider looking in, with absolutely no experience in game development or programming, this is actually the idea that I like the most:

And Legendary, that would make the game incredibly niche, and is basically being done on the forums right now in the Roleplaying section. There is no reason to create a system for something that people are just doing on their own right now anyway.

I do not think you know what Nethack is. Lemme try this again.

You should make it look like Dwarf Fortress. There are still graphics, but they are at their simplest. Things appear as letters and symbols present in ASCII or similar character collections and thus the Dookhamner40K with Popamatic Action doesn't have to be graphically designed. It looks like whatever symbol you use for a hammer.

The roleplaying section is almost certainly not doing that because my understanding is that they are doing text-based games. It's also not all that niche, because DF and Nethack are pretty popular! Plus, abandoning that level of work, AT LEAST UNTIL THE REST OF THE GAME WAS DONE, would still allow you to release playable betas along the way and at a much faster rate, which would help people keep interest in the project.

Making an ASII or at least 8-bit styled Homestuck game would in my opinion be the best option. At least to show the world that it can be done, and what kind of game SBURB would be like, THEN start thinking about making a full-fledged 3D game. Number one it would allow you to actually make the millions of item combinations that SBURB promises a reality because there would be very little sprite or model work. Number two once you work out the engine that way, you could use that as a basis to start working on a more advanced version of the game. Number three you could implement multiplayer much faster, which is one of the biggest potential draws of a game adaptation of any MSPA comic.

I'm almost 100% certain that an ASCII version of SBURB would be extremely popular, no matter the lack of real graphics.

[Frost]

Have to agree with that. ASCII would be able to deliver all of the important parts of most Sburb video game ideas with significantly less effort. Hell, an ASCII Sburb game could comfortably be made by a single programmer.

Only two significant drawbacks:

Firstly, it'd be ugly to look at. This wouldn't have any major effect on playability, and Dwarf Fortress has proven that ASCII graphics wouldn't be a dealbreaker. It'd be a shame to lose the opportunity to use Homestuck's excellent visuals, though.

Secondly, it'd practically force the game to be turnbased or pseudo-turnbased (similar to DF or Nethack), for a bunch of fairly complicated reasons. This might harm playability a little bit, but it's not like any of these wannabe Sburb developers have expressed too much preference with regard to how the game would actually play. Unfortunately, it would make it much more difficult to implement multiplayer gameplay.

[darkDetective]

Making an ASII or at least 8-bit styled Homestuck game would in my opinion be the best option. At least to show the world that it can be done, and what kind of game SBURB would be like, THEN start thinking about making a full-fledged 3D game. Number one it would allow you to actually make the millions of item combinations that SBURB promises a reality because there would be very little sprite or model work. Number two once you work out the engine that way, you could use that as a basis to start working on a more advanced version of the game. Number three you could implement multiplayer much faster, which is one of the biggest potential draws of a game adaptation of any MSPA comic.

I'm almost 100% certain that an ASCII version of SBURB would be extremely popular, no matter the lack of real graphics.

ASCII would present it's own problems as well, along the lines of if for some reason ANY item in the game doesn't successfully combine with any other item with a decent description, we would get attacked for it. It forces us to account for every single combination in the game and provide statistics and a description for every item. It sounds like less work, but it is really way way way way way way more.

More work? Why is this DD? Isn't drawing a million sprites harder?

Yes, simple question asker, yes it is. That is why we AREN'T drawing a million sprites.

Let us give example numbers for what exactly we are planning to achieve at the minimum.
We want to have 10 weapons the players can choose from, and each weapon represents a Primary attribute. You can't combine more than two Primaries without one being overwritten.
That leaves us with 10*10=100 possible combinations for the weapons.
Each ITEM in the game has a Secondary effect, this creates an aura or an effect with said Item, and you can stack up to 4 or so as long as they don't contradict.
Let's say that there are 25 Secondary effects and each effect has about 4 items it is assigned to. 25*4=100 sprites.
We are up to 200 now.
Now if we have a wide, a long, and a regular sprite for each effect, that is 25*3=75+200=275 sprites.
Now for every Item sprite we want to modify it to have a broken version. 275+100=375 sprites.
Let us say we want to have 5 different specialized secret recipes for each weapon type 5*10=50+375=425 sprites.
Now let us add 50 easter egg sprites, aka sprites that provide little use other than be from Homestuck and be little trophies. 425+50=475 sprites.

And from those 475 sprites we get thousands of valid combinations. If we wish, we can even add additional sprites to the game before the final release, in updates, or in an expansion pack, since 475 really isn't as many sprites as it sounds.

[rogue of void]

I have read this entire thread and I notice people, other than oj, haven't mentioned freymotifs, strife themes, and land themes. The music for each land would have to be different, or simply have one set of music for each modifier which I think would only make things even harder to do, there is another option, have a set of land themes for every type of land, but that seems like it would cheapen the experience. Also what are you going to do about freymotifs and strife themes? All of the music has been unique to the player and the area so how are you going to handle all of that? What about the people who want to upload their own music, how powerful will the ingame freymotifs be, and how powerful will the imported ones be?

[Thedude3445]

You also have to take into account randomly generated lands. That's the big part. even if you just take the 32 different land types from the canon, that's.... uhh a ton of combinations (math = too much work).

[rogue of void]

You also have to take into account randomly generated lands. That's the big part. even if you just take the 32 different land types from the canon, that's.... uhh a ton of combinations (math = too much work).

Now try making music for each and every possible land combination. And that's only 32 types.

[Thedude3445]

You also have to take into account randomly generated lands. That's the big part. even if you just take the 32 different land types from the canon, that's.... uhh a ton of combinations (math = too much work).

Now try making music for each and every possible land combination. And that's only 32 types.

well music isn't the biggest deal at this point. Someone could go in and make some crappy looping chiptunes if they have to.

[orngjce223]

I will complain if I have to make 144 or 256 or 1,024 distinct "crappy looping chiptunes". You are not going to make them distinct, not in that kind of problem-space. You're going to have to reuse them, a lot.

[Legendary]

[Overly technical]It's technically only 31 themes! Jade and Kanaya share one.[/overly technical]

But seriously. I'm glad people are re-examining my ASCII suggestions, because they're actually REALLY GOOD.

[agnomen]

In an ASCII based system, you wouldn't need to write descriptions and work out statistics for each and every item ahead of time. All you would need to do is assign each base item various description "tags", e.g. colour, size and shape, and write the alchemisation part of the game to combine these to generate a description for a new item. Sure, you'd lose a little bit of flavour, but no more than you'd lose with an extremely bored writer crafting a paragraph for each and every combination. The Everything Randomiser is a pretty entertaining example of how much you can get from combining various tags together!

Speaking of combinations, let's look at a little bit of the maths involved in trying to figure out how many alchemised items we can make, shall we?
For the simplest case, we'll assume that an alchemised item is made of two different base items through either the && or || operator. These are both commutative - that is, A || B is exactly the same as B || A. An alchemised item is not allowed to be alchemised again. The number of combinations for one operator will be (n choose 2), there are two operators, and so we have 2 * (n choose 2) total combinations. This works out to be 90 if you start with 10 base items, and 9900 if you start with 100.

Next we'll open it up to allow for three-base item combinations. The possible combinations here are A || B || C, A && B && C, A || B && C, A && B || C. This gives a total of 4 * (n choose 3) additional alchemised items. Starting with 10 base items, this would mean there's 570 alchemised items to consider. Starting from 100, there's 656700.

In the box - if you allow realchemisation.

show spoiler

hide spoiler

Ok! Thinking about what happens if you allow the re-alchemisation of items. Assuming that we're still not allowing a base item to appear in a given combination more than once, introducing an alchemised item can be considered to be short-hand for part of a long sequence describing the total chain used to create the final item. In other words, a final alchemised item can be described entirely in terms of base items.
If we start with n base items, a final item is made of k base items, and involves 2^(k-1) operators. The total number of alchemisable items will therefore be the sum running from k = 2 to k = n of (n choose k) * 2^(k-1). a) I wish this forum had LaTeX and b) I hope to god that's right, combinatorics was never my thing.
Starting with 10 base items, this allows a total of 29514 possible combinations, a truly ludicrous amount. This is only really an order of magnitude estimate, though - it assumes that all combinations generate unique items, and also, slightly less forgiveably, assumes that the ordering of the items is unimportant, ie A || B && C generates the same result as A || C && B. It works fairly well as a lower bound, though.

EDIT: Oh, we've moved onto music! Also interesting. As has been said, you would need a lot of individual tunes to cover each possible combination - it might be easier to write a tune for each land element and then mix the two together in some way to make an overall theme for the land. At the very least, it goes from writing (n choose 2) tunes (since there shouldn't be a difference between the Land of X and Y and the Land of Y and X) to n. Crappy little looping chiptunes could work pretty well there, so long as they were written so they could combine fairly easily.

[darkDetective]

I have read this entire thread and I notice people, other than oj, haven't mentioned freymotifs, strife themes, and land themes. The music for each land would have to be different, or simply have one set of music for each modifier which I think would only make things even harder to do, there is another option, have a set of land themes for every type of land, but that seems like it would cheapen the experience. Also what are you going to do about freymotifs and strife themes? All of the music has been unique to the player and the area so how are you going to handle all of that? What about the people who want to upload their own music, how powerful will the ingame freymotifs be, and how powerful will the imported ones be?

Freymotifs I am holding out on, as VERY little about them has been explained. If they are simply attack types, I actually have a system already planned out for them. If not, then I really need to find out what they are to begin work on them. The music will be discussed with our composer, but I think we will be doing something along the lines of area based music. This should result in differing music throughout the game and throughout multiple sessions, since areas will be randomized. You could very well encounter the same music during a session, but the music would differ enough during the sessions that it shouldn't ever get old.

As for the land themes, we most likely won't be doing all 32 right off the bat, as that is a lot of legwork to do for the spriters. However, we will be using a random generation system for the lands so you should almost never encounter the same land twice, and even if you do the layout will be different the second time. Our biggest goal in this project is to make each playthrough unique.

[rogue of void]

As for the land themes, we most likely won't be doing all 32 right off the bat, as that is a lot of legwork to do for the spriters. However, we will be using a random generation system for the lands so you should almost never encounter the same land twice, and even if you do the layout will be different the second time. Our biggest goal in this project is to make each playthrough unique.

I was referring to music for the lands Background music that plays throughout the entire land, except for maybe the quest bed and the Denizen's Lair.

[darkDetective]

In an ASCII based system, you wouldn't need to write descriptions and work out statistics for each and every item ahead of time. All you would need to do is assign each base item various description "tags", e.g. colour, size and shape, and write the alchemisation part of the game to combine these to generate a description for a new item. Sure, you'd lose a little bit of flavour, but no more than you'd lose with an extremely bored writer crafting a paragraph for each and every combination. The Everything Randomiser is a pretty entertaining example of how much you can get from combining various tags together!

Speaking of combinations, let's look at a little bit of the maths involved in trying to figure out how many alchemised items we can make, shall we?
For the simplest case, we'll assume that an alchemised item is made of two different base items through either the && or || operator. These are both commutative - that is, A || B is exactly the same as B || A. An alchemised item is not allowed to be alchemised again. The number of combinations for one operator will be (n choose 2), there are two operators, and so we have 2 * (n choose 2) total combinations. This works out to be 90 if you start with 10 base items, and 9900 if you start with 100.

Next we'll open it up to allow for three-base item combinations. The possible combinations here are A || B || C, A && B && C, A || B && C, A && B || C. This gives a total of 4 * (n choose 3) additional alchemised items. Starting with 10 base items, this would mean there's 570 alchemised items to consider. Starting from 100, there's 656700.

(will edit some more into this when I get time looking at what happens if you allow alchemised items to be re-alchemised! because I'm that bored.)

If someone wants to do a ASCII system, more power to ya. This is not what I am planning for this project though, and if both of the projects are successful no one is going to sue anyone. Just means that every Homestuck fan in existence will no longer have any free time whatsoever.

For the record though, I would rather you critique my alchemy system rather than throw together numbers based on other peoples posts that have nothing to do with the actual planned system.

[Frost]

You also have to take into account randomly generated lands.

Random world generation is actually very plausible, especially if the graphics were 3D (or ASCII). I mean actual procedural generation from scratch, just to be clear; not just piecing together pre-made parts or anything like that (although there would have to be a certain amount of handmade creation involved).

It would of course still require a ridiculous amount of work, but it's something that (say) a professional development company could definitely achieve in a fulfilling way. I can't say the same for alchemy.

For the record though, I would rather you critique my alchemy system rather than throw together numbers based on other peoples posts that have nothing to do with the actual planned system.

Please don't try to control the discussion, it's kind of an obnoxious thing to do. Try to remember that this thread isn't about your project, it just looks like it is.

[darkDetective]

I was referring to music for the lands Background music that plays throughout the entire land, except for maybe the quest bed and the Denizen's Lair.

Well the music will be broken up by Strife themes, building themes, cutscenes, and such. However for the general exploration theme for the land I guess we could talk about this. How about I give you guys and example and we discuss it. Let's say we are making LOHAC. What if we made it so areas dominated by Heat and such (such as caves filled with lava, flying over lava lakes, pits of fire, etc.) were given variations of a theme we could create for Heat, and areas filled mostly with Clockwork (pretty obvious) would be given variations of the Clockwork theme. This would break up the music over the span of the game and multiple playthroughs. How does that sound?

Please don't try to control the discussion, it's kind of an obnoxious thing to do. Try to remember that this thread isn't about your project, it just looks like it is.

Sorry, not what I meant. Just was trying to point him toward my system rather than the system that was being thrown around in 90% of the posts.

[agnomen]

If someone wants to do a ASCII system, more power to ya. This is not what I am planning for this project though, and if both of the projects are successful no one is going to sue anyone. Just means that every Homestuck fan in existence will no longer have any free time whatsoever.

For the record though, I would rather you critique my alchemy system rather than throw together numbers based on other peoples posts that have nothing to do with the actual planned system.

Right, sorry, I got kinda distracted by maths there, mainly due to the amount of times this has come up before (and carrying on from the discussion a few posts ago). It happens. If I'm reading your system right, you're planning on stacking several sprites on top of each other to generate the overall sprite, yes? A weapon sprite and up to four effect sprites?

[darkDetective]

Right, sorry, I got kinda distracted by maths there, mainly due to the amount of times this has come up before (and carrying on from the discussion a few posts ago). It happens. If I'm reading your system right, you're planning on stacking several sprites on top of each other to generate the overall sprite, yes? A weapon sprite and up to four effect sprites?

Indeed, that doesn't include the recolors for metal changing types, too. Like mythril would make a sword teal, and obsidian would make it black.

[Frost]

What if we made it so areas dominated by Heat and such (such as caves filled with lava, flying over lava lakes, pits of fire, etc.) were given variations of a theme we could create for Heat, and areas filled mostly with Clockwork (pretty obvious) would be given variations of the Clockwork theme.

"Variations"? Procedurally generated variations or handmade variations? It's probably worth mentioning that attempting to procedurally generate music in any way would be an incredibly, hilariously bad idea. Like, Greek Tragedy levels of hubris.

[Thedude3445]

I will complain if I have to make 144 or 256 or 1,024 distinct "crappy looping chiptunes". You are not going to make them distinct, not in that kind of problem-space. You're going to have to reuse them, a lot.

that's why I'm saying that music isn't even necessary if the game is ASCII. At least not yet. Because it's not just Land themes, there are many other themes as well!

But darkdetective is suggesting that if people want to make an ASCII SBURB game they can make their own fan project for it. Is anyone going to do that?

[rogue of void]

I was referring to music for the lands Background music that plays throughout the entire land, except for maybe the quest bed and the Denizen's Lair.

Well the music will be broken up by Strife themes, building themes, cutscenes, and such. However for the general exploration theme for the land I guess we could talk about this. How about I give you guys and example and we discuss it. Let's say we are making LOHAC. What if we made it so areas dominated by Heat and such (such as caves filled with lava, flying over lava lakes, pits of fire, etc.) were given variations of a theme we could create for Heat, and areas filled mostly with Clockwork (pretty obvious) would be given variations of the Clockwork theme. This would break up the music over the span of the game and multiple playthroughs. How does that sound?

Like more work, even if it is only slight variations, now you not only have to make a theme for each type but you also have to make variations for different areas of that type. You took 1 and made it into 4 or more. But that is beside the point, getting back to your LOHAC example, I remember there being mostly equal amounts of both in most areas that we saw, except for the steel girders maybe. So what then?

[darkDetective]

What if we made it so areas dominated by Heat and such (such as caves filled with lava, flying over lava lakes, pits of fire, etc.) were given variations of a theme we could create for Heat, and areas filled mostly with Clockwork (pretty obvious) would be given variations of the Clockwork theme.

"Variations"? Procedurally generated variations or handmade variations? It's probably worth mentioning that attempting to procedurally generate music in any way would be an incredibly, hilariously bad idea. Like, Greek Tragedy levels of hubris.

Well that wasn't what I was planning, but look into the Spore music system, it actually does exactly that.


But we would probably be creating a few different versions of each theme and applying them to certain areas.

Like more work, even if it is only slight variations, now you not only have to make a theme for each type but you also have to make variations for different areas of that type. You took 1 and made it into 4 or more. But that is beside the point, getting back to your LOHAC example, I remember there being mostly equal amounts of both in most areas that we saw, except for the steel girders maybe. So what then?

Well we would put an equation into place to decide which is dominant in an area. Like a gear sticking from the ground would be worth 3 points toward Clockwork, a firelake would be worth 4 toward Heat, etc. Highest number would get the theme. We would also make it so areas would be more likely to be a heavy in one thing rather than the other to make the overall theme of the area obvious to the user.

[orngjce223]

But we would probably be creating a few different versions of each theme and applying them to certain areas.

Ahahahahaha no. If you want even one theme per Land-Aspect, and to fade them back and forth across "aspects", they would all have to have exactly the same key signature, meter, and tempo. That cuts out some of the main ways that you vary music. Procedurally generated music can go shove its atonality down an oil-clogged pipe on LOWAS.

Even if you cut it up like Heat and Light and Clockwork and Frogs and Snow and Crystal and Water getting themes instead of the pair receiving a common theme, you've just made it so much harder to distinguish them from each other, because key signature, meter, and tempo. Major, minor, modes; 2/4 3/4 4/4 6/8 7/8 and 13/8 time; the exact tempo can go anywhere from 60bpm to 240bpm. You've just cut the entire thing down to a vaguely minor 4/4 120 song, which is hilariously generic and frankly has no reason to work.

There is a possible mitigation for the problem, involving storing the music like a tracker as its raw notes instead of the rendered music, but that runs straight into exactly the same problem as the "chainsaw with razor blades" - it requires human judgement to make sure they fit into each other nicely. It's more obfuscated, since you don't know music, but it's the same problem.

[Frost]

You might not want to oversimplify too much with regard to splitting a land up into two "components". Look at the Land of Pulse and Haze, the Land of Brains and Fire, the Land of Maps and Treasure, and the Land of Rays and Frogs. All of them would invalidate this music system you're planning (or, at least, cause it to spastically switch between two themes).

Procedurally generated music can go shove its atonality down an oil-clogged pipe on LOWAS.

See what I mean? Hubris. The Gods struck you down just for mentioning it, through the medium of their holy agent orngjce223.