Return to “Announcements”

Post

Re: The State of Limit Theory Development, 2017 Edition!

#137
Great to see Josh posting again, I have the utmost confident in you that you will finish Limit Theory since the Dark days. Keep it up, and I believe you can do it.

I have a general interest in game development, and would like to know a bit more about the limit of 100,000 lines of codes.

My basic instinct would be same as yours, dividing up the codes. As you have stated, dividing it up did not solve the problem, does this mean having multiple programmers working on it won't make a difference? Cuz none of the programmers fully understand what the codes actually means, and can't debug them as they have no idea where the codes contradict themselves.

Not sure if Josh would ever read this, could anyone have a basic understanding of programming answer? Thanks in advance. :ghost: :ghost:
Post

Re: The State of Limit Theory Development, 2017 Edition!

#138
Roarer wrote:Great to see Josh posting again, I have the utmost confident in you that you will finish Limit Theory since the Dark days. Keep it up, and I believe you can do it.

I have a general interest in game development, and would like to know a bit more about the limit of 100,000 lines of codes.

My basic instinct would be same as yours, dividing up the codes. As you have stated, dividing it up did not solve the problem, does this mean having multiple programmers working on it won't make a difference? Cuz none of the programmers fully understand what the codes actually means, and can't debug them as they have no idea where the codes contradict themselves.

Not sure if Josh would ever read this, could anyone have a basic understanding of programming answer? Thanks in advance. :ghost: :ghost:
one more thing, I get the feeling that Josh excluding the game codes from this 100,000 lines limit, is it true? If so, why?
Post

Re: The State of Limit Theory Development, 2017 Edition!

#139
Hi, Roarer. I'm not Josh, but I am a long-time programmer who's written a few games (none you've ever heard of), so let me try to answer your question.

The simple answer is that the more programmers you add to a project, the more time they have to spend communicating with each other about their code than actually writing it.

Let's start with one programmer. He's working on a project that will take one month of coding to complete. He knows everything about all the code because he wrote it all.

Now let's say instead that this project gets assigned to two programmers. Each programmer knows half the code. In theory, by dividing the work of a one-month project between two programmers, working simultaneously it should take them half a month to finish the project, right?

This is a popular theory. In practice, what actually happens is that the two programmers have to communicate with each other about what their code does... and every minute, every hour, every day they spend telling each other how their part of the code works is time that is no longer spent actually writing code.

So instead of two programmers taking half a month to finish a one-month project, it's likely to take closer to something like three weeks.

Now let's really run with the idea of splitting up code -- let's say there are four programmers. At this point, you should be guessing that it's not going to take only one week to finish this project. ;) Nor will it get done any sooner with five programmers, or twenty, or a hundred. In fact, very quickly all the communication about the code that has to happen will cause the total project time to exceed how long it would have taken with just one programmer.

There are processes that people have invented to try to reduce communication time. Some help; some are just busy-work. None of them let you turn a one-programmer job into a ten-programmer job that's finished in one-tenth of the time.

If you'd like to know more about this effect, a very famous book (in programming circles) was written by Fred Brooks called The Mythical Man-Month.

So that's one reason why Josh may be reluctant to let someone else help him with the code. There may be others:
  • Josh is an extraordinary programmer. Even if he brought in some help, he'd still be doing most of the work.
  • Did I mention that Josh is an extraordinary programmer? He probably codes so fast that he'd spend all his time telling the other coders what he did.
  • The work that Josh is doing right now is not straight gameplay programming, which is simple by comparison.
  • To put it another way, once Josh can do straight gameplay coding, it's likely to go very fast. He won't need help with that.
  • Finally, Josh has never shown any sign whatsoever of being willing to let anyone else help him with the programming. That probably isn't going to change.
So, all things considered, Josh farming out some of the coding for version 1.0 of Limit Theory seems very unlikely to happen.

But if the version of LT that Josh ships implements much of the gameplay in a scripting language, you'll see mods start to appear the same day. :D

Note: I interpreted Josh's comment as saying he had hit about 100,000 lines of code in total, meaning engine, scripting, everything. I could be wrong about that, though.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#140
Flatfingers wrote: ...lot's of good explanations...
Yeap, correct. So a 1 man-month project does not make sense with more than one programmer. However, I feel you make it too "unattractive" to work in team. So...

Let's take it now from some other perspectives:
  • Assume a 500 man-months project. That's a pretty standard stuff (budget: 3-5M$), say a medium-large R&D project in my (chemical) industry. Assume for simplicity that you find a guy with talents for every task in the project: He could do it alone say in 1/2 of the time (very optimistic assumption - it assume 50% of the time over all team member is lost to inefficiencies. That's more than 20 hours per week) and get it done in 250 months. That makes over 20 years! Your project is obsolete before you make a fraction of it.
  • Alternatively, let's assume a small 50 man-months project (3-4 years for your lone fighter, sounds feasible): how likely is it that you will find one guy with talents and knowledge for all facets of the job? very unlikely. Even in LT: a good programmer (implementer) may not be a good guy to design, define and balance an economical system. Of to design a good GUI efficiently. Or to animate a backer/fan community. Or to have previous experience with many languages in order to know without months of testing what actually has a chance to be appropriate. In this case, some communication in the team will be more than compensated by the fact that each team member actually knows his job and does not have to learn from scratch.
  • Finally, while two implementers are not twice as fast as one implementer, two designers are usually more than twice as creative as one designer. It is because creativity comes from interaction and from different perspectives. So any product will be better if several people participate in the design.
  • Wait... what was Josh's problem? More than 100k lines in his head? This is solved routinely in teams by having clear packages with clear interfaces - yeap, this cost time, but hey, that means it is feasible to have software with more than 100k lines!
For all of these reason, the "cost" of communication and coordination of a team is more than compensated by what you get: speed, competence and better product... oh, and you actually can get a product in the first place!
The exception may be very smallish products, or projects to learn, or art; so things where efficiency is not desired or required - and that have no backers waiting... the other (not valid! but frequent) exception is the Diva-syndrom: this is my precious, not sharing anything.

And again: having a team forces you to define clear objectives, boundaries, interfaces, communications. That means: it forces you to structure and plan and this is obviously what does not work so well when enthusiastic brilliant amateurs try to chew a first large project.

In short, and in my not so humble opinion: Josh is factually wrong to try to make this project alone. This is probably one of the main reason that he is loosing years of his youth to find a solution to industry-standard problems by trial-and-error. At the very least he should have a "board" of (experienced) people to discuss concept, plans, issues and schedule if he wants to implement alone. Such people are a dime a dozen on this forum who would willingly help for free, so cost and availability is not a factor.
And this statement remains valid even recognizing his huge talent :thumbup: - just nobody can do such project efficiently alone.
Image
Post

Re: The State of Limit Theory Development, 2017 Edition!

#142
To Flatfingers' excellent explanations, I can only add something of a personal speculation.

The issue is not really that Josh has hit 100k lines of code, which is why I wrote in the PAX thread that the RAM analogy was terrible. The 100k number is meaningless. Another ambitious procedural project, Ultima Ratio Regum, had 420k lines of Python code back in March, and the developer has shown no sign of fatigue since then. No, the issue is that Josh's 100k lines of code probably do too much. This directly contradicts Josh, but, well, my intuitive feeling is that Josh is wrong about his own explanation:

The difficulties have everything to do with what his codebase does. And that isn't Josh's fault at all, in fact it's not a fault as such -- merely a result of his ambitions leading to an exceptionally complex game, probably involving extremely complex programming (in terms of programming constructs), to the extent that he's had to construct another language on top to manage it all (LTSL).

The only judgment of Josh I'm willing to make is one that's based on another speculation. His search for simplicity in code -- and people from 2012-2014 will remember his passion for it in the dev logs, and his enthusiastic updates heralding reduced codebase size -- has turned out to be a costly delusion. The irony of his situation that he probably has a very elegant engine, but the added complexity of the elegance has made it very difficult for him to work with it.

Let me be very clear. I have nothing but the greatest respect for Josh. He has my full support in everything he does. If he went to KS a second time I'd support him in a heartbeat. The guy has set out to truly deliver on a living, breathing universe, no compromises. And that's a gargantuan undertaking. I have trouble even conceptualizing the whole thing and he's out there actually coding it. But I feel the 100k lines of code thing is a misleading marker. If you have to have an analogy -- it's the CPU that's overheating, not his RAM that's insufficient. I would trust Josh to handle a simpler project of ten times the size. But this is no simple project -- and the number of lines of code has little to do with it. The question at hand is primarily one of performance, and secondarily that of Josh working with his engine without it turning into a nightmare for him.
Post

Re: The State of Limit Theory Development, 2017 Edition!

#143
I like this forum. The level of discussion (information + civility) is remarkably high.

CSE, you're right that I was using a one-person project as my baseline to explain why "twice the people means half the time" can be a fallacy. As you correctly point out, that doesn't have to be as fallacious for a big project. If it's so big that one person couldn't possibly do it in a reasonable time, then you have no option but to throw more people at it. There are still communication costs; they're just smaller as a relative proportion of the overall effort compared to the coding and testing.

But the time-to-complete curve will eventually turn upward again for any project at some point. IBM -- no stranger to Big Projects -- was for a time notorious for its management's faith in "human-wave" programmer allocation. Eventually communication costs catch up with you.

The question of interfaces is a little trickier. Once team size grows above three or four people -- less if they're virtual -- it does help to specify a general form of interfaces. This keeps the overall flow among modules consistent, which saves time in debugging and modification.

But there's still/always the more specific task of deciding what data to pass via an interface. Having a standard format, while useful, won't save any time on the "what fields do you need?" conversations that have to happen when different programmers are connecting their systems. It's this interface-conversation time that adds up.

And then there's the project management time spent keeping everybody's designs consistent, and scheduling when each system needs to be completed for the other systems to work properly, and resolving the inevitable personal conflicts that flare up when people (i.e., more than one person) have different but inflexibly certain opinions on the Right Way to implement some feature... etc., etc. :P

alpan: also agreed. 100K is not a magic number applicable to all programmers, or even all game programmers. I suspect you are very right that the elegance that Josh has described seeking in his code probably makes 100K of JoshCode equivalent to 250K-500K of not-JoshCode....
Post

Re: The State of Limit Theory Development, 2017 Edition!

#145
scousematt wrote:
alpan wrote:The 100k number is meaningless. Another ambitious procedural project, Ultima Ratio Regum, had 420k lines of Python code back in March, and the developer has shown no sign of fatigue since then.
In one file.

420k loc in one file.

Heard a podcast recently where the URR dev was talking about starting another file due to daily crashses of his editor.

Crazy.
This is why real programmers master includes :D

URR is a crazy project, way crazier than LT ever aimed to be.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: The State of Limit Theory Development, 2017 Edition!

#146
Flat: we love having you here too :) :D

I remember hearing about this story years ago regarding the first built A380 by Airbus :
"Everything was going well until the different engineering groups inside Airbus forgot to talk with each other and the result has been nothing short of catastrophic…"
" but the real problem was that the different engineering teams were using incompatible versions of the CATIA design software, which led to all sorts of miniscule, but critical mismatches in connectors."
I'm just piping in that even the big boys get it wrong from time to time.. but they got there in the end. :D

You can read the full story/ article here.
YAY PYTHON \o/

In Josh We Trust
-=326.3827=-
Post

Re: The State of Limit Theory Development, 2017 Edition!

#147
Silverware wrote:
scousematt wrote:
alpan wrote:The 100k number is meaningless. Another ambitious procedural project, Ultima Ratio Regum, had 420k lines of Python code back in March, and the developer has shown no sign of fatigue since then.
In one file.

420k loc in one file.

Heard a podcast recently where the URR dev was talking about starting another file due to daily crashses of his editor.

Crazy.
This is why real programmers master includes :D

URR is a crazy project, way crazier than LT ever aimed to be.
I'd like to add that Python code is a lot simpler than C++ or C code. More than I could possibly emphasize. Certainly more than four times. 400k+ lines of Python code probably translates to less than 100k lines of C++ in terms of complexity.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: The State of Limit Theory Development, 2017 Edition!

#148
You also have to remember that at some point, you need to take your hands OFF some parts of the code and call them 'complete'.

If I write a game with SDL, I'm not going to commit the entirety of SDL's library code into part of that 100k limit. It doesn't make sense. Instead, I'll use their API documentation.

If you're going to manage a large project, you need to be able to offload parts of the project; whether it's an entire library, or a single function.

I can guarantee that I don't have a limit nearly as high as 100k lines of code. Mine is probably closer to 20k. But I wrote a little datafile maker/loader (and Sly even made me a neat little front-end for it too! :D ), and if I ever need to use datafiles again, I'll use it. I don't need to understand the code again, because I wrote my own API documentation so I can just reference that (it's a good thing too, because I forgot the inner workings :ghost: ).

If I were to write a large project, I'd have to set it up so that I'm revisiting parts of the code as little as possible.
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: The State of Limit Theory Development, 2017 Edition!

#149
To add a little science into the discussion about man-months and why dumping more dudes on a project doesn't always make it go faster, there is a similar phenomenon in computing itself with regard to parallelization of algorithms. It would seem like if you have a program that ran in 12 seconds on one processor, you could run it in 6 seconds on two processors, or in 3 on four processors.

This is only theoretically possible, since you have some overhead from the scheduler in the operating system and also that most programs have some things that have to occur in sequence. It's Amdahl's Law, which is related to the concept of diminishing returns.

For project development, it's rather similar (which is kind of meta). You might be able to throw four people at a library/module/namespace and flesh that out in quick time, but you won't be able to really allocate much (if any) working time to other parts of the codebase which were designed to depend on it. Certain things have to happen in sequence, so throwing more people at that will just end up with some people tinkering with the coffeepot in the breakroom. Too many cooks spoil the broth, and too many programmers hamper development.

Grab a deck of cards and make sure it's shuffled. Now, sort it, with each suit ordered (A, 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K), and with the deck ordered (Clubs, Diamonds, Hearts, Spades). Doing this by yourself will take a couple minutes. Then you can grab a friend and you split the deck. You each throw down your cards into piles of each suit, and once you've sorted all the cards into their suits, you sort each suit. One of you takes the red suits, the other one takes the black suits. You both pile the suits back into a deck.

I've done this exercise with some people before and, while there were speed gains, it definitely wasn't a perfect inverse relation to the number of people sorting.

Four four people works pretty well too. You split the deck four ways and pile up the suits. Then everyone sorts one suit. You can do a few variations on this with more and more people but eventually it starts slowing you down (we reached that point after about 6 people). Consider the extreme case, where you have 52 people and everyone is holding one card. Now you have to sort people by having them compare their cards or organize in different corners of the room. Chances are you'll take longer than you did with doing it by yourself.

It is possible that there would be some benefits to Josh having a small team of maybe three or four people, but Josh would probably have to take at least a couple days getting the team situated at the office and they'd have to dedicate some time to breaking up what tasks remain and what model they're going to follow. This is part of that communication overhead everyone else has talked about.

Is it worth it to Josh to hire sous-programmers? Does the amount of work and the kind of work remaining lend itself well to being broken up, or are we awaiting our master mason to place the last few keystones on his arch? Couldn't say, and it's not my call. But while Amdahl's law might not hold the answer we're looking for, I'd imagine Brook's Law does.
Shameless Self-Promotion 0/ magenta 0/ Forum Rules & Game FAQ
Post

Re: The State of Limit Theory Development, 2017 Edition!

#150
Indeed.

So we all agree while there is some gain of putting more manpower, it is not as high as one could hope.

But as DWmagnus said with SDL - there are some components that can/should be done independantly, similarly to using a library. Yes it means accepting some limitations as set interfaces should be followed (but it is a bit more flexible, as the "library" author is one office away if really required to make a change).
Any anyway, if you did your planning phase correctly, you already have a pretty clear idea of what data should be available. So you know what characteristics a ship, or a planet, weapons, or... should have and can start from there.

In the context of LT, there are many things going in this direction:
-> all the procedural generation code (ships, systems) can be done independantly from the rest
-> the strategic/tactical AI, probably even with smaller granularity (merchant AI, general AI) that could later be plugged in a CEO AI.
-> the AI for first person fighting (seems to exist, though)
-> the market development also (sinks, sources, pricing, LOD)
-> obviously the rendering (but this seems complete)

Once you have the concepts and the code running, OK, you may need to retouch it because of a new feature from the ship guy that request a change in the fighting-AI, but this is minimal compared to the whole work package and in many case optional (no, this feature is not included in 1.0).
So in such a project, I assume there is at least place for 3 people:
-> rendering, graphics, GUI
-> AI (probably this job is also for the master that manage the core)
-> procedural generation, economic simulation

And I guess 3 guys would have an acceleration factor >3 in this particular case because also they would have together more experience and loose less time in (ultimately failing) trial-and-error that has cost almost 2 years to date.
Of course, this reflection was valid 4 years ago. Today, I guess this is too late - probably the only thing that would help is an advisory board helping to streamline, cut features, accept (enforce) compromises and generaly bring experience and control.
Image

Online Now

Users browsing this forum: No registered users and 6 guests

cron