STRANDED - The Game (WIP)

[omid3098]

ok, do your best

[niv3k]

Yeah, it was Irishlostboy who first pointed this out and I've adjusted the weapon positions. Thanks for the pointers though

 

 

no problem

[Pixel Perfect]

Just a note to inform you that Leadwerks Engine has been dropped as the engine of first choice for my game STRANDED.

 

I have for a while now been concerned about the support offered for this current version and with all eyes yet again focused on version 3.0 and am acutely aware of how the previous (pre 2.3) version was effectively run down leading up to, and left unsupported after, the release of version 2.3 and the tendancy of the developer to simply drop features of the engine and editor. None of this is conducive to long term development.

 

It's a great shame as I have invested in Leadwerks exclusively now for nearly 2 years and do believe in the potential of the engine but I have failed to get any indication that should I run into API issues during further development work that these would be addressed in a timely manner. As such Leadwerks is now seen as too great a risk for the investment I have to put in at this stage.

 

I will continue to work with Leadwerks in the background; as my AI development is currently underway and the test bed effectively in place (see pic below). This functionality could be ported to another engine at any point.

 

Likewise, I'll continue to visit the forum and keep an interest in what's happening here. I have made many good friends here and wish you all continued success with your individual projects.

 

All the best to a great community,

 

Pixel

[AggrorJorn]

A shame that you are leaving Pixel but I understand why.

 

Good luck with your future projects and hope to see you again with 3.0.

[Guest Red Ocktober]

yup... i find myself in the same boat... and for the very same reasons...

 

LW has been downgraded as not the first choice to complete my project either... i've been doing parallel developing with two other tools (see attached shot), and while i feel that LW provides some really great graphics and lighting, i just can't justify the time spent having to rework existing code that has been broken by arbitrary changes in the api, and functionality that has been either removed or capricously changed... for no logical reason at all... and with no warning...

 

when i see serious developers who have been here and who have supported LW from the very beginning start to 'jump ship'... well, it's gotta be an indication of something that is definitely wrong...

 

in all honesty, i walked into this with my eyes wide shut... so in the end i have noone to blame but myself... i knew the nature of things when i licensed LW... and while i did see some indication that things would get better, that indication started fading not too long after the the very first minor update...

 

i too will still be working with LW, and hoping that things stabilize... but i gotta get a product completed and shipping... so, given the current state of affairs, i too have to 'jump ship' so to speak... and reluctantly relegate LW to the back burner...

 

 

--Mike

[Rick]

Pixel, what would you say your biggest obstacle was? Since you were creating your own editor for the game, it seems like you would have had a large amount of control over what you made Leadwerks do. It clearly shows that you had the ability and desire to make your own things. So if the water wasn't the way you wanted it, (like in the case for Red), then nothing was stopping you from making your own. If you wanted decals, nothing would have stopped you from making your own. So what were the specific issues that you ran into that you couldn't fix yourself within your editor? I can only imagine these would be true bugs that Leadwerks has and not a lack of anything, as you would have just wrote it yourself. If it's just the fear of Josh not supporting any issues you find in the future, then that seems not all that valid as he's said he's not even working on 3.0 and he probably wouldn't be the one programming it anyway. He'd just be the idea man behind it.

[Guest Red Ocktober]

So if the water wasn't the way you wanted it, (like in the case for Red),

 

you miss the point Rick... again... if it were just the water thing, i've already added waves to the existing water... and i could've lived with the water we have now (well, not really when compared to what we once had)...

 

 

it's a lot more than simply the water... something you would realize if you were actually doing any real coding...

 

 

--Mike

[Flexman]

I sense some dissenters in the ranks

 

I've still not migrated to 2.33r5 and wont for some time till more of the niggles get sorted out. And I need to upgrade as this version introduces a key feature I've been waiting for.

 

But it has been a lot of work in the past, especially when documentation isn't changed to reflect new behavior, so you can't even go and look up why something isn't working anymore. A large chunk of problems come from having to reserialise assets (an acknowledged PItA) and mixing /duping old shaders/mats/models. That latter I don't see as LE's fault, just another PItA.

 

But I hesitate to upgrade as I don't know how long it's going to take, and if it's going to change in the next week or two.

 

I think a calendar with fixed update/publish dates with more stringent doc updates would go a long way. Just a matter of personal discipline which is hard when (like me) you have a brain that fires in different directions at any given tim...ohh shiny thing.

 

All I can do is sympathise with Pixel and Red who have done really cool things and have been able to borrow ideas and inspiration from. Although I'm not sure if you're going to find anything more suitable. Everything else I've looked at has problems of it's own. That navmesh/ai path editor is smart Pixel.

 

The topic name is wonderfully fitting though.

[Sooshi]

Man Pixel, I hate to see you go dude, best of luck to you...

 

it's a lot more than simply the water... something you would realize if you were actually doing any real coding...

And judging from your "screenshot", your game looks amazing

 

Damn I just realized something, ive only been using Leadwerks for 4 months ..im such a newb

[Richard Simpson]

Yeah its a shame to see you go Pixel . Glad to hear that you will still visit the forum though . Good luck with the new engine! Which one will you be using btw? if you dont mind me asking.

[Josh]

I knew focusing on the internal scene management was going to produce some temporary bugs with no immediate visible gain for most users, but I did it anyways because it will allow your games to run a lot better when they get big and complex. The improvements made in 2.32 are expressly for the purpose of allowing better published games. Version 2.x is not being dropped or discontinued. I just spent three months on stuff that ensures you can make large games with 2.x. I spend about one weekend a months twiddling around with version 3.0 code, and I am asking for input well in advance so I can have it available when I am ready to start.

[Guest Red Ocktober]

it's not the changes and optimizations you made to the scene management logic that i have issues with... as a matter of fact, that is one thing that i applaud...

 

 

it's the capricious and unnecessary changes to the api, which causes existing code to break, and existing functionality to change in an unexpected manner... that is my major complaint...

 

then when someone brings up an issue... a real issue... it is minimized or totally ignored...

 

there's no way anyone who is seriously involved in a project can conform to any anticipated deadline under these circumstances...

 

there's got to be some sort of continuity in the api...

 

 

 

--Mike

[Sooshi]

there's no way anyone who is seriously involved in a project can conform to any anticipated deadline under these circumstances...

except me

 

I cant speak for everyone else..

 

time spent complaining, can be time spent training

[Guest Red Ocktober]

well... then good luck to you Kevin...

 

and keep us abreast of how well your project progresses...

 

time spent complaining, can be time spent training

and you can tell that shiite to someone else... i've been up since 5 this morning looking over some of the latest code, and going back to an older version and getting that code up to speed... in an attempt to salvage the time i've spent on Leadwerks...

 

i've got two machines running now... one compiling LW c++ code... the other do some macintosh stuff... and i can still find time to voice my complaint...

 

and i'm sure you see Pixel's frustration as as waste of time as well... maybe he should've been training a lil more too... eh...

 

kinda hard to train for something when you have no idea what's coming... what's gonna be changed unexpectedly... but i'm sure you'll see that when you actually start writing some code for something more than a simple walkround in a level...

 

 

hey... i'm happy for ya... glad you're stuff is working fine...

 

be happy for me...

 

 

 

 

--Mike

[flachdrache]

Hä, i learn for the last 20 years and iam still not rich enough to call it a day -> Relax.

I could even die tomorrow ... or later this day, dont know.

 

Sorry that i cant be much of a help but i already gone at least twice through misgiving.

Because of this i might can say that i have a sane set of expectations though. Loosing faith is one of the main issues for indieDevs imho - so, i look in that direction.

 

Of course i too would like to have all issues sorted - that i just cant stumble over this or that milestone. I do expect that i need twice the time for my stuff as a random gameStudio would need. Simply because of engine, time, money and/or knowledge and thats just normal. For me "a indieDev" actually means to build a game beside the every day job (and there is not even a horror film about it - accept maybe the one with the rats nest in the cellar and the dude fighting the whole film and at the end he suffers severe wounds and the whole house is just smoke and ashes and the rats still survive ... ask your neighbor *eg*) which means like some hours a day work straight.

 

I dont want to bring someone down or cause disbelief but sometimes once work has to follow once possibilities to once given time ( oh no, now he starts with the fairytales ).

 

Please note that my urge aint just about decisions but the way it is - damn, i do sound like a frigging priest of darkness.

 

hf

[omid3098]

really bad news pixel.. I wish the best for you and your project. you are the most perfect pixel I've ever seen!

[sad..]

I think leadwerks needs more and more and even more staffs for engine development and support..

I really don't want to discuss each 5-6 months with my team members about same topic..

Josh, I know that you are trying very hard. but believe me, you are not enough.

[Josh]

it's the capricious and unnecessary changes to the api, which causes existing code to break, and existing functionality to change in an unexpected manner... that is my major complaint...

What API changes have their been in the last 6 months? Entity view range changed, because the new system allows much greater distance culling optimization. The sky background color started affecting the sky in 2.32, so you can adjust the background to make day/night changes. The "Render" script function was renamed to "Draw" to match the internal functions, again a consequence of the scenegraph system (cameras have a Render() method, and all entities have a Draw() method, so you can see why this is).

 

It's always hard to make a decision that effects existing code, but these had some significant benefits, so it was deemed worthwhile. The internal optimizations in 2.32 have made it a difficult release, so you may want to stick with 2.31 a while longer. The end result will be much better for your games, which is what I care about most. I can understand if you would feel disoriented at first, especially when 2.32 was first released with some bad bugs that had to be fixed.

 

For the rest of 2.x, all I have planned is bug fixes and minor feature additions. Once all bugs in the tracker are resolved, I consider 2.x finished, and any features on top of that are just icing.

[Rick]

[EDIT]

I'll remove my comments to avoid issues, but sounds like Josh has a pretty clear road map planned out here.

[cocopino]

For the rest of 2.x, all I have planned is bug fixes and minor feature additions. Once all bugs in the tracker are resolved, I consider 2.x finished, and any features on top of that are just icing.

All this talk about 3.0 has made some people nervous, but this sounds really assuring. Good to hear this Josh.

[macklebee]

All this talk about 3.0 has made some people nervous, but this sounds really assuring. Good to hear this Josh.

 

if it happens that way... history of how the later versions of 2.2X were handled suggests otherwise... but we will see.

[Josh]

Probably the biggest inconvenience we have had was caused by relying on the serialized physics files that change format occasionally. Newton 2.20 is stable and supports everything I want, so I don't see any reason to upgrade if a newer version comes out. In version 3.0 we will have our own .phy format that doesn't change, and I don't plan on upgrading to any new versions of Newton for LE 2.x.

 

There are only three open issues in the bug tracker right now, BTW.

[macklebee]

Probably the biggest inconvenience we have had was caused by relying on the serialized physics files that change format occasionally. Newton 2.20 is stable and supports everything I want, so I don't see any reason to upgrade if a newer version comes out. In version 3.0 we will have our own .phy format that doesn't change, and I don't plan on upgrading to any new versions of Newton for LE 2.x.

 

There are only three open issues in the bug tracker right now, BTW.

 

so i assume this means the destructable physics/objects will not be implemented? The new PHY format will still require us to change all of our assests' physics files or will there be a method in which this will automatically be done? Or at least a way to minimize the amount of effort and time to do this?

 

How are you going to address issues with objects passing through each other? Hopefully better than what Newton currently does...

[Guest Red Ocktober]

[edited]

 

 

@ Josh...

 

The "Render" script function was renamed to "Draw" to match the internal functions, again a consequence of the scenegraph system (cameras have a Render() method, and all entities have a Draw() method, so you can see why this is).

 

so... and just to take this one instance to illustrate what i'm trying to say... you're telling us that in the new release, Render() could not have been retained for backwards compatibility, and simply call the new Draw() function...

 

... and in the docs it would be mentioned as obsolete and depricated, and should not be used.

 

i mean, wouldn't that be preferable as opposed to simply ripping it out, thus invalidating existing code...

 

 

we're not us against you... i'm not against you... we... i... would very much like to see Leadwerks become the tool of choice... but if you're just gonna make these arbitrary chages, and then disregard user feedback when this sorta stuff is done... well...

 

this isn't the first time for something like this... why do ya think people are complaining...

 

 

--Mike

[Josh]

so i assume this means the destructable physics/objects will not be implemented? The new PHY format will still require us to change all of our assests' physics files or will there be a method in which this will automatically be done? Or at least a way to minimize the amount of effort and time to do this?

I have no plans right now to implement destructable physics. I think stability is more important right now than adding more features.

 

I don't know what the parameters of the .phy format in v3.0 will be, since it is pretty far away. It will probably be more a matter of creating the shape in the editor with adjustable parameters, or converting an .obj or .gmf in the editor to a .phy file. It will be easy.

 

How are you going to address issues with objects passing through each other? Hopefully better than what Newton currently does...

Enabling swept collisions is the way to deal with this.

 

so... and just to take this one instance to illustrate what i'm trying to say... you're telling us that in the new release, Render() could not have been retained for backwards compatibility, and simply call the new Draw() function...

I agree. It sucks to change code. I figured having the engine call two script functions would ultimately lead to more confusion and potential problems than just renaming it. I also thought the Draw() function wasn't used that frequently. Sorry for the inconvenience.

[macklebee]

I have no plans right now to implement destructable physics. I think stability is more important right now than adding more features.

 

I don't know what the parameters of the .phy format in v3.0 will be, since it is pretty far away. It will probably be more a matter of creating the shape in the editor with adjustable parameters, or converting an .obj or .gmf in the editor to a .phy file. It will be easy.

 

I vote for GMF2PHY conversion. Having to create an OBJ model file just so I can have a model that reacts to physics is a pain in the arse and seems an unnecessary step for asset creation.

 

 

Enabling swept collisions is the way to deal with this.

 

yeah, that makes absolutely no difference. Something the size of say a grenade when launched and hits the terrain just right will cause it to fall thru the ground. I know the answer is that this is supposedly a problem with any physics engine, but honestly I cannot recall the last time I played an fps game where this happens.

 

 

I agree. It sucks to change code. I figured having the engine call two script functions would ultimately lead to more confusion and potential problems than just renaming it. I also thought the Draw() function wasn't used that frequently. Sorry for the inconvenience.

 

Actually I have about 30 scripts that have to be rewritten because of this. I know your intention is to make things more user friendly but its changes like these that annoy the hell out of people. And they have to upgrade their projects to the next release, because before now we couldn't get bug fixes unless we upgraded. I think the rule going forward should be fix the current bugs before any new releases. This allows people to make the decision to either move their project forward to the newest release or just live with the current version thats bug free for their intentions.