Return to “General”

Post

Re: Don't release the code yet

#46
Silverware wrote:
Mon Oct 01, 2018 3:04 pm
You haven't worked much with complex code have you?
You mean, apart from things like writing parts of the Windows operating system, or JVM's, or Compilers, or PC Emulators, etc...?
If you don't build in this capability from the start it's bloody nightmarish to implement later, much better to build the entire gameplay aspect from the same interface that the modders will use, that gives you the most flexibility later on, and the least effort refactoring.
I know very well - from first-hand experience over many, many years - how much better it *would have been* to build in modding ability; but things have changed.

Given the codebase as Josh has described it, if he releases the source, and if someone builds anything on top of it, it would be a much bigger effort to fix and complete the Lua/C interface and write the game according to the last plan Josh espoused, than would be reasonable. As Josh said, it would be years more effort.
Apart from that, don't forget that a modder would have ultimate access to the source code going forward, and wouldn't need a limited, scripting language interface to mod the game anyway, and if you even did all these things, there's no telling if it would actually perform well enough to play as a game.

My approach as I've listed, is borne solely from the need to strip down the engine to the minimum viable product; and to build a game from there in the shortest, easiest, most distributed way possible. It means cutting out a great number of features, and the ability to mod any subsequent game via a scripting language is very high on my list of things that should die given the highly limited functionality they would bring.

Putting it simply, would you rather have a game you could play, or a game engine that you could mod?

I totally accept that your priorities for a game are different to mine, and modding may be the one thing you wanted, but I think we can definitively state that you're not going to get that now, so from here on, you might want to alter your expectations.
--
Mind The Gap
Post

Re: Don't release the code yet

#47
Silverware wrote:
Mon Oct 01, 2018 3:04 pm
Ringu wrote:
Mon Oct 01, 2018 2:38 pm
Definitely. Personally, I'd drop the Lua/modding stuff completely: the interface isn't finished, and is a massive distraction from writing either the engine or the game
You haven't worked much with complex code have you?

If you don't build in this capability from the start it's bloody nightmarish to implement later, much better to build the entire gameplay aspect from the same interface that the modders will use, that gives you the most flexibility later on, and the least effort refactoring.
And maybe that approach to somehow have everything fully moddable, thus including a script-interpreter, was what wasted the majority of effort. Leaving it out might just be what is needed to allow finishing it into a full game.

There are many games with a large modding community where the engine only allows modding by changing data (where everything is basically datadriven, with well documented XML/JSON and binary leveldata), instead of allowing to change the processing logic.

And if there is really a need to allow a mod alter gameplay-logic, just offer a thin network-layer. Where the game accepts well defined packages to alter entity state and respond to queries about the world-data.
The mod then has to implement the networking and internal processing logic by itself, sending and receiving data in a well defined package format.
-> The game would then profit from running natively with full performance in code compiled from C, and optionally process commands coming from the networklayer.
This saves the hassle to have everything in the game run over the LUA interpreter. The network-layer commands could be extended if need be later, starting with supporting to change basic entity actions, spawning entities and responding to queries about the world, entities and current events / playerstate.

Plus: the mod can be written in any language of the modders liking. (just needs to open the a socket to the game, and implement the package format)
Last edited by Damocles on Mon Oct 01, 2018 4:25 pm, edited 2 times in total.
Post

Re: Don't release the code yet

#48
Dinosawer wrote:
Mon Oct 01, 2018 3:28 pm
It's more that it's more work to rip it out now - the game is Lua, on top of a C engine, and that's already implemented. Removing moddability would be more work cause you'd have to move all the Lua parts back to C.
Well, we know that 'the game is Lua' isn't really accurate: there isn't a game right now, Lua or otherwise. Plus, if there was the basis of a game in place, it wouldn't be as big a job to complete as Josh is suggesting.

It seems to me that there are a great many unknowns about the Lua/C bridge still; its' capabilities, its' performance, the fundamental nature of the components it implements, any bugs it has; I believe, based solely on what's been said previously (and my 35 years of development experience, 20 of which was on operating systems and language compilers), that discarding this part of the codebase would make it easier to create at least a basic game.
--
Mind The Gap
Post

Re: Don't release the code yet

#49
The modding question is tough.

If we were just starting out, for an experienced team, I'd say go for it; for a first-timer lone wolf project, I'd say just make the game.

However, given that Josh seemed to have solved the FPLT to his satisfaction some time ago, I suspect Silver and Dino have the stronger argument: it would be tougher to rip that out now. Can't know for sure either way without looking at the code, though.

I think it also matters a lot that coding gameplay features in Lua versus C eliminates a large and significant number of possible coding hassles. When there's a lot of gameplay code to write, and you -- the actual game developer -- can write that code in a simple language, the possible savings in time becomes significant. And although Josh chose not to go this route, if you can farm some of that feature coding out to less-gifted programmers because the language is simple, that's even more time savings.

So even though we talk about it in terms of support for player mods, it seems to me the real advantage of integrating LuaJIT is that everybody can crank out features faster than if they have to buy a C compiler and fight pointer bugs.

Thus, while I think I was ambivalent about making the LT engine support modding back when we first started talking about it, I came over to thinking it was a rational tradeoff of development time because in theory it would significantly speed up Josh's own later coding of gameplay features.

In hindsight I might decide otherwise. But given what we knew at the time, and especially after Josh announced that he'd solved the FPLT, I think "support LuaJIT integration" was a reasonable call.

Now, of course, if Josh does release the kraken code, we'll need to see how far Josh got in letting the engine actually support coding most of the game's features in Lua.
Post

Re: Don't release the code yet

#50
Bear in mind that these are *my* biases coming into play; I've written C since before many people on here were born, so it's as natural as breathing to me.

My development instinct is saying that in LT 1.0, modding via Lua is a great feature to have; a bit of luxury. Writing the whole game in Lua is a big achievement, where you're sacrificing low-level power for the ability for someone else to see, understand, and change your whole philosophy.

But in the situation we may soon find ourselves, where we might have a codebase that doesn't compile, doesn't run if it did compile, and isn't a viable game even if it did compile and did run, there is one fundamental choice that has to be made: do you try and make LT 1.0, or do you make ~LT-0.1 ?

The codebase will tell us if it's easier to strip out the Lua bridge and rewrite any useful scripts back into C, or if it's easier to carry on the development path and continue writing in Lua. It's only my instinct that's saying there be dragons down the latter path.
--
Mind The Gap
Post

Re: Don't release the code yet

#51
I recall Flat once saying "Build the game with the expectation to throw it away" -- with the meaning that your first iteration will be thrown out as you rebuild certain pieces in order to improve upon it.

At the same time, from my experience in performance music, you want to play through the piece first before you start practicing different parts. If you were to chart your proficiency over the course of the piece of music, it would look like a line graph with lots of peaks and valleys. You focus on the valleys to bring those up, while making sure you still go over the entire piece once in awhile (also bringing up your peaks) until you have a much more consistent line, that's much higher than when you first started out.

Same thing with programming. Complete something first, then go back to the rough areas. If you all you do is re-work the areas that are functional to be even more pretty, all you have are the pretty areas. It doesn't matter if you have to take shortcuts or whatever, as long as the idea is that you'll revisit them to take out your hard-coded work-arounds or the band-aids you put in place. Better to have a game with nothing but place-holders here and there as long as you have something.

Then again, that's mostly my style. I'm not a professional programmer, so I can't compare it to what's considered 'industry-standard'.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Don't release the code yet

#52
There's a tendency in any technical field, as the years go by, to get cynical about new concepts. "Pssh. That newfangled stuff is just people who have no actual skill coming up with fancy buzzwords I don't understand as a way to complicate the work. Why, in my day we had a [compiler and text editor] | [hex editor and front panel toggle switches] | [rock and a lump of mud] and we managed just fine."

I admit I feel that way about any number of currently fashionable systemic "solutions" that promise to improve software development: wedging lambda expressions into languages, open-plan offices, The Magic of Agile [Something], Culture of Accountability, the Three Ways, etc., etc. In part it's because I've lived through previous phases where some VP hears that other companies are all adopting some amazing system for getting more code out of coders, then declares that we must also embrace this critical new thing. So out they trot ISO9000, or TQM, or IITP, or some other revolutionary replacement for hiring skillful programmers, and the Senior Managers chant, "Yes, It's Awesome, and We Will Earn Bonuses By Hitting A Magic Number For Reported Uptake of This New Thing." And the experienced programmers look at each other, and say, "Um, sure, yeah, we're totally using it right now," and then go back to what they were doing in the serene assurance that this new thing will be forgotten after a year and carefully never mentioned again. And so it always proves.

Well, what does that leave us with, then? How's programming ever supposed to improve? What actually works to make coding a little easier?

If there's an answer to that, I suppose it can only be hard experience that reveals the truth of some facts about system design as practiced by finite, fallible human beings. Fred Brooks popularized at least a couple of these: "Just throwing more coders at a project makes it later," and "Build the first one to throw away -- you will, anyway" are rubrics that sound nuts to people new to software development, but which every ancient dev considers too obvious even to mention because they've personally seen what happens when clueless managers pretend that the limits of human nature can be mitigated by imposing some new process.

There are others -- rules of thumb that are known and applied not because they promise to compensate for human limits but because they respect and work with those limits:

"You can't see all the bugs in your own code."

"The most productive teams have people who value the complementary gifts of the other members."

"A good system today is more valuable than a great system tomorrow."

Absolutely there are exceptions to rules like these that recognize human limitations. But they're exceptions. The experienced-but-not-yet-cynical developers know when to make the occasional exception without deciding that the rules of limits don't apply to them and their coding processes and their code.

Working without a team as a new developer is perilous because it takes away the easy path of learning the truth of rules like these by seeing their benefits in action. Maybe learning them yourself the hard way helps the lessons stick better... but that education comes at a price.

Anyway, we're just swapping stories here until a decision is carried out on the LT code front.
Post

Re: Don't release the code yet

#53
Ringu wrote:
Mon Oct 01, 2018 4:11 pm
Dinosawer wrote:
Mon Oct 01, 2018 3:28 pm
It's more that it's more work to rip it out now - the game is Lua, on top of a C engine, and that's already implemented. Removing moddability would be more work cause you'd have to move all the Lua parts back to C.
Well, we know that 'the game is Lua' isn't really accurate: there isn't a game right now, Lua or otherwise. Plus, if there was the basis of a game in place, it wouldn't be as big a job to complete as Josh is suggesting.

It seems to me that there are a great many unknowns about the Lua/C bridge still; its' capabilities, its' performance, the fundamental nature of the components it implements, any bugs it has; I believe, based solely on what's been said previously (and my 35 years of development experience, 20 of which was on operating systems and language compilers), that discarding this part of the codebase would make it easier to create at least a basic game.
If what you say is true, then you have a point, but as I understood it from the devlogs the engine/Lua split is complete, and what we have are some scattering of game systems in Lua already (the economy and the generation of system connections and the GUI system Josh has been talking about, Lindsey's procedural fighters and so on), and a ton that have yet to be ported from Python or whatever it was, and a ton that have not even been written yet.
I guess we'll see when and if the source is released.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: Don't release the code yet

#54
My 2¢ is that I'd like to see the code, mainly out of curiousity. Of course, a decision should be made on the licensing and terms of release and there's no rush on my end. Didn't have time to read prior posts but a quick thought suggests the options are:
  • Release the code using a permissive (MIT?) open source license. People can do what they want with it, including profit from it
  • Release the code under a copyleft (GPL/CC-BY-NC?) open source license. People can do what they want but can't directly profit from it.
  • Release the code using a 'better' license for backers than for the general public (they funded it after all). So maybe backers get an MIT-style (or proprietary) license, general public get GPL?
Mainly though, I'd like to see how the graphics-related bits were done. I'm an experienced dev but I've never done any graphics work (business/web software, not games). It'd be an interesting source of inspiration for me if I ever wanted to do any 3D work of my own.
Nobody suspects a Toreador …
Post

Re: Don't release the code yet

#55
I'd just like to agree with ToreadorVampire, seeing the code under some kind of open source licence would be the best thing in my opinion if josh is truly committed to abandoning the project. (I'd totally be willing to throw money at a second kickstarter but by the sounds of things hes quite burnt out at this point) The only other option as I see it (other than just throwing all this hard work in the bin) is to auction it, which is a terrible idea since whoever or whatever aquires it could lock it in some sort of IP vault never to see the light of day again, just go watch "noclips" documentary on GOG to see how hard it is to get the legal right to resurrect abandoned games.

Additionally since this game was intended as a totally proceedurally generated systemic sort of "living" universe of sorts, it would be very interesting to see what could become of it if it was ever taken to a playable state. Seems like the perfect engine/game to experiment with deep learning, as the AI has a lot of emergant behaviour.
Post

Re: Don't release the code yet

#56
Just to toss in my two bytes, the mod code (if functional) might be the only viable content pipeline if you don't want to go low level. [Not all of us live and breathe C/C++.] I could see community LT development broken into two teams; the engine team works on functionality and systems while the content team adds assets and scripts for the engine to digest. That's a big hairy IF, but it might be a manageable way to handle it.

Regarding the idea of a backer license, I like it. It adds value to the people that supported the project.
--
TAZ
Post

Re: Don't release the code yet

#60
I cannot more strongly advocate against not releasing the code. Firstly and foremostly because he said he would, even we he didn't have to. Good headspace or not, doing so is him giving everything he has, even in its incomplete state, to the KS backers, which I for one feel that they deserve.

Could he sell the code to a different studio instead of releasing it? Yes, I suppose he could, but I think he should let the KS backers vote on that, as well as whether or not he should take the proceeds of such a sale and provide refunds. However given the responses from the community and the backers, I'd guess that the outcome would be around 85% saying no, just release the source code. 10% saying sell it and issue refunds. and 5% saying sell it and restore your personal savings.

In releasing the source code, he gives the project a chance at a future and his labor will have done far more good than just teaching him some lessons. In shelving it, he would be solidifying the notion that he wasted much of the last 6 years of his life.

After all consider what it would mean for him to put LT on ice for 4 years while he goes back to school or finds a new job... by 2022, the code will be quite outdated, his memory of how everything worked will fade, and when he comes back to it, it will be but a monument to his failure. If he sells the code to another developer, there is a high probability that they would take it and mutate it into something neither the community, nor he would approve of as they try to get a ROI by mining it for what they can find useful while discarding the rest. In releasing it, LT would also mutate, but it would do so by the hands of a grateful, creative, and likeminded community that retains a similar if not identical dream.
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can

Online Now

Users browsing this forum: No registered users and 5 guests

cron