Sburb Development Project Thread

[orngjce223]

Well, the creation of a game is a little bit different than the creation of a painting, but I will be blunt with you, I have never created a game before. But hear me out. Developers tend to concur that the best way to learn how to make games is to play them, which I have done a lot of. I also have extensive experience through tabletop games of actually setting up games (preparing campaigns and such.)
And over the years I have mapped out the basic principles for multiple games, some of which would probably still stand up to the current market despite me first conceiving of them 4 or so years ago. It has always just been in finding the manpower to create the game, which is getting almost EASY now that I have reached collage age.

Oh, so you're one of those kids who "loves videogames and wants to go into game design when they grow up". Good to know. Have you ever looked into the working conditions of the AAA game studios? (Indie-ing is almost certainly out of the question unless you yourself know how to program, or draw, or music/effects.)

This is not to dismiss you but merely to say that in my experience there are very, very few people who can design games and have other people make them. It doesn't just require good ideas, as real life stubbornly refuses to be a meritocracy. It requires you have charisma... and the ability to make a prototype that people can play, or at least watch, to get the idea of what you're talking about.

Words do very, very little to put across the feel of the exhilaration of solving a puzzle based on that last oblique hint, or the frantic scramble to run for the exit as the fireball or the ninjas or the guards chase you. At the same time, they obscure the flaws: the fetch quest that was novel and interesting the first time, but after the third or fourth load has turned into merely another tedious Skinner-box award scheme; the game that kills you with invulnerable monsters if you so much as hint that you're straying off the beaten path; the frustration of trying to solve the puzzle that has absolutely nothing to do with the storyline and just so happens to be there to make it harder for you.

If you can actually address this pitfall, good for you. But I'm wary, in general, because too many magic lamps have air in them instead of genies.

The basic premise would be one attribute item and one base item, which is which depending on the way they put the cards in. Let's put up a simple equation. A item + B item = A(B)
Alright, that equation made no sense, apparently I'm bad with equations and good with examples.
Let us say you apply a B: chainsaw to a A: katana. You would get a Chained Sword (ala a sword with a chainsaw for a blade)
We reverse that equation and we get a Razor Chainsaw. (a chainsaw with blade running along the sides rather than a chain)

The way I've heard alchemy explained before is that HS punchcard alchemy applies one object's "aspect" to the other object's "concept". I think this may be what you're talking about:

> Hammer && Pogo Ride = concept Hammer, aspect "Pogo springs", = hammer w/ bounce properties.
> Hammer || Pogo Ride = concept Pogo Ride, aspect "Hammer", = pogo ride that looks like a hammer.

No, this does still require sprites to be made for many combinations. A generic "this item is a piece of shit" sprite would really restrict the system to the usual cookbook item-crafting system, just with an alchemiter instead of a forge or workshop. Which could be a worthwhile simplification, but kind of misses the point. Sburb is supposed to be the game of ~imaginaaaaaaaaaaaaation~. At some point, that does need to come across...

[Frost]

Developers tend to concur that the best way to learn how to make games is to play them

Nope. It's a good way to fine-tune existing design skills, and the best way to expose yourself to the work of those people more experienced than you, but it doesn't teach you game design. You sort of have to know what to look for. I racked up dozens of hours playing TES Oblivion when I was a novice designer, but it's only when I played it again more recently (as a slightly-better-than-novice designer) that I'm actually learning anything useful from it.

And over the years I have mapped out the basic principles for multiple games, some of which would probably still stand up to the current market despite me first conceiving of them 4 or so years ago.

I moderated a game design forum for like three years, so please don't take offense when I say that, statistically speaking, most of these game ideas are going to be naive bullshit. It's almost impossible to come up with a good game design through intuition.

It is of course possible to come up with an adequate game design through intuition- a design that, with a bit of luck and revision, would make something fairly playable if you followed it through. Unfortunately, "adequate" isn't going to be enough for Sburb, especially not if this would be your first attempt to actually make a game. If you're serious about going through with this, I'd advise you to recruit a more experienced game designer, rather than relying on your own abilities.

Alchemy etc.

Wouldn't work. You've done a fairly good job of making alchemy deterministic, but your examples contain about a dozen decisions that a computer wouldn't be capable of making. I mean- "a chainsaw with razor blades running along the sides"?

The only thing that came close was the idea that you could recycle objects by recoloring or retexturing them. It's been brought up before, and it definitely wouldn't be enough to make alchemy work, mostly because every non-trivially-unique item would need to be created by hand. That would end up being either far too many sprites to make the game viable, or far too few items to make the game interesting.

[darkDetective]

No, this does still require sprites to be made for many combinations. A generic "this item is a piece of shit" sprite would really restrict the system to the usual cookbook item-crafting system, just with an alchemiter instead of a forge or workshop. Which could be a worthwhile simplification, but kind of misses the point. Sburb is supposed to be the game of ~imaginaaaaaaaaaaaaation~. At some point, that does need to come across...

Wouldn't work. You've done a fairly good job of making alchemy deterministic, but your examples contain about a dozen decisions that a computer wouldn't be capable of making. I mean- "a chainsaw with razor blades running along the sides"?

God forbid the spriters have to draw something!
The point of this is random generation, it is procedural generations.
We take the weapon types and brainstorm combinations, we then draw up said combinations, check them, and then they are DOUBLE CHECKED through the actual alchemy system to make sure they work. I shouldn't even call it double checking because it will be checked way more than twice, it is just the word I will use for stage 3 of the process. Needless to say it will work for the actual game after that point. We will create stupid mundane items, but the majority of those will be easter eggs or easy to procedurally generate. You guys are looking way to far at the extremes, and that is why your ideas wouldn't work. You aren't looking at the fact that players would giggle for two seconds at the crazy Bill Cosby bobblehead that is holding a sword, then throw it out because it is literally just crowding their inventory space after being made. You know like what every kid in Homestuck did. Make a whole bunch of useless crap, pick out 3 things, leave the rest in a pile. The other extreme you seem to be fighting for for an absurd reason would be to procedurally generate everything in the game . How about this? How about I just ask Richard Hawkings to do the videogame companies a favor and pull an algorithm out of his ass that procedurally generates entire working games? Because that is just about the only way you are going to see that within the next 40+ years. When game designers cut things out of games, it isn't because they want to. Just like movie directors. It at some point becomes destroys the game itself if you work too much on one area. Whining about how you won't be able to make a dresser made out of purple gushers doesn't take away the fact that the dresser that an artist spent an hour on will make you giggle for 3 seconds. Or that Bill Cosby bobble head we procedurally generated from an impossible code will do the exact same thing.
If you want imagination, you can change your clothes with alchemy, you know, kind of like what the kids did. Create your own computer with alchemy. Pick out your favorite weapon. You actually deal with those things for my than 5 seconds in total, making it worth it for both the artists, the coders, and the player.
Sorry if I was a bit harsh in part of that, but people really need to get it out of their heads that every thing in Sburb needs to be part of the game. It it is exactly like complaining if they made a Harry Potter game without you going to every single class of the school year. And I am hoping I can get people to understand this if we ever want to get this project off the ground.
And it isn't just recycling the sprites, you could add effects to, like Flaming or Frozen. Think of similar to the Diablo or the Borderlands weapon generation. A limited number of sprites, but an unlimited number of items. Borderlands is especially good for my point because they do the retextures.
On a side note, I would prefer if you said "however, the retexture and recolor of objects was a good idea" rather than "the only thing that came close was the..." You should be encouraging good ideas, not silently dismissing them because they don't fit the "stop trying" theme of the post.

It is of course possible to come up with an adequate game design through intuition- a design that, with a bit of luck and revision, would make something fairly playable if you followed it through. Unfortunately, "adequate" isn't going to be enough for Sburb, especially not if this would be your first attempt to actually make a game. If you're serious about going through with this, I'd advise you to recruit a more experienced game designer, rather than relying on your own abilities.

Oh, so you're one of those kids who "loves videogames and wants to go into game design when they grow up". Good to know. Have you ever looked into the working conditions of the AAA game studios? (Indie-ing is almost certainly out of the question unless you yourself know how to program, or draw, or music/effects.)

This is not to dismiss you but merely to say that in my experience there are very, very few people who can design games and have other people make them. It doesn't just require good ideas, as real life stubbornly refuses to be a meritocracy. It requires you have charisma... and the ability to make a prototype that people can play, or at least watch, to get the idea of what you're talking about.

First off, I have the essential skills. I have leadership experience, and I don't just do fine in tough conditions, I excel in them. Second, I do know what credentials you need to get into the gaming industry. You need to either be a collage graduate with a friend decently high in said company, or you need to be the winner of a gameshow. Anyone that actually believes that the modern game industry is any better than that is sorely mistaken. And no, for most people playing a lot of videogames doesn't make them any better at making one. But for the developers it did, since they don't see it under the same eye as CoD frat boy or WoW Addicts Anonymous survivor. Now maybe I don't have that eye, but I am going to keep trying until someone proves it to me and doesn't just bark it in my face at the slightest mention of Sburb.
Now this is why I wanted to finish my portfolio before introducing the project, because I knew that under the fanbase's scrutiny I would be ignored unless I came to them with nothing less than a 200 page journal on why Sburb wouldn't just work, why it would be fantastic.

And don't even tell me that alchemy is the tip of the iceburg, I know probably better than you. I already have the basics of in game time-travel, the importance of consorts, replayability features, and house building mapped out.

[darkDetective]

Alright, well apparently one of the admins decided that I shouldn't be allowed to respond.
So instead I am going to work on my project in peace until I am ready to assemble a team.
Anyone that wants to ask questions may msg me, but I won't be bringing this up again for awhile, just as I intended.
See you all soon enough.

[Avi]

No you just got caught in the spam filter, it happens sometimes.

[darkDetective]

Why thank you Avi! D :
Didn't know that, I'll be sure to worry less next time!

[orngjce223]

So here's the deal:

If you learn how to program, and have a prototype for us that actually exhibits the new ideas you've been talking about, we'll consider it.

If not, we won't bother. It's really that simple. This subforum generally runs on "do you have something to show for it?" especially for perennial ideas like the Sburb Game. Ideas are cheap. Implementation is the real problem.

If you're new to programming, I'd recommend python+pygame.

I'd like to see it, but it's gotta be plausible and I am not about to do the work for you.

[Frost]

God forbid the spriters have to draw something! (...)

I've never claimed that a restricted alchemy system wouldn't work, design-wise. For some reason, though, you tried to pass off your "make everything by hand" alchemy system as something novel and procedural, and I spent a couple of paragraphs telling you why it wasn't really either of those things. Calm down, I guess?

First off, I have the essential skills. I have leadership experience, and I don't just do fine in tough conditions, I excel in them.

I had all of these things plus years' worth of hands-on game creation and design experience. It wasn't enough to make Nepetaquest work, and you want to manage a project five times as difficult on your very first try.

Now maybe I don't have that eye, but I am going to keep trying until someone proves it to me and doesn't just bark it in my face at the slightest mention of Sburb.

Bro, we're not trying to sabotage you out of spite or jealousy- we're trying to give you some advice. Namely, we're trying to stop you from spending months working on a collaborative crowdsourced multiplayer procedurally-generated open-ended indie action-adventure RPG project with basically no relevant experience. Would it kill you to start small?

I mean, in indie game creation circles, this is about the closest thing there is to a cliche. The "ideas man" with "leadership skills" comes trotting in with the massive project that he's "always wanted to see made", grabs a couple of team members, and suddenly finds that he has no idea how to manage them, and that his big idea is full of holes. It always ends disastrously and I'm kind of sick of seeing it happen.

[darkDetective]

And to be honest, Frost, I know this is way out of my league. But I'm not afraid of failing. Don't really have much to lose, and I can only learn from this experience, even if I do crash and burn. I may sound way to hopeful to you guys, but I can only really see good coming from this. If someone doesn't do this project soon, just like you said, there will be no point in doing it. I never intended to start this project from scratch myself, I thought one was already in the works and I could just help with that. But there isn't. As far as I can till if I don't do it there never will be.
As far as I can see it I spend more of my free time being productive, make a few friends, learn some coding and work on my art, and advance any skills I need to become a Creative Director some day. And I get all that if I fail.

But I won't, because as soon as you start saying you will fail, you fail! So I'm not even going to consider it!

Thanks for the kindness guys, but I think everyone would be happier if you stopped poking holes in me and started poking holes in my project so I know where I need to fill them. Let's do this. ;D

[Frost]

Working on a smaller Homestuck game project is an option, you know? I'd say that getting things right on your first try is far preferable to learning from your mistakes. You get to skip the baptism by fire, and you might even get a game out of it. Hammerkind has proven that a fangame doesn't have to be wildly ambitious to be fun and popular.

I mean, the only reason I can see to pick a Sburb project rather than something smaller is the possibility that it might actually work out. And, well... it's not going to work out, for a thousand reasons. Why not aim lower? Take it from me, disappointing people who wanted to make a game with you is not a fun experience.

[ShadowOfFate]

On a side note, I fully support this game! The ideas seem solid, there is a team who has the necessary skills, so I say go for it!

...man I sound stupid. But I still stand by my opinion!

[darkDetective]

I already have a plan up to the pre-alpha tech demo. If we get that far we will see if the project is worth following through on. By the time I get that out I will have gone far enough ahead in the design process to have spotted and major game ending flaws (no pun intended), and the community will either be on board or against the project. It will also be up to the rest of the team on whether or not they feel it is worth continuing.
Call this a trial phase if you must.
I already have a few programmers, and am working on getting a experienced designer on board. He seems interested so there is hope to be had. I think you will find that I am a lot more serious about this project than past creators.

On a side note, I fully support this game! The ideas seem solid, there is a team who has the necessary skills, so I say go for it!

...man I sound stupid. But I still stand by my opinion!

Haha, thank you Shadow, it is nice to hear some encouragement today. Especially since I just started the earliest phase of development. XD
I'll be sure to keep you updated!

[orngjce223]

Well, poke me when you have a decent tech demo and a script. I apparently have a freakishly good eye for proofreading, so that's offered when the time comes. Music/sound effects may or may not be forthcoming after that, depending on what I see.

[darkDetective]

The Alchemiter Alpha will most likely come before the official tech demo, and I am hoping to have a concept trailer up within two months, but that depends on me finding artists. If it makes you feel any better, two months is just the latest I am allowing myself to go for the concept trailer.

[Legendary]

I think you will find that I am a lot more serious about this project than past creators.

You're not going to listen to this, but you really should be aware that saying this stuff doesn't reassure anyone. People like me and Frost have seen people say this before (I'VE said it before and I wouldn't be surprised if Frost has too) and then, regardless, not succeed anyway. People who don't have our experience in spotting your sort of situation believe in you anyway. I've seen projects that are SOOOOOOOO much simpler than this get to a 50% mark and then fall apart. It's not just the fact that you're doing something really really hard.

You're also doing this for free. You're either going to attract people who are dabblers and eventually get frustrated and go dabble in something else, or you'll get skilled people who decide that Sburb the Freeware Game That Is Several Pay Cycles Away No Matter How Much Money We're Charging isn't as good a use of their time as That Thing That Gives Me Money For Food And Alcohol.

I wish you the best. I hope that, regardless of how THIS project goes, you will get some new skills out of the deal and be ready to tackle new projects.

It's just that, if I were a betting man, I wouldn't bet on this.

[darkDetective]

It's just that, if I were a betting man, I wouldn't bet on this.

Nah don't worry about it. I know people don't know me and I have a lot to prove. And I know I am doing this with the odds stacked against me. I know that this project won't literally pay off for a very long time if we can find a way to get it to pay off at all.

I'm sure as hell not asking you to bet on us, but I really don't think you should right us off the ticket just yet.
But right now I am reminding everyone that this project is not even official till the concept trailer is released. That is when the real thread for this goes up and when I will be bringing in more people for the project. Right now I will be working on the trailer and going over the details with my current team. However, if you see the trailer/thread go up, you can be sure that the project is officially being put together and will be in the early stages of being coded/drawn.

Until then, feel free to ask questions, make suggestions, criticize my ideas, or complain about my lack of an avatar!

[shinyjiggly]

I'd like to help out a bit! I have lots of experience in spriting and a little bit of programming knowledge (I can use GML). Also, I have an idea of what you could do for some of the more "out-there" alchemy thingies:

This way, you can have people alchemize all sorts of things without having to create a bajillion sprites, but won't have to settle for only one garbage/unusable item sprite. Also, It would be close if not exactly how they handled those kinds of things. Also, since it would be a special item instead of "generic garbage item", you would be able to extract the different pieces of the item to get the pieces of that item (like explained here... kinda.). And also, you would need the codes for the unwanted items in the garble to get the one that you wanted so that would make it somewhat balanced.

If you need any sprite work and/or someone to help brainstorm ideas on how to get things working, feel free to PM me!

[darkDetective]

Mmm, see I've already considered this. Something like this would take out the surprise in all the items you can get. A sword and a spear would be a stick with a sword on the end, or a spear end on a sword hilt. Not only does that second makes sense because it would just be called a dagger or a shortsword, but you could see that coming from a mile away. On top of that, the stats would be hard to balance it would be difficult to code. Easier on the sprites, but bad for everyone else. :/

However I might just want to talk to you about sprite work!

[RotationalBasis]

If I may ask a question, will the game be in top-down, sidescrolling or isometric perspective?

Naturally sidescrolling would be the easiest to produce.

[Okasen]

Alright, I'm going to respond to a few points you've made:

God forbid the spriters actually draw something

As an artist who's dabbled in spriting before, this is so naive it's near insulting. It's not just draw "Something". It's draw enough sprites to account for the endless possibilities of creations.

Let's say we had just ten base items. Ten things that people could combine however they like. All of the combinations comes up to 45. However, lets say you add in the two kind of alchemization, && and ||. Suddenly the amount of combinations is 90. Now then, we could stop there and say that items already alchemized can't be alchemized again, but that would piss off the players. So now repeat the process with 90- 8010 sprites. And of course, you'll have the players who want to combine more past that, and we're getting around 64 million possible combinations.

But even at that, people will be bored as fuck combining the same 10 items, no matter how many ways we give them. Bump that up to 100, which still seems small, and we're dealing with 990, 979,111, and if we allow alchemization past that, we're nearly at 1 trillion sprites.

Of course, texture reusing can save for some of that, but we'll either have to stick with that and have it be boring, or a lot of the alchemization will have to involve completely unique sprites.

Now then, past the problem of killing your spriters, you have to face the issue of fitting all of these sprites into the game. If each sprite is, say, 80 by 80 pixels, and therefor ~19 kb, and you want to limit the space your sprites take up to 1 gig, then we're at a limit of about 55,000 sprites. If each item needs an average of 3 sprites (these items will be used, of course, and therefor need multiple sprites), and we're down to about ~18,500 items. This allows us to have either:

4 base items, able to undergo three alchemizations.
12 base items, which can be alchemized twice
OR, 130 items that can't be alchemized with anything else after first being

We're either cutting the quality of unique items by making them all stem from the same tiny pool of items, or we're telling people that once something has been alchemized, they're out of luck. And even then, that's a meager 130 base items, if our method of making these unique sprites is "god forbid having the spriters draw something".

Now then, I suppose I will throw out my "alchemization idea", which is based on the same concepts that made the game scribblenauts able to support endless creativity. This is a lot like the "concept + attributes" that gets thrown around a lot, with the shape of one item being altered by the attributes or textures of the second. Now, the way scribblenauts handles this, if you haven't played it, is to have first a set of generic sprites. These can be then altered via the use of adjectives- "colossal" will change the sprite's size to be bigger, "rainbow" adds a rainbow texture, and "winged" adds wings to a fixed position on the sprite.

The way that this would be used in alchemization would be to take every base item and define it in two ways with its code: The shape (a base sprite) and attributes (say, spiky, rainbow, huge). Every "shape" corresponds to a base sprite, and every attribute corresponds to either a sprite, a texture, or a size, all of these defined via variables and functions and whatnot (like I've said before, my programming knowledge is minuscule, but I would have to imagine that this is possible, albeit complicated).

To give an example, let's say you combine a hammer with a porcupine. Let's say that a hammer is defined as "Shape: Hammer - Attributes: Brown" and porcupine is "Shape: Ball/Rodent/(whatever generic shape that would get good use besides for a porcupine) - Attributes: Spiky". Now then, let's say that the first item determines shape, and the second item attributes. However, attributes from the first item will appear so long as they are not overwritten by ones from the second item. To determine what overwrites what, attributes would be given classes defined with their variables- Texture (Such as brown) size (default 80*80) and extras (spiky). the alchemizing code would determine that the end item needed "Shape: Hammer - Attributes: Brown, Spiky". Shape from the hammer, brown from the hammer (As its class was unique) and Spiky from the "Extras" class of the porcupine.

So now we have a code that is telling the game to create a sprite with the shape of a hammer, using the base hammer sprite. It is then given the texture "brown". Finally, spikes are added on the same way that wings can be added on to things in scribblenauts, as extra sprites/animations on top of a sprite that is already there. I could see this being done either with the base sprites having fixed points on them where these extra sprites could be attached, or that the program would detect the edges of a sprite and attach things there, with adequate rotation. However, the latter seems like it would need a rather complicated function to pull off, the former would probably be just as much so, and both would probably create a lot of graphics problems in the beta stages.

That said, this is basically the only way I could see alchemization working. It has to be procedural- we can't sprite for every possible combination that someone will think of- but it also has to be incredibly simplistic, at least initially, so that your programmers have something reasonable to work towards. Not to mention the fact that it has been proven that this was possible. It also has to have every be very defined and logical- this is because while a computer can follow directions perfectly (if they're coded perfectly anyways) it sure as hell can't reason. If you want to have a chainsaw with blades on it, you're going to have to tell it explicity to attach the sprite of a blade to fixed positions on the sprite of a chainsaw. You're not going to be able to program it to reason on its own what parts of what goes on what, so the best you can do is give it a procedure to follow- but that's going to take a lot of very intuitive work by your programmers.

Not to mention, I don't actually know how possible what I proposed actually is. It seems like it's doable, but the thing that both you and I lack that's the real reason we aren't getting anywhere with just concepts is that you have to actually know how what you're talking about works, and how it's possible. You say you've never coded a game, so how do you know which of your concepts are and are not realistic? Some of the things you've proposed- like what I mentioned earlier, with a chainsaw with blades added on- simply aren't. I'm not into game design, but the thing is, I do a lot of research in artificial intelligence and intend to actually go to college to study it intensely as my life's work. And the thing you're describing with the program just knowing "oh, put blades on the chainsaw" ? That kind of creative reasoning is the kind of thing I'm trying to work towards discovering- I can assure you that you're not going to have a game designer come up to you and say "Poof, the computer can reason now." Yes, you can set up a function to explicitly tell the program how to deal with certain variables (like attributes that I mentioned earlier) and define them with sprites or stats or what have you, but again, explicitly is the key word here.

But anyways, this brings me to my next point-

Second, I do know what credentials you need to get into the gaming industry. You need to either be a collage graduate with a friend decently high in said company, or you need to be the winner of a gameshow. Anyone that actually believes that the modern game industry is any better than that is sorely mistaken.

>Anyone that actually believes that the modern game industry is any better than that is sorely mistaken.

I'm sorry, but you're faulting the game industry for requiring the designers to go to college and study game design? That's completely inane. Seriously, replace "Gaming industry" with medical industry and look at how it reads. Of course doctors have to go to college, they're fucking doctors, no hospital is going to let some random dude come in because he has a good idea of how medicine works. It's the same with the game industry, and if I was a game designer who had spent years in college learning what the hell I was doing, I would be very insulted to hear that you thought my education was just some way of getting into an elitist society of game designers.

What you're missing is that there's a reason that the gaming industry requires those credentials- because you sort of need them to know what you're doing. The people who design games, even indie ones, spent a lot of time studying and practicing and learning to get to where they are. What you're basically saying is that you're some god given gift that's just able to design a game. You're forgetting that past the need for creativity, which hell, you may have, there's a whole bunch of technical knowledge of how things just work that is completely essential, and you lack it. To bring back the painting metaphor, it's not even like you've never painted before- it's more like you've never painted before, and you want to paint in three dimensions. Taking away the fact that you don't know how to paint in two dimensions, and you're ignoring the fact that there's a lot of technique and knowledge that goes into that, you want to actually defy what is even possible.

And when we say this is impossible, it's not like putting a man on the moon. It's more like driving the man to the moon in a car or something. Not to mention, the people who defied that impossible were incredibly brilliant, and had actual college degrees in fields that allowed them to know what they were doing. They we're just random guys who thought it was possible.

So yeah. Basically, before you even worry about the logistics of the game, it -may- help to humble yourself a bit, and realize when you're in over your head.

[Frost]

I am hoping to have a concept trailer up within two months

If your concept trailer is anything like this- that is to say, a statement of intent with no actual game content- I'd advise against it. It won't cause as much hype as you think. If you hadn't already gathered, Fan Projects has become pretty jaded about a Sburb project, such that people will want to see actual proof of progress before they throw their chips onto the pile.

Better to aim for something that indicates real progress. A gameplay demo, a well-written and complete design document, some real concept art, descriptions of how you're going to handle the worst design issues. Yes, I'm sure you're going to include some of those anyway, but I'd much prefer to see, say, a dozen pieces of usable and well-thought-out concept art, rather than a trailer that indicates two months of wasted effort.

[darkDetective]

Okasen

show spoiler

hide spoiler

Alright, considering that I just read your entire paragraph, I think it would be a little bit fair if you actually went back and read about what exactly me and Frost were talking about.

But even at that, people will be bored as fuck combining the same 10 items, no matter how many ways we give them. Bump that up to 100, which still seems small, and we're dealing with 990, 979,111, and if we allow alchemization past that, we're nearly at 1 trillion sprites.

I did the actual math with one of the programmers last night, and you are blowing it so out of proportion that it is almost scary. Why don't you please leave the math to the programmers.

That said, this is basically the only way I could see alchemization working. It has to be procedural- we can't sprite for every possible combination that someone will think of- but it also has to be incredibly simplistic, at least initially, so that your programmers have something reasonable to work towards. Not to mention the fact that it has been proven that this was possible.

Oh, great, you described everything I just described. Thank you I guess? We will be proving it possible before even the pre-alpha tech demo is released.

Now then, I suppose I will throw out my "alchemization idea", which is based on the same concepts that made the game scribblenauts able to support endless creativity. This is a lot like the "concept + attributes" that gets thrown around a lot, with the shape of one item being altered by the attributes or textures of the second. Now, the way scribblenauts handles this, if you haven't played it, is to have first a set of generic sprites. These can be then altered via the use of adjectives- "colossal" will change the sprite's size to be bigger, "rainbow" adds a rainbow texture, and "winged" adds wings to a fixed position on the sprite.

I have played Scribblenauts, and it is an ingenious system. It would make a fantastic system for alchemization.

That's it.

If you have played Scribblenauts, you would know that combat isn't really a focus. There is a reason for that. You create a spiked humongous mouse and you have NO IDEA how it would fair against a lion. This is what would make it great for a alchemiter to just play around with and terrible for graphics or gameplay. What we are planning on doing is a system with all the combat essential items done by hand, and all the modifiers being basic additions to the more advanced sprites.

God forbid the spriters actually draw something

This was a misunderstanding between Frost and I. Frost thought I wanted to create a system where the computer automatically generated the sprites (I believe, sorry if I'm wrong Frost) and I was trying (and obviously failing) to present my idea of sprite reuse.

If I may ask a question, will the game be in top-down, sidescrolling or isometric perspective?

Naturally sidescrolling would be the easiest to produce.

I was thinking isometric with possible 3D character models to make weapons and outfits easier to make. We would do our best to stay to the Homestuck art style in 3D, and if it fails we would probably scrap it and go into traditional isometric.

I was also going to discuss the other two options with the game designer I'm meeting with today.

Better to aim for something that indicates real progress. A gameplay demo, a well-written and complete design document, some real concept art, descriptions of how you're going to handle the worst design issues. Yes, I'm sure you're going to include some of those anyway, but I'd much prefer to see, say, a dozen pieces of usable and well-thought-out concept art, rather than a trailer that indicates two months of wasted effort.

I was debating whether or not to do a cinematic experience, but if you guys don't want it I guess there is no point.
The tech demo we want to get out all at once, and since it is three parts that might take awhile. The alchemization will be out as soon as we have think it is ready and tested it for basic bugs. I am actually writing up a design doc since the designer I am trying to hook asked for one last night. If all goes well I will meet with him tonight. After maybe a few revisions, anyone interested on joining me online I will be able to send a design doc as well.

[Okasen]

I did the actual math with one of the programmers last night, and you are blowing it so out of proportion that it is almost scary. Why don't you please leave the math to the programmers.

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.

So I'd rather you not insult my math skill, because at this point the only way I can see those numbers being wrong is if you had a different process for determining what can be alchemized. Honestly, the fact that you're starting to get snarky with the people who are offering you critique is going to doom your whole project. As for offering up the same idea you just posted, I never claimed to be being totally unique in my idea. I was offering a much more in depth explanation past "put blades on a chainsaw"

[Tyrannic]

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.

[Legendary]

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.