[BG Official] Brickadia Hate Thread

Author Topic: [BG Official] Brickadia Hate Thread  (Read 50916 times)

What do you mean by "Expensive"? If their goal is to add mod support eventually and they do not have time constraints, why does it matter how long it will take?

What do you mean by "Expensive"? If their goal is to add mod support eventually and they do not have time constraints, why does it matter how long it will take?
scope is a perfectly valid constraint here. all of the devs obviously have lives and expenses that need to be covered, so blowing up scope needlessly is going to take away from their lives and take development longer to complete. i'm not worried about how long it'll take, i'm worried that the scope will become so large that they'll have to cut it out of development entirely or settle for an inferior solution. in the past i've heard talk about just riding along with UE4's obstructive front end baked packaging system which is already a huge hint that the scope of mod support has become a little too big at this juncture

it doesn't matter what expense we're talking about when i refer to 'expensive' whether it be time money or sanity. it's still more expensive. designing scalable and modular software is already the most important aspect of programming as a whole, and obviously doing it later will make everyone's job harder.

i dont know the internal landscape of brickadia, but if mod support was a massive priority it would be the first thing that the devs would want to show off, well before their building controls or procedural brick grids. introducing new mechanics to an open-ended sandbox game is moot when you consider that all of the mechanics can be designed in post on top of a well-made plugin system, even by the community
« Last Edit: August 19, 2019, 05:07:24 PM by PhantOS »

What do you mean by "Expensive"? If their goal is to add mod support eventually and they do not have time constraints, why does it matter how long it will take?

Cost in software can equate to many things. Something that is expensive can literally cost money, can take excessive amounts of time, or result in inferior quality. In this example, cost and time constraints are eliminated or reduced, so the depreciation of quality is increased. You may end up waiting a significantly longer time for an inferior solution, because the cost of change over time is exponential, not static or even linear.

A change that costs, say, 10 hours in the design phase could cost 500 hours during development or greater testing. Adding mod support to a big complicated game very late in development could equate to years of work. Furthermore, the cost of a change and the actual work put into a change isn't 1:1, nobody works at 100% efficiency. You're not actually going to spend exactly 500 hours on a 500 hour change. You'll lose some quality. The bigger the change, the bigger the difference, the more quality lost, exponentially. The sooner you start the better.

This is obviously more of a problem when you're designing multi-billion dollar systems for IBM, but I imagine the concept should hold true no matter what software you're building

this entire thread is mental procrastination

Cost in software can equate to many things. Something that is expensive can literally cost money, can take excessive amounts of time, or result in inferior quality. In this example, cost and time constraints are eliminated or reduced, so the depreciation of quality is increased. You may end up waiting a significantly longer time for an inferior solution, because the cost of change over time is exponential, not static or even linear.

A change that costs, say, 10 hours in the design phase could cost 500 hours during development or greater testing. Adding mod support to a big complicated game very late in development could equate to years of work. Furthermore, the cost of a change and the actual work put into a change isn't 1:1, nobody works at 100% efficiency. You're not actually going to spend exactly 500 hours on a 500 hour change. You'll lose some quality. The bigger the change, the bigger the difference, the more quality lost, exponentially. The sooner you start the better.

This is obviously more of a problem when you're designing multi-billion dollar systems for IBM, but I imagine the concept should hold true no matter what software you're building
thanks for tell me something i already know and not answering the actual question 😔


i dunno if you two are doing this on purpose or what but the way you say these things suggests you're talking from a viewpoint of someone looking in on development philosophy as opposed to someone who has even secondhand knowledge of basic game design principles, it's hard to dredge up a response because you're going through roundabout ways to describe completely simple forgetin concepts

i just think it would be cool to have more block building games to play ¯\_(ツ)_/¯

thanks for tell me something i already know and not answering the actual question 😔

Well I clearly answered what expensive means in this context and how the lack of a time constraint doesn't guarantee perfect quality software so I guess I just didn't understand the question.

as opposed to someone who has even secondhand knowledge of basic game design principles

I have minimal game development experience, I have experience with and tertiary education in software engineering. Rectangles and squares. I don't know which "basic game design principles" you're referring to but if I had to guess I'd imagine they abstract from "basic software design principles"

i just think it would be cool to have more block building games to play ¯\_(ツ)_/¯
^^^

i honestly hope im able to convert my vehicles and static maps over to brickadia just as easily as i was able to get them into blockland.
or for that matter make it like every vehicle, weapon, playermodel, brick, print, etc made for blockland. if not then well. guess im not playing brickadia.

i honestly hope im able to convert my vehicles and static maps over to brickadia just as easily as i was able to get them into blockland.
or for that matter make it like every vehicle, weapon, playermodel, brick, print, etc made for blockland. if not then well. guess im not playing brickadia.
why would anyone want stuffty disgusting ports when you have buildable vehicles

why would anyone want stuffty disgusting ports when you have buildable vehicles
They're not that bad, IMO

why would anyone want stuffty disgusting ports when you have buildable vehicles
because if i wanted to build vehicles then ill go play brick rigs

If i cannot port blockland addons over brickadia, i wont play the game
Sounds reasonable
« Last Edit: August 22, 2019, 06:29:13 PM by Sylvanor »

static maps already dont have a place in a building game, but with brickadia's procedural brick grids and stuff then it really won't be needed

static maps already dont have a place in a building game, but with brickadia's procedural brick grids and stuff then it really won't be needed

Well, not only that, but you can also make a proper map in Brickadia!