Return to “General”

Post

Re: Don't release the code yet

#31
Hi Flat,

Your question about the code being sufficient to form the base of a playable game..

..I take this from the kickstarter:

Well, I will prepare the source code for release. It's not a working game, and in my frenzy to get things working I've left huge swaths of code in a half-refactored or half-complete state. But releasing it is the least I can do. I don't imagine it will be of any use to anyone, other than as a monument to a failed dream. Perhaps those who are interested in game engines will glean a thing or two from the engine, as it is a fairly solid piece of engineering, much more solid than the Lua game code.

Doesn't sound like it mate!

By the sounds of this unless Josh does another kickstarter and picks this up again it doesn't sound like anybody else would be able to make 'head nor tail' of it either....could be wrong tho?
Post

Re: Don't release the code yet

#32
While I hesitate to dispute with Josh, I know what it's like to be too close to a project I care about to assess it objectively.

I think it's also fair to note that Josh was pretty upset (as any serious creator would be) to have to declare his six-year effort over. And we know he could be a bit of a perfectionist (although it's not always fair to assume that for specific things; sometimes coding is just hard).

So I conclude he may not be in the best place to see right now how much he's accomplished. I don't think anything would be hurt by having someone else go through the code to arrive at an independent understanding of how close or far it is from a complete architecture... especially since, if he just dumps the source, that assessment is going to happen anyway.
Post

Re: Don't release the code yet

#33
Flatfingers wrote:
Mon Oct 01, 2018 11:33 am
that assessment is going to happen anyway.
I'd guess that'll happen multiple times by different people; and they'll all reach mostly different conclusions as their ideas on what's needed to progress to a game is different.

Based solely on what we've been told about the various components, it seems to me that there's a lot left before you could consider this a viable game engine. It doesn't have a proper render pipeline, nor asset management, and it's lacking in the specialised procedural components too, like the universe generation and recall.

If I were going to take this forward - and I'm not; there's too much work here for me to do in a reasonable timeframe - the first thing I would do would be to get it to run without the command-line fiddling, and get it to the point of displaying a single system. Then I'd create enough objects to be able to build one ship and one landing platform. Tie those objects together and connect them to game code to provide user control (this may be retrievable from the PAX demo code). Place the landing platform on a moon or asteroid, put the ship on the platform, and let the user fly.

Once you've got that, put a basic HUD in place, and everything else can be done by independent people over time.
Add more objects to create more ships, tie each object up to game code for that specific function, and work out ship upgrade/construction.

By the time you've got enough to have a couple of different-looking ships, you can add NPC's and enemies, along with basic move-attack-defend AI, and you've got something like the PAX demo.

From there, you add more objects when you want to provide more functions and things for you to do (guns, mining lasers, cargo holds, scanners, warp drives, etc.) This becomes the gateway to everything else in the universe.

When you've got enough of that, then you can add groups and factions and economies and all the in-system bits, and then finally you can add the inter-system selection, travel, generation, etc.

It's a lot of work, but that's the way I'd tackle it. Forget using a proper game engine style approach because it'll take too long to get the basics; instead do it piece-meal and strip out unfinished bits as you encounter them, and you'll have the best chance of making something work.
--
Mind The Gap
Post

Re: Don't release the code yet

#34
I'll give a +1 to what Flat and RIngu said, and add:
if it's feasible for us to make LT as community project, I'd strongly suggest leaning towards a "Early Access" development model - what I mean there is, build towards a basic but working game first and then expanding that into the game LT is supposed to be, step by step, keeping the game functional along the way.
As example, I think the first long term goal would be to make something that is more or less feature wise equal to the original Freelancer - control one ship, combat, piracy, trading, missions, and so on, in a finite universe and with not yet everything dynamic and Ai driven. And then from there replace placeholder systems with AI, add multi ship ownership and RTS, production, factions, and so on, step by step.
The reason for this is:
-To get something people can play with relatively soon, people have waited 6 years already
-Let's be honest, hobby projects tend to drag on and run out of steam. This way, if we don't manage to finish it, there'll be at least something people can play and enjoy, even if it's not the full LT experience yet. And having something that works is more motivating to keep working on, I think.
-Not everyone wants every feature LT is supposed to have - for example, Victor has stated many times all he wants is basically Freelancer 2.0. This way we can make something those people can already be content with beforing delving in further and making it the best space game ever :D
-I think this will make it easier to get features working as well. It's easier to make a fancy feature if you're just replacing a placeholder in an already working 'whole' than writing it from scratch. Say, easier to replace randomly spawned missions like in Freelancer with missions provided by AI, if all the other stuff is in place (mission board and combat and dogfighting etc)
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

#38
Ringu, that sounds to me like a very defensible plan.

The main concern I have beyond those individual features and their sequencing is performance. The reason why the architectural stuff matters so much is because there's a lot going on. The pieces don't exist independently; they affect each other. It's not at all unlikely that a well-designed engine and several redesigns may be required to keep the game playable as more simulationist features get added. (And that's assuming every individual piece of Lua code is written with maximal efficiency -- almost certainly an incorrect assumption.)

Also, not just anyone can do this sort of thing. You either have to already have hard-won experience at optimization, or you have to discover the tricks as you go, such as synchronizing with drawing frames. So it's not just tech; personnel matters, too. (And if it's a group effort, having people with both tech and social skills matters enormously.)

So I'd endorse your plan as a starting point. It's good. I'd just also build in some time for integration and testing. A systems-heavy game demands those.

My question was: where on that list can a team start? How much, really, on the engine side is complete?

I don't know.

Talvieno wrote:
Mon Oct 01, 2018 12:54 pm
I think you guys are moving way too fast. :lol: I think it's very possible Josh may change his mind about releasing the code after he's stepped away for a while to distance himself. Making plans on what to do with the source may be a bit premature.

I'd be 100% fine if he reconsidered simply dropping the code.

If your comment is a serious request that we not discuss "Whither LT?" just yet, of course I'll comply. Otherwise, my comments are hypothetical -- they're "what if," not "when."
Post

Re: Don't release the code yet

#39
Flatfingers wrote:
Mon Oct 01, 2018 1:11 pm
Talvieno wrote:
Mon Oct 01, 2018 12:54 pm
I think you guys are moving way too fast. :lol: I think it's very possible Josh may change his mind about releasing the code after he's stepped away for a while to distance himself. Making plans on what to do with the source may be a bit premature.

I'd be 100% fine if he reconsidered simply dropping the code.

If your comment is a serious request that we not discuss "Whither LT?" just yet, of course I'll comply. Otherwise, my comments are hypothetical -- they're "what if," not "when."
No, not at all! Just want to temper expectations of readers just in case they think this conversation means "Josh is 100% definitely releasing the code", so nobody gets mad if, by some chance, that doesn't happen. :) It seems slipping out of the Community Manager role may be harder than I would have anticipated.
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: Don't release the code yet

#42
Flatfingers wrote:
Mon Oct 01, 2018 1:11 pm
Ringu, that sounds to me like a very defensible plan.
I wouldn't go so far as to call it a plan, for exactly the reasons you mention: more like a general attitude and approach.
The main concern I have beyond those individual features and their sequencing is performance. The reason why the architectural stuff matters so much is because there's a lot going on.
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. And even then, there's no guarantee that what's left will even work, let alone perform. My best guess is that since the PAX demo worked, we could probably get that level of performance if continued C development were to take place.
Also, not just anyone can do this sort of thing.
QFT. I've done it before, and I remember the long years of building up experience in so many different areas before I felt able to take something like this on. I certainly wouldn't do it again.
My question was: where on that list can a team start? How much, really, on the engine side is complete?
I'm very interested in seeing what people think about that, if they do get the chance to look at the source.
The reason I put the first thing as running the app and displaying a procedurally-generated star system was because a) we know that bit used to work, b) should be relatively stand-alone, and c) when you've got that far, and can figure out how it worked, you'll know everything you need to about the codebase. Anything not involved in that process (apart from utilities like the physics/collision systems), IMO, would be trashed and the rest of it just built natively for speed of development and performance.
Talvieno wrote:
Mon Oct 01, 2018 12:54 pm
I think you guys are moving way too fast. :lol: I think it's very possible Josh may change his mind about releasing the code after he's stepped away for a while to distance himself. Making plans on what to do with the source may be a bit premature.
Heh. As Flat said, I consider this a hypothetical discussion only.
--
Mind The Gap
Post

Re: Don't release the code yet

#44
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.
°˖◝(ಠ‸ಠ)◜˖°
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()}`);

Online Now

Users browsing this forum: No registered users and 11 guests

cron