Miscellaneous Bugs And Questions That Don't Deserve Their Own Thread Thread

Hay Guys, can someone bring me up to speed, what did i miss,what's going on an' stuff. what can i do to help?

PS: sorry for using the forum to promote my fb page,not sure if that is against the rules.

Things are a bit slow at the moment but i know there is an important discussion coming up about the compound system, while things on the programming side are also slowly (but surely) progressing, specifically on the subjects of compound system, microbe editor, new models being implemented and to a lesser degree gui and sound!

I'm not sure how up to date you are, but thats the most recent information I can give you!

I'm back after a long time.
Have i missed anything? I was busy.

Read the post directly above yours. Also, the Applications subforum was not the right place to originally post your thread.

Hi.

(Haven't found anything similar on the forums...sorry if already discussed. Please, link if it was).

As real world evolves, and aiming to a multi-architecture and multi-platform product, this game should be based on HTML5, Javascript, canvas and SVG.

PS: As I suggested here, I have added a suggestionID to help linking it on the wiki.

Wow wow there, thats a bit of a steep suggestion!

While a web-based platform would help reach a greater variety of platforms, such as smartphones, tablets and niché things like ChromeOS we are already planning on supporting Windows, Linux and Mac with our current structure.

There are a lot of reasons why switching to a web based platform would be a bad idea:

• We would have to throw away a large amount of work. We have a very well functioning engine created by very talented programmers that would nearly all have been for naught.
  
• Performance would be noticeably worse, which will become a major concern in the later stages of development, while things like graphics can be handled effeciency on a web platform, there are a lot more to the development of this game than that, which makes a fully interpreted language a bad idea.
  
• If we chose to offer the game as a web service (why would you distribute a web-game locally), all the assets and code would result in heavy amounts of downloading and long loading times.
  
• We would need to find a completely different group of programmers. While we don't have a lot of developers current doing the programming, it would still require new people with a completely different skillset and with different interrests. Personally i would probably not want to continue programming on a web platform.
  

I really don't see a big advantage to switching, but I will add that I'm not an expert in the web platform area so if I'm mistaken in some of my assertions, feel free to correct me.

crovea wrote:

Wow wow there, thats a bit of a steep suggestion!

Indeed!

crovea wrote:

While a web-based platform would help reach a greater variety of platforms, such as smartphones, tablets and niché things like ChromeOS we are already planning on supporting Windows, Linux and Mac with our current structure.

Glad to hear.

crovea wrote:

There are a lot of reasons why switching to a web based platform would be a bad idea:

• We would have to throw away a large amount of work. We have a very well functioning engine created by very talented programmers that would nearly all have been for naught.
  

Sometimes is good to step back to take impulse. I see your point.

crovea wrote:

• Performance would be noticeably worse, which will become a major concern in the later stages of development, while things like graphics can be handled effeciency on a web platform, there are a lot more to the development of this game than that, which makes a fully interpreted language a bad idea.
  

About graphics: It's possible to use Hardware aceleration (&GPU) to render on HTML5 canvas.
About language: check "javascript vs c performance" on google. You could be surprised.

crovea wrote:

• If we chose to offer the game as a web service (why would you distribute a web-game locally), all the assets and code would result in heavy amounts of downloading and long loading times.
  

Actually there are alternatives to use a "mixed" approach, having online interface and local data. If you have interest, I can investigate on this subject.

crovea wrote:

• We would need to find a completely different group of programmers. While we don't have a lot of developers current doing the programming, it would still require new people with a completely different skillset and with different interrests. Personally i would probably not want to continue programming on a web platform.
  

You probably have your reasons not to code for web. Anyhow, I understand your concern.

crovea wrote:

I really don't see a big advantage to switching, but I will add that I'm not an expert in the web platform area so if I'm mistaken in some of my assertions, feel free to correct me.

The main advantage it's the approach itself. A web-based game will probably be easier to update, change and evolve than a C++ one.
There could be other advantages, like a wider distribution or becoming a valuable online educational resource.

Regards.

While I agree with some of the possible advantages of what you propose (portability, relative ease of updating), it's simply not a valid alternative to what we're doing right now. Thrive has been designed from the start to target PCs (windows/mac/linux), and much of what we want to do isn't feasible on a web based platform, either because of processing requirements or the interface.

As Crovea mentioned, we also have a lot developed in our current engine, and quite a bit of momentum, and switching architecture would waste all of that. C++/opengl/ogre may be fairly old now, but there are relatively few workable alternatives.

Also, while we appreciate suggestions like this, and it sounds like you know what your talking about, you need to provide a lot more details if you want us to take suggestions seriously. Specifically, you've said we should switch to this architecture, but provided very little information about why we should. You provided more info in response to Crovea, but some of that and more should have been in your first post.

darwin.the.gamer wrote:

It's possible to use Hardware aceleration (&GPU) to render on HTML5 canvas.

I awknowledged that in my first response ^^ What i was saying is that there is more to it than graphics, and other things will require a more solid platform regarding performance (see below).

darwin.the.gamer wrote:

check "javascript vs c performance" on google.

I tried and couldn't find any benchmark or articles in favor of JS in terms of performance, could you link to what you might be referencing?
Ultimately i have a hard time imagining an interpreted language being faster than a natively compiled one.

darwin.the.gamer wrote:

The main advantage it's the approach itself. A web-based game will probably be easier to update, change and evolve than a C++ one.
There could be other advantages, like a wider distribution or becoming a valuable online educational resource.

I'd say that creating a patcher (making updating easy) would be significantly easier than recreating all our work in JS/HTML5 etc. Evolving and changing might be faster due to easier language constructs but also more limited due to the limitations in terms of libraries and OS permissions.

Seregon wrote:

While I agree with some of the possible advantages of what you propose (portability, relative ease of updating), it's simply not a valid alternative to what we're doing right now.  Thrive has been designed from the start to target PCs (windows/mac/linux), and much of what we want to do isn't feasible on a web based platform, either because of processing requirements or the interface.

Although "design a game targetting a specific platform" it's not always a great idea (the game should tell you which platform to use), I understand you worries.
I still see a lot of advantages on Web platform, as rapid evolution, but to my understanding you (the few involved in this project) aren't interested in this approach.

Seregon wrote:

As Crovea mentioned, we also have a lot developed in our current engine, and quite a bit of momentum, and switching architecture would waste all of that.  C++/opengl/ogre may be fairly old now, but there are relatively few workable alternatives.

I don't care about throwing away things if there not in the "correct" way, but I understand (apart of the correct term), it could be frustrating to people involved in the current version.

Seregon wrote:

Also, while we appreciate suggestions like this, and it sounds like you know what your talking about, you need to provide a lot more details if you want us to take suggestions seriously.  Specifically, you've said we should switch to this architecture, but provided very little information about why we should.  You provided more info in response to Crovea, but some of that and more should have been in your first post.

This proposal can be seen from different angles, but thinking on the game itself, there are a lot of possibilities is the game is mobile-oriented.
Even we are doing this in our spare time, selling features or pieces could help us to get some income and spent more time doing what we (some of us) like.
Mobile environment has a wider distribution, and if the game is properly designed, it could be not also funny and beautiful, but a way of paying bills.

As the world is daily more Web-oriented, i still consider this a smart step, perhaps having lower quality graphics or simpler 3D meshs...but still worthing it.

crovea wrote:

I tried and couldn't find any benchmark or articles in favor of JS in terms of performance, could you link to what you might be referencing?
Ultimately i have a hard time imagining an interpreted language being faster than a natively compiled one.

Don't loose the point. Native compiled language is faster, but not as much faster as you may think.
Chrome parser is (much) faster than Firefox, but anyhow here you got some links:
http :// arstechnica . com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/
http :// www . stefankrause . net/wp/?p=144
https :// blog . mozilla . org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/

Maybe something like thing could be a great "mixed" approach?
http :// code . google . com/p/nativeclient/

crovea wrote:

I'd say that creating a patcher (making updating easy) would be significantly easier than recreating all our work in JS/HTML5 etc. Evolving and changing might be faster due to easier language constructs but also more limited due to the limitations in terms of libraries and OS permissions.

You are comparing Oranges with Apples.
Creating a patch for C++ and releasing for clients is harder than doing it in Javascript.
Creating a Game in C++ is equally harder (maybe easier, due to documentation, engines...?) than in Javascript.
Of course, remaking its not funny.
Nothing to say about permissions...don't think we need "any".


Again: I understand your reticences, you have good reasons. I only think it worth to be discussed. (And I'm enjoying it)

Seregon wrote:

C++/opengl/ogre may be fairly old now

openGL will not be outdated for a looong time. There are no contestors. (DirectX windows only), even darwins approach would use openGL.
C++ and ogre are still under quite rapid development, their age doesn't degrade their usefulness!

darwin.the.gamer wrote:

but to my understanding you (the few involved in this project) aren't interested in this approach.

You have hit us in a bit of a low period for activity, there are quite a few more people you just aren't seeing atm. A change in this direction would probably be up to the programmers and while I haven't known Daniferrito and Nimbal (the real lead programmers) for a long time, I suspect they feel the same way as I do. But yes I will happily discuss the merits with you, as long as it remains constructive!

darwin.the.gamer wrote:

I don't care about throwing away things if there not in the "correct" way

This is a very idealistic approach, but thats not to say that it's not a valid one. Companies like blizzard will easily do this 10 times over to reach where they want to be, and while this project really wants to get things done the right way making it a prime candidate for this approach, we still have to consider resources if this game is to be ever completed. If another approach was clearly the right one, i would be in favor.

darwin.the.gamer wrote:

there are a lot of possibilities if the game is mobile-oriented.

From my understanding, the entire reason this game was conceived was to create a better alternative to spore, as spore was incredibly dumbed down (also had some really questionable decisions to boot). Going mobile ultimately means creating a very simplified version of the game, both to conform with very limited hardware but also to conform with limited and varied interface. I think a mobile approach would work against the philosophy of this project, but perhaps some of the founders should speak to this.

darwin.the.gamer wrote:

funny and beautiful, but a way of paying bills.

The question of money has been discussed extensively many times.. There are no bills atm, and if we came in need of money a kickstarter would be our first approach? "We" don't want to sacrifice anything in the game for the sake of making money. (If I'm not speaking for everyone, please correct me).

darwin.the.gamer wrote:

As the world is daily more Web-oriented, i still consider this a smart step

We aren't really looking to reach out as far as possible, we aren't a company trying to maximize income. But that obviously shouldn't mean that we shouldn't take free opportunities to branch out. However this argument is poor on it's own in this context.

darwin.the.gamer wrote:

Don't loose the point. Native compiled language is faster, but not as much faster as you may think.

This is true, and I am quite biased as a performance addicted programmer. Regarding your articles, the first one is certainly interresting but it seems to strongly couple our expected performance with the firefox parser.

darwin.the.gamer wrote:

Chrome parser is (much) faster than Firefox

Again I am biased as a firefox loyalist but I hear quite the opposite.

darwin.the.gamer wrote:

You are comparing Oranges with Apples.

You're right, it's not a fair comparison. A server side approach would certainly be easier to update.

darwin.the.gamer wrote:

Creating a Game in C++ is equally harder

This is subjective and also has to do with scale of the project.

Overall you seem to want the project to scale down to a smaller game and then choose a more objectively appropriate platform. But the question then seems to be, do we want to scale down the scope of the game?

Again, trying to be brief:

• Do you think something like Native client or asm.js (Compile C++ into Javascript, so having "near" native performance, while running on web) its a viable option?. I'm sorry to repeat myself, but it seems to be a good move.
  
• Web oriented gaming its not only for paying bills/income (seems I didn't explained myself properly). It's for using the Web platform itself. A wider distributio could mean a wider support (kickstarter or not) and a long-living game. I dont agree with you that Web/Mobile implies simplicity. I even imagine this game be upgraded by my kids...if it were Web-made.
  
• I don't want to scale the project down to a smaller game, i want to divide it in smaller pieces to make it real. Since I started reading about it, I love it each day more, but I think you (we, if you let me in) have a BIG challenge in front of us...Divide and conquer.
  

-------

https://thrivegame.canadaboard.net/viewtopic.forum?t=1403