SourceForts 2.0 Design Diary

In this second Design Diary entry, we will be sharing a major gameplay change to SourceForts 2.0, codenamed "Raptor", that is being discussed and refined. This is a Design blog, so all of this is tentative. Most importantly, this is a chance for YOU to weigh-in and tell us your thoughts and ideas for this concept!


2. Building: Evolving the Building Metagame
SourceForts is a two-headed monster: half combat, half building. It's no secret that the building side is what probably draws people to the game, offerring a unique experience where you can shape the battlefield with your own creations. However, the concept is a lot better in theory than it is in execution. In designing SourceForts 2.0, one of our major goals is to make building more interesting, and most importantly, more fun.


In the first Design Diary, we outlined a major change being made to the game as a whole: the removal of the build phase. Such a change addresses some major problems, but also tips the scale towards the Combat side of things. We don't want to reduce the role that Building plays in SourceForts at all, so we began to look into how we could add more depth to the building metagame.

We've talked about adding new blocks, adding bigger blocks, adding blocks with functions or powers, so on and so forth. Unfortunately, all of these ideas ran into their own host of problems, and too many new complex mechanics might just overcomplicate the game into an even worse mess. However, we are now working on a single, elegant system that should maximize the potential for new and interesting gameplay, giving players new tools and abilities to be used for Building, while simultaneously minimizing potentially problematic side-effects.


Block Combos
A simple concept: Block A + Block B = Block Z


So far in SourceForts, as much as the game has changed, building has stayed relatively the same. The only way players can use multiple blocks for a single purpose, is to stack or layer them. Not really very interesting or enthralling.

Now, we are proposing a system in which blocks can literally be combined to produce new, unique pieces. We are unsure of what the exact block dimensions will be in SF 2.0, but Khuskan bammed up a piece of concept art to simply convey the idea:


(click to enlarge)

This shows a simple and obvious block recipe, with a few regular blocks combining to form a single, large block that is used as a wall segment. This new block would have the advantage of a larger size, maybe with more hit points than its smaller component parts. Obviously, this block recipe is nothing to shoot your load over, but it's merely the most basic of block combinations.


Recipe System
Players should be able to quickly and easily find out the equation or recipe for any number of block combos. Maybe at the press of a button, a little tree-menu can pop-up showing different block combinations and how to make them.

Recipes can vary wildly, with some simple easy-to-cook Combos being obvious (2x3 + 2x3 + 2x3 = large wall piece), and more specialised Combos which may be harder to accomplish (Two Blue 1x5s + Two Red 2x3s = ???), creating mini-objectives for some players to chase if they wish.


Community Weigh-in
We have some cool ideas being tossed around for different block recipes, like big siege-ramps, jump pads, teammate-healing blocks, deployable bunkers, on and on and on. With blocks being relatively easy and quick for the dev team to produce, maybe we can look forward to seeing new "flavor-of-the-week" blocks being regularly added to future versions.


What kind of blocks and recipes would YOU like to see? Newbie or veteran, Cactus or Azlan, we want to hear it. Feel free to post or PM your ideas, thoughts, comments and suggestions. Your ideas are always valued, and hey, it saves us the trouble of having to think up a ton of shit!

just from my point of view if you had say 30 combos wouldnt that be an exorbitant amount of skins you would have to make? otherwise it sounds interesting. also since i make a map occasionally would these combos (if they come about) be available to mappers to place or would they only be made by doing the combos in game?

__________________
11:29 p.m. - ☢ AZgAg: did the fgd was moved?

"Newbie or veteran, Cactus or Azlan"
Though I can't quite place what it is, something about your analogy here seems very flawed.

On topic:
The first problem that comes to mind is that you'll have to come up with a relatively believable way for the blocks to become the item you want them to be. Do they just disappear and something appears in its place? do they go into a spiffy animation and morph into whatever they're supposed to end up being?

With the prototype you described, players would have to go around collecting various kinds of blocks, while making sure other players don't take the blocks they've already gotten, and then proceed to select all those blocks(which are likely all stacked on top of eachother) and then proceed to use whatever mechanic you create to assemble them all. Given the confined space of haven maps I've seen, that's likely going to cause issues, especially since everyone else will by vying for the same space to put their shit. Consider as well that said player is doing all this instead of progressing to the next point, or worse yet, trying to do this *to* progress to the next point (as he would be if he were trying to make a jump pad or siege ramp). What you're left with here is a very cumbersome mechanic that really doesn't fit the supposedly fast pace you're trying to achieve. Unless you guys have a much more streamlined system up your sleeve for accomplishing all this, I think you're better off abandoning the blueprint idea.

I think you'd be better of implementing these sort of things as an extension of the original block menu. Say, push shift to access the normal block menu, left click to select a block, or right click to access the "advanced menu" that includes not only blocks, but a list of additional structures as well. This would be far easier to manage than a blueprint model, as well as more updatable in design. To make a complex item, you simply have to wait longer, rather than force the player to keep track of an ever increasing number of blocks.

EDIT:

I have a better idea. I'm kinda tired, so its gonna sound messed up.

Keep the blueprint concept, but instead of forcing players to collect the blocks, make it so they can build the blocks directly into the structure.

OK: Picture the skywalk prebuild, but in wireframe. That is your blueprint. To build the blueprint, you have to "heal" the blocks into existence (like you did in the haven alpha, only instead of you holding the block, the "blueprint" holds the block for you. As you heal more and more blocks into existence, the build becomes more and more complete. Any player could work on the blocks at any time, but one player could still complete it on their own.

For small things, such as bunkers, you would be able to spawn this blueprint anywhere (like the tf2 engy blueprint), but you would also be able to add map specific builds for complex walls and bases, as well as location specific entities like ammo boxes that can only be constructed at certain points in the map.

All of this could be accessed from a menu like the one described above.

That was quite possibly the worst explanation I could have given for this, so I might fix it later.

whats the recipe for the velociraptor block?

You had better fucking include a recipe for the velociraptor block

__________________

sf_skiff

My initial thoughts exactly. I want to know how you're going to pull this off well enough in a fast paced mod.

__________________

What is "fast paced" really? Quake? SourceForts 19x?

I don't think future versions of SF will be so insanely paced that you won't possibly have any opportunity to do something like this. Judging purely from the Haven alpha, players had lots of time to be standing around and building back from the front lines, and more offensive minded players had plenty of fighting to do up front.

Rest assured, nothing is going to be added and finalized without being tested first. If it's too slow, or something is just plain wrong with it, I'm sure that necessary changes will be made to fix it up. Rarely do you ever get things completely perfect on the first try, but through trial and error you find what works and what doesn't.

This sounds like a nice mechanic. I like that it offers some room for teamwork in building, letting your teammates see your plans for building without having to be told what to do.

That's exactly the problem. To make effective use of that particular system, you pretty much *can't* be on the front lines while trying to use this; you have to be well back in your own territory. While that would make sense for things like main bases and such, we're talking about ramps to get into enemy bases and jump pads and things like that which *need* to be built near enemy walls for them to be effective. I see this as a very critical flaw in your idea, one that should not be overlooked in favor of testing it out.

Consider everything you'd have to implement in order to test something like this, and then consider the time necessary to then come up with a replacement that works with a game that has been created around the original idea and then implement it. Given everything else you have to do, I'd say simply leaving things to testing is not a good idea of you can determine beforehand whether it will be flawed or not.

In b4 snowman recipe.

__________________

Raptor blocks or gtfo.

__________________

proof sol said it