Wishlist: Why magic paths are like mod Nations.

[MaxWilson]

Originally Posted by HoneyBadger

I'm impressed with how moddable it is too, MaxWilson, but that doesn't mean it can't be better. AI and the magic system are two areas where we lack important modding tools.

You missed the point. Even KO lacks modding tools for the magic system. Such things must be (and are) hard-coded.

-Max

[llamabeast]

I can say a lot about where, exactly, I think Llamabeast was speaking from--but I won't, because that wouldn't be politic. As far as Llamabeast's "programming experience", Llamabeast isn't JK, so there's the end of that argument.

No I'm not, but I do do a lot of programming, which gives you a feel for these things.

Anyway, look, we all agree with you that it would be a wonderful feature to have, but also I think many people feel it's unlikely and so there's no point pushing for it. If you want, send a PM to KO or JK and say you think it'd be a great feature - which it undeniably would - and then there's nothing more anyone can do and there's no point trying more to persuade us.

I'll say again, I think it would be really cool if you could add extra paths, there'd be no end of modding possibilities arising from it. I expect everyone else feels the same. It's just that I, and I believe others, feel it's a futile hope.

[Edi]

Llamabeast and Endo have hit the nail right on the head here. Having seen some of the code, and all of those little snippets in basically sections that link to somewhere else where the deeper code is located, I have no idea what that looks like.

I do have enough knowledge of programming to know that to go in there and messing with it to the extent the moddable paths would require is more likely than not render the game completely unstable precisely because the magic path stuff is linked to nearly everything. At the very least it would generate a crapload of bugs that would then have to be fixed.

And since it would require coding new UI for all the relevant parts, that makes it even more unlikely, as we have both JK and KO on public record stating that they do not like programming UI. Furthermore, Illwinter is already in the middle of a new project, so should they drop that to tinker with Dom3 on such a massive scale instead?

This thread is in my opinion utterly pointless precisely because the feature requests made in it are so preposterously far from reasonable.

[Gregstrom]

I have to agree with llamabeast and Edi. I spent a few years in game development, and far-reaching game changes at at any stage post-beta made the dev team very stressed and unhappy. UI changes were annoying for both programmers and artists.

I guess if Dom3 had been designed and developed in modular code sections from the ground up, adding mopddable magic paths might not be a huge job (it'd be a medium-large one instead). But, as we all know, it wasn't.

[Omnirizon]

Originally Posted by Gregstrom

I have to agree with llamabeast and Edi. I spent a few years in game development, and far-reaching game changes at at any stage post-beta made the dev team very stressed and unhappy. UI changes were annoying for both programmers and artists.

I guess if Dom3 had been designed and developed in modular code sections from the ground up, adding mopddable magic paths might not be a huge job (it'd be a medium-large one instead). But, as we all know, it wasn't.

getting off topic, but in this thread maybe that's a good thing...

this point has begun to intrigue me recently. In fact, I want to do some analysis of both code and interface. I've only recently become enthralled with coding and data management and design, but two things strike me as extremely relevant and yet almost ignored.

The structure of code is analogous to physical structures, and is very important for the same reason. Yet it seems to me that there is virtually no forethought going into most code structure. There are computer programmers, but no program architects. Individuals create code in what is basically a 'dark art' compared to the world it is embedded in (ie. no one but the coders understand the coding, yet the rest of the world depends on it). While the work of these individuals may be highly creative and smart, the _structure_ of their objects make no sense. How often do programs come up against insurmountable barriers due to structure problems? How often is the code to a single application completely rewritten to overcome this?

Think of how much top down planning goes into a building, or even modern cities. Buildings and cities have been built for centuries, and humans have centuries experience with them, and they aren't so nearly a dark art as coding is right now. Yet cities and buildings too face expansion and modification problems. Think how much thought actually went in to some more recent public work programs, the design of pipes, road and rail, tunnels and transportation architecture; it is currently all heavily designed with future expansion in mind.

Why do we not have this same kind of foresight in mind with coding? Computer programmers are taught to code, but not design architecture or plan for the future. Why not? Do we need 'program designers' separate from the coders who can design the architecture of the code, while the programmers create its interface?

[MaxWilson]

Originally Posted by Omnirizon

two things strike me as extremely relevant and yet almost ignored.

The structure of code is analogous to physical structures, and is very important for the same reason. Yet it seems to me that there is virtually no forethought going into most code structure. There are computer programmers, but no program architects.*snip*

Welcome to the world of large projects and waterfall design. Now you get to argue with the agile programming community about building-construction-as-a-software-metaphor and in what ways it is and is not appropriate. If you get good enough at it you can get a job at a company as a highly-paid software architect. (The architects I know are brilliant and valued highly because they ask the right questions to surface design issues as early as possible.)

-Max

[Kristoffer O]

Hi, I wanna join! Can I?

Adding new paths to dom3 and making them moddable is less likely than us making a dom4.

Programming-wise it would be a hassle. A bigger hassle than making new code. Thus dom4 is more likely. Many examples on unforeseen problems has already been posted, including UI stuff, AI stuff and gem management: how much more gem production must rise to compensate for sites being less easy to find, and how many traits a given site must accomodate etc.

Endo's suggestion on themes is way easier. Some of the theme structure is still in the code in the form of nation's dom-effects and it is partially moddable.

Adding nation based blesses is also easier by far. It just needs an entirely new modding capability and bless structure. Probably a lot more demanding than site modding.

Thematically I'm inclined to think that the need is slim. I have at times thought that the current paths could have been better chosen. You can make new magic traditions under the current system just by adding a description and possibly a nation restriction. If you want a tantric tradition you can add a couple of tantric spells to the Bandar Log, describe the practices and how this is a sister path of the astral magic.

Sex magic might be conceived as a technique deriving it's powers from necrophilia (death), wild magic (nature), carnal energies (blood with or without sacrifices) or something else. It's all in the descriptions.

At times I have thought about just having three paths. Ctonic, oceanic and olympic (or whatever you want to call them). Most phenomenon and gods fall under these three spheres. Then you could give each nation a set of unique spells associated with the three godly spheres of influence, instead of the current plethora of spells.

This would of course mean less diversity for each nation and possibly more thematic congruence. It would make my game more coherent, but would probably lessen the strategic options of the game.

Adding new paths on the other hand would not be that meaningful unless the current paths were differentiated and new effects and options were added. Death magic could be remade into reanimation, necromancy (divination and ghost summonings), darkness (including HB's shadow stuff) and unlife (drain life, cloud of death, disintegrate), but that is to some extent covered by the schools of magic. Paths overlap a bit atm, but if there was multiple new paths the overlap would have to be lesser and current paths would need to be conformed I think.

Hmm, not sure if I said what I intended, but never mind. I said something

[lch]

Originally Posted by Kristoffer O

Hmm, not sure if I said what I intended, but never mind. I said something

read as: brace for "Thank you!" storm

[thejeff]

Well, in theory there are such people. Software engineers, system designers, etc. Some of the larger and more critical software systems actually use them. And go through rigorous testing processes. Medical software, avionics controls, things like that.

There is a big difference between software and disciplines like architecture and engineering though. Writing software is more analogous to the design phase of building projects. It's much easier to modify code, no matter how badly designed than to modify an existing building. That's why you have to design for future expansion when your working with the physical world. It may be difficult to modify the code, you may even have to rewrite completely, but that's nothing compared to rerouting a highway.

More cynically, from what I've seen, most programmers are taught at least the basics and theory of design. Algorithms, design patterns, layers, etc. Then they get a job and the money people just want something that works, as quickly and cheaply as possible. This is particularly true of any kind of retail software. It gets sold based on features and maybe a quick demo, not on how sound the codebase is. If the first version doesn't sell, there won't be a second, so why spend time and money designing for it?

[llamabeast]

Yeah, Omnirizon, I think that what you suggest has already been done, very extensively, and is taught on computer science and software engineering courses. It's also true that it's far from universally known, e.g. I've been programming for years, and have picked up bits and bobs of design philosophy on internships and so on, but basically have no knowledge of serious software design theory.