cell stage graphics?

i've been messing around with roguelike games recently, how about a prototype using ASCII graphics?

If you REALLY want to do one, go ahead, but it would be a complete loss of time, as i dont think of any bit of code that could be used for the real game.

Thriving Cheese wrote:

I'm working on some 3d cells with blender.

I've uploaded apicture of a micrbe template I made and I will soon uploud pictures of some of my new cells to

Spoiler:

does this loke like a good shape?

Hey, nice work here. It's like a Metroid ^^.

PS.
Mola mucho y bienvenido tio

penumbra espinosa wrote:

i've been messing around with roguelike games recently, how about a prototype using ASCII graphics?

Heh, I remember when I suggested that. Watch out with radical ideas, people tend to really lose their Belgium.

Have you ever been to #rgrd on quakenet? Lots of rl devs there.

roadkillguy wrote:

penumbra espinosa wrote:

i've been messing around with roguelike games recently, how about a prototype using ASCII graphics?

Heh, I remember when I suggested that. Watch out with radical ideas, people tend to really lose their Belgium.

Have you ever been to #rgrd on quakenet? Lots of rl devs there.

Still fustrated from thrive, aye?

I am fusrated on some things, but- not planning to post a huge rant thread.

Anyway, good to see you, there has veen some progress, mostly with theoretical models, and a bit of progress in programming...

1. Seregon opebd a repo in github (no one is allowed to use "push" for some reason).
2. Seregon made a CMake and added a Ogre.cpp in his fork (Copy Paste of Ogre tutorial number six)
3. I made the same file as above but modified to fit our needs (And added an SDL initialization) but people got upset (Because I opend a new repo so I could push abd work comftebly).
4. Dani is working on an eating AI and on a nore or less realistic cell physics system.
5. Aime guy forked the github repo and worked on a class structure but stopped working for a reason.

1 - it's called code review, the way github works is that you fork a project into your own account, work on it there, and when your done, push it (or pull request) back into the main repo. Once people start working with the repo regularly, and if their code looks ok, they will be given push access.
2 - yes, the actual source is mainly from the tutorials, the main work I did was on the CMake files, which should allow the project to be compiled on windows or linux. I had included various initialisation code, but stripped a lot of it to troubleshoot the issues we're having with MyGUI.
3 - I have no objection to you working in your own repo (though it would be more convenient if it was github), what I would like to avoid is having competing repo's for the main source to Thrive. The main advantage to the current one is that most coders already have access, and both Nick and Scio have admin access, so we wouldn't lose access to it if I were to dissapear.


Also - Hi Roadkill, good to see your still around, even if your mostly lurking.

Seregon wrote:

1 - it's called code review, the way github works is that you fork a project into your own account, work on it there, and when your done, push it (or pull request) back into the main repo. Once people start working with the repo regularly, and if their code looks ok, they will be given push access.
2 - yes, the actual source is mainly from the tutorials, the main work I did was on the CMake files, which should allow the project to be compiled on windows or linux. I had included various initialisation code, but stripped a lot of it to troubleshoot the issues we're having with MyGUI.
3 - I have no objection to you working in your own repo (though it would be more convenient if it was github), what I would like to avoid is having competing repo's for the main source to Thrive. The main advantage to the current one is that most coders already have access, and both Nick and Scio have admin access, so we wouldn't lose access to it if I were to dissapear.


Also - Hi Roadkill, good to see your still around, even if your mostly lurking.

1. Your way is fine, but it is really not comfortable, I also don't think that we have many people that want to cause damage.
2. That is fine, I am just saying, that my code is more "clean", I edited to look nice and easy to read... BTW, There is CEUI.
3. I didn’t force anyone to use my repo, my mine complain is that while it seems that you ware displeased with the repo, but didn’t comment about my code at all, I mean, don't judge the book by his cover... Also, while you aren’t disappearing, you are writing a thesis (I assume, if you are doing Ph.D), and can't spare much time for thrive (And that's okay), but the problem is that both nick and Scio don't know C++ (At least not very well), and can't review the code themselves, and you don't have the time either, therefore, I think should give admin to someone who knows c++ well (Maybe Dani... I myself don't think that I am skilled enough)...

P.S.
Sorry I was rude, just had a bad mood.

While I'm on the topic of completely derailing the topic, I might as well continue.

It looks like nothing has changed.. at all. The only people "working" on the project don't know what they're doing, and the people who do have stopped because of its inherent impossibility. The community seems to cycle through every few months too. It's a cool idea, and people join, but nobody delivers and they leave.

I guess I can state and restate this again, but nobody will listen. Simplify or die. This community has become so completely obsessed with realism, nobody will ever, EVER, want to write the code. If they do, they'll never finish. Cell physics? Push the Belgium things apart from eachother based on their distance. We don't need rigid body colliders, and we don't need to handle surface tension.

Not to mention, what will ultimate realism accomplish? Our exact same universe? Gee what a fun game, I can go outside and do whatever I can do IRL, but as a dog. Why not make it up? Why not create a dynamic evolution simulator? One where interesting things occur because of unusual circumstances? A game where crazy organisms evolve, and you have the ability to mix them together, just to see what happens?

I'm not pitching this as a step in the game, I'm pitching this as the ENTIRE game. Don't get me wrong here. I am actively critisiing thrive. This project is bad, and you should feel bad. Cell stage? Civ stage? Space stage? Editors? What a blatant copy of spore. The fact that you hang on to these silly "realistic spore" ideals is pathetic. It's what's preventing a game (yes, a game) from being made.

As for me? I will not touch this codebase with a 20½ foot long pole. Ogre? Safe pointers? Not my style. My opinion is, if you're going to put so many layers of protection on c++, why aren't you using C#, or Java? Seriously, why? I find it quite comical that a group of non-programmers have more or less determined the libraries that the programmers will use, though I suppose that's the case with the rest of the game.

Frustrated? No longer. I have become a quiet observer. I have joined the spectators --the ever lurking spectators. I do apologize for what a rant this may or may not have turned out to be. Though you must understand that without rants, how can there ever be change?

I have questioned many times whether or not to post again. I guess I just decided it was time for some tough advice.

Sincerely, your favorite antagonist,
roadkillguy

@ido - You are clearly a beginner, but you clearly have enthusiasm. My suggestion is to stop right here, and have at your own attempt. Yeah, you're pretty much annoying these guys. You bug the hell out of them, so don't let them hold you back. Go. Write. Code.

roadkillguy wrote:

While I'm on the topic of completely derailing the topic, I might as well continue.

It looks like nothing has changed.. at all. The only people "working" on the project don't know what they're doing, and the people who do have stopped because of its inherent impossibility. The community seems to cycle through every few months too. It's a cool idea, and people join, but nobody delivers and they leave.

I guess I can state and restate this again, but nobody will listen. Simplify or die. This community has become so completely obsessed with realism, nobody will ever, EVER, want to write the code. If they do, they'll never finish. Cell physics? Push the Belgium things apart from eachother based on their distance. We don't need rigid body colliders, and we don't need to handle surface tension.

Not to mention, what will ultimate realism accomplish? Our exact same universe? Gee what a fun game, I can go outside and do whatever I can do IRL, but as a dog. Why not make it up? Why not create a dynamic evolution simulator? One where interesting things occur because of unusual circumstances? A game where crazy organisms evolve, and you have the ability to mix them together, just to see what happens?

I'm not pitching this as a step in the game, I'm pitching this as the ENTIRE game. Don't get me wrong here. I am actively critisiing thrive. This project is bad, and you should feel bad. Cell stage? Civ stage? Space stage? Editors? What a blatant copy of spore. The fact that you hang on to these silly "realistic spore" ideals is pathetic. It's what's preventing a game (yes, a game) from being made.

As for me? I will not touch this codebase with a 20½ foot long pole. Ogre? Safe pointers? Not my style. My opinion is, if you're going to put so many layers of protection on c++, why aren't you using C#, or Java? Seriously, why? I find it quite comical that a group of non-programmers have more or less determined the libraries that the programmers will use, though I suppose that's the case with the rest of the game.

Frustrated? No longer. I have become a quiet observer. I have joined the spectators --the ever lurking spectators. I do apologize for what a rant this may or may not have turned out to be. Though you must understand that without rants, how can there ever be change?

I have questioned many times whether or not to post again. I guess I just decided it was time for some tough advice.

Sincerely, your favorite antagonist,
roadkillguy

@ido - You are clearly a beginner, but you clearly have enthusiasm. My suggestion is to stop right here, and have at your own attempt. Yeah, you're pretty much annoying these guys. You bug the hell out of them, so don't let them hold you back. Go. Write. Code.

There is a thine line between constructive criticism and just being Belgium, I believe that now you are just "Not over the ex"... Well, I really feel like watching a "Friends" episode!

While I don't agree on the manner, your have written your rant, I do agree with some stuff in here:
1. As you might have read, I opposed Dani's realistic cell physics, and I do believe we don't need that complex stuff, this is a game after all!
2. I really don't know why we can't use stuff like the "new" keyword, and the pointer standards, but I'm not going to criticize, and will leave it to Seregon to explain.
3. That some people think that we, the programmers can do "Computermagics" and create tons of editors and stages in a "Woshhh".

What I disagree on:
1. What is the problem with Ogre? Suggestion for replacement? Or maybe are you too lazy to learn how to use Ogre.
2. You are something in rants, aren’t you? I haven't noticed a piece of code you created (Maybe there aren't any...), You may know c++, but did you actually contributed anything to the code? It seems that you were just here for something like three years doing nothing.
3. The libs and all were mostly decided by Seregon (Who knows c++) and more programmers (jaws 4 blood, aperion... They became inactive).

Look, about your 2 lines for me:
1. You are right, I am a beginner.
2. Believe me, I am not "that" enthusiastic.
3. My suggestion to you is that you try to work with people, I mean, actually work and help others.
4. You know what, I will just let them decide, PM me if you feel that I should quit or not. (Or reply here...)
5. goto line4
6. Go. And. Do. Something...

Now, feel free to sand rants to my inbox, I will reply to them! (Or rant here, I will replay...)
Also, you are welcome if you want to come back!

@ido
1 - It's not that I'm worried people will want to cause harm, but that people will accidently push code which isn't quite ready. The idea of the pull request is that other people can see, review, and fix the code before it goes in the main repo.
2 - Fair enough, the code I have in my repo right now is far from clean, but I never intended for it to be used, one of the reasons I put of putting it in the main repo. We did look at CEGUI, but had even more issues with that than MyGUI.
3 - My only objection was the possibility of having duplicate repos. I had no real objection to your code, though there wasn't much to look at at the time, and as you say much of it was from tutorials - it was fine, but there wasn't enough there to comment on. I agree that someone needs to be around to accept pull requests, and that neither Scio nor Nick are (currently) qualified to do so. The main reason they're admins is so that if I dissapear, they can give other programmers the necessary access. If people start using the repo more I'll start giving them greater access. While I am fairly busy, I still have just enough time to keep track of most of whats going on here.

@Roadkill
I can agree with a lot of what you say, but not all. We probably won't ever finish Thrive, and while its possible, we may not get to many of the later stages, I also agree that the similarity to Spore has been taken too far, and that the space stage for example adds little to the idea of Thrive as an evolution sim. The difference, I guess, is that that isn't why I'm here. I'm here to build something, and anything we do is worthwhile, whether or not it ever gets finished. I'm more interested in the concepts we develop, and the prototypes we do manage to build, than a finished game. You might see that as a problem, or not.

Similairly, being realistic isn't necessarily about what should be done, but what can be done (without ruining Thrive). I like doing difficult things, if Thrive aimed simply to be a fun evolution-related game, I wouldn't be here (and neither, I suspect, would most of us).

On c++, I guess that's a question of personal taste. I use c++ not becuase its 'not safe', but becuase it's powerful as hell, and I'd choose to use Ogre because I came here to code a game, not a graphics engine. Also, the choice of libraries was actually made by programmers (when we had a fair few last August/September)... I think you were even in that meeting.

Again, I can see where your comming from, and how you got there, but I can't agree with all of it.

@ido again (...post sniped me!)
I'm not sure what Dani is proposing is particularly realistic, or difficult to implement, but I'll have to give that thread another read over. To some extent this sort of issue is comming up a lot (not just from you), where people are scared away from particular concepts becuase they appear hard to code, which seems to have developed becuase in the past noone seemed aware of this, and it was pointed out repeatedly by the coders. The problem, perhaps, is that now we've gone a little too far the other way, and concepts which would be fairly simple to code are being dismissed, for the same reason - most people don't know how hard, or not, something is to code. You've been doing this a lot recently, I suspect becuase you've recently learned to code, and have realised how hard it can be, but haven't yet learned just how powerful it can also be, and how easy some things are if you know how. Unfortunately, because I have limited time to post, while I'll try to correct these posts where possible, I'm not always able to do so kindly, or explain the problem in full - I'll try to do so more when I do reply, though it may mean even less posts from me.

The use of safe pointers, instead of 'new' and 'delete', wasn't my suggestion, but Apeiron's, and I happen to think it's a very good one. Safe pointers have a lot of advantages besides being 'safe', and I remember roadkill even found that out when coding his entity system. The main advantage as I see it, is that shared pointers can be used from many different scopes, without having to keep explicit track of where, and without risk of it being deleted prematurely. There's still a risk of it not being deleted, if some object holding a reference is kept around too long.

As for you going or staying, I'd say stay. Yes, you can be annoying at times, but I don't think it's intentional, and the more you learn, the better you get. You have a long way to go in learning many subjects, but atleast you've started, and having a relative beginner around can be surprisingly useful at times, and someday you won't be a beginner anymore. If it helps any, I actually left the forum after my first few weeks here (for almost a year), becuase I felt I was being annoying and stepping on too many toes, despite posting some relatively useful stuff in that time. Also, so that you might avoid them, there are two things which particularly annoy me on these forums (again, not just you, I've seen many people do this many times) - the first is duplication of effort, especially where there isn't a significant difference in the new effort, and it has the potential to compete with the original (the repo being a good example). The second is when people don't do their research, or argue a point (often blindly) based on an opinion they've formed, rather than evidence or experience. You tend to be pretty good at doing your research, but when you end up argueing with an experienced programmer about whether or not something is possible, it's worth double checking your facts. Finally, as Roadkill said, it's worth having a go at writing stuff yourself (as you already have), whether it be independant prototypes, or sections for the actual game, practising is the only way you'll get better. What you write may not get into the codebase yet, but it might help us test various ideas and develop concepts, and having your code reviewed will definitely help your learn a lot faster than trying to learn on your own.

Also - yes, this is way off topic, but it's a discussion worth having, so if it goes on much longer I'll move it somewhere more appropriate.

Wow, I don't check for one day and what a discussion...

First off, to everyone, but particularly Ido and Roadkillguy, try and keep the anger/dispute levels low in your replies. We can discuss this issue like orderly and civilized Forumers.

@Roadkillguy: I'm surprised to see you back Roadkill. Not because I didn't expect you to, but because I used to check on you and Bashi to see when you guys last logged on. Nonetheless, its a pleasant surprise.

Quote :

I guess I can state and restate this again, but nobody will listen.
Simplify or die. This community has become so completely obsessed with
realism, nobody will ever, EVER, want to write the code.

That is exactly what I was trying to get people to do, particularly in this thread. However, I don't have a good sense of how complex or simple different game mechanics normally are, so it was my idea to propose a physics based porpulsion and collision system since I thought that that would be a practical application.

This is a question to all the programmers. What would need to be done simply to get the basic .exe that opens a program that simply displays the below?

Spoiler:

My point is, that is all we need right now. Then, once we have that done, we populate the screen with some cells. Then we add a main menu before you actually go into the game. Then we make it so that the cells can move. We start simple, and build or way up using simple steps. I have just summarized the whole and entire purpose of this thread, which I just previously mentioned, and which is based off of your signature Roadkill (The older one).

Seriously though, how hard would it be and what would need to be done to just get the basic .exe with a simple background up and running?

Quote :

As for me? I will not touch this codebase with a 20½ foot long pole. Ogre? Safe pointers?

Eh... I don't really know about that stuff, so I can't reply.

I have read and reread most of your and Bashi's posts explaining how things need to be simplified and code-able. I genuinely am trying to follow that, and I hope you realize that. If you could help me out with coordinating things to start with the basics and build our way up from there, please PM me or reply, I would really appreciate it.

@Ido: It is okay, although you guys, as well as I, may disagree with certain points of his, I think his post was very useful and constructive. Plus, he's saying all that because he wants to see the game succeed and develop.

Also, watch out with the name calling, even if it is censored.

Also, I second Seregon's comments on you. Having said that, I enjoy your contributions. Just please try not to get aggressive with your collaboration.

Lastly, don't criticise Roadkill for not having done things when most of us haven't done much either.

@Seregon: At the bare minimum, I would want hope for everything until the end of aware stage to be completed, but that is only the bare minimum.

There's no worry of going off topic here. Normally I crack down on people who post whole threads to say Happy Halloween or talk about Chuck Norris organisms, but this really is worth discussing, so I'll vouch for it.

EDIT: As a final note to Roadkill, please don't go to just lurking. Your antagonizing is what drives us forwards! It was you who got me inspired to make the "Building Microbe Stage" thread, and to start thinking as you do. You really are a wonderful and irreplaceable asset to the team.

Seregon wrote:

@ido
1 - It's not that I'm worried people will want to cause harm, but that people will accidently push code which isn't quite ready. The idea of the pull request is that other people can see, review, and fix the code before it goes in the main repo.
2 - Fair enough, the code I have in my repo right now is far from clean, but I never intended for it to be used, one of the reasons I put of putting it in the main repo. We did look at CEGUI, but had even more issues with that than MyGUI.
3 - My only objection was the possibility of having duplicate repos. I had no real objection to your code, though there wasn't much to look at at the time, and as you say much of it was from tutorials - it was fine, but there wasn't enough there to comment on. I agree that someone needs to be around to accept pull requests, and that neither Scio nor Nick are (currently) qualified to do so. The main reason they're admins is so that if I dissapear, they can give other programmers the necessary access. If people start using the repo more I'll start giving them greater access. While I am fairly busy, I still have just enough time to keep track of most of whats going on here.

@Roadkill
I can agree with a lot of what you say, but not all. We probably won't ever finish Thrive, and while its possible, we may not get to many of the later stages, I also agree that the similarity to Spore has been taken too far, and that the space stage for example adds little to the idea of Thrive as an evolution sim. The difference, I guess, is that that isn't why I'm here. I'm here to build something, and anything we do is worthwhile, whether or not it ever gets finished. I'm more interested in the concepts we develop, and the prototypes we do manage to build, than a finished game. You might see that as a problem, or not.

Similairly, being realistic isn't necessarily about what should be done, but what can be done (without ruining Thrive). I like doing difficult things, if Thrive aimed simply to be a fun evolution-related game, I wouldn't be here (and neither, I suspect, would most of us).

On c++, I guess that's a question of personal taste. I use c++ not becuase its 'not safe', but becuase it's powerful as hell, and I'd choose to use Ogre because I came here to code a game, not a graphics engine. Also, the choice of libraries was actually made by programmers (when we had a fair few last August/September)... I think you were even in that meeting.

Again, I can see where your comming from, and how you got there, but I can't agree with all of it.

@ido again (...post sniped me!)
I'm not sure what Dani is proposing is particularly realistic, or difficult to implement, but I'll have to give that thread another read over. To some extent this sort of issue is comming up a lot (not just from you), where people are scared away from particular concepts becuase they appear hard to code, which seems to have developed becuase in the past noone seemed aware of this, and it was pointed out repeatedly by the coders. The problem, perhaps, is that now we've gone a little too far the other way, and concepts which would be fairly simple to code are being dismissed, for the same reason - most people don't know how hard, or not, something is to code. You've been doing this a lot recently, I suspect becuase you've recently learned to code, and have realised how hard it can be, but haven't yet learned just how powerful it can also be, and how easy some things are if you know how. Unfortunately, because I have limited time to post, while I'll try to correct these posts where possible, I'm not always able to do so kindly, or explain the problem in full - I'll try to do so more when I do reply, though it may mean even less posts from me.

The use of safe pointers, instead of 'new' and 'delete', wasn't my suggestion, but Apeiron's, and I happen to think it's a very good one. Safe pointers have a lot of advantages besides being 'safe', and I remember roadkill even found that out when coding his entity system. The main advantage as I see it, is that shared pointers can be used from many different scopes, without having to keep explicit track of where, and without risk of it being deleted prematurely. There's still a risk of it not being deleted, if some object holding a reference is kept around too long.

As for you going or staying, I'd say stay. Yes, you can be annoying at times, but I don't think it's intentional, and the more you learn, the better you get. You have a long way to go in learning many subjects, but atleast you've started, and having a relative beginner around can be surprisingly useful at times, and someday you won't be a beginner anymore. If it helps any, I actually left the forum after my first few weeks here (for almost a year), becuase I felt I was being annoying and stepping on too many toes, despite posting some relatively useful stuff in that time. Also, so that you might avoid them, there are two things which particularly annoy me on these forums (again, not just you, I've seen many people do this many times) - the first is duplication of effort, especially where there isn't a significant difference in the new effort, and it has the potential to compete with the original (the repo being a good example). The second is when people don't do their research, or argue a point (often blindly) based on an opinion they've formed, rather than evidence or experience. You tend to be pretty good at doing your research, but when you end up argueing with an experienced programmer about whether or not something is possible, it's worth double checking your facts. Finally, as Roadkill said, it's worth having a go at writing stuff yourself (as you already have), whether it be independant prototypes, or sections for the actual game, practising is the only way you'll get better. What you write may not get into the codebase yet, but it might help us test various ideas and develop concepts, and having your code reviewed will definitely help your learn a lot faster than trying to learn on your own.

Also - yes, this is way off topic, but it's a discussion worth having, so if it goes on much longer I'll move it somewhere more appropriate.

Thanks for your critisim, It was constructive.

@roadkill:
This is an exemple to good and constructive criticism... As you see in here he criticized me and you while not insulting us. Your post is an exemple of trying to get a massage across, but poor way of saying it.

@Seregon:
1 - Well, everything is fine but the main problem is who will review.
2 - Hopefully you won't disappeare.
3 - I might delete the dupe repo.
4 - Protip: Remember to get your destructors right.

First, I will try to stop duping stuff.
Second, I am sometimes taking my argument to far, also, I will try to evaluate what is possiable or not better.

Anywho, thanks for the tips.

NickTheNick wrote:

Seriously though, how hard would it be and what would need to be done to just get the basic .exe with a simple background up and running?

Very easy, and I've probably had something similair done before now, but not posted it as I had other goals. I definately see your point here though, I've been too worried about having all the libraries in place before doing more (for good reason, adding them later could be significantly more painful), but as that effort seems close to stalling, it may be worth simply producing something, anything, and moving on from there. Ofcourse we're going to run into the GUI issue again fairly quickly, but I think we can atleast work around it, if not solve it, in due course.

NickTheNick wrote:

@Seregon: At the bare minimum, I would want hope for everything until the end of aware stage to be completed, but that is only the bare minimum.

I agree on that, and those stages are the ones which most interest me personally. They're the ones which are perhaps most challenging, and most unique. I see the later (tribal/civ) stages as practically a different game, but definately still interesting enough to consider, and maybe someday build.

@Ido
Thank you, and your welcome.
1 - That is a problem, but as noone is submitting much code right now, it's not an urgent one. For the moment I'll handle it, once people start submitting more than I can deal with, whoever is actively contributing good code will also get review rights.
2 - I have no intention of dissapearing, but you never know what might happen.
3 - Don't worry too much about it. If it's for your own use, and your comfortable using it, keep using it. It'll be a lot easier to work with us if you use github, but it takes a little getting used to. It also really helps if your IDE has github integration (I really recommend netbeans here).

Seregon wrote:

NickTheNick wrote:

Seriously though, how hard would it be and what would need to be done to just get the basic .exe with a simple background up and running?

Very easy, and I've probably had something similair done before now, but not posted it as I had other goals. I definately see your point here though, I've been too worried about having all the libraries in place before doing more (for good reason, adding them later could be significantly more painful), but as that effort seems close to stalling, it may be worth simply producing something, anything, and moving on from there. Ofcourse we're going to run into the GUI issue again fairly quickly, but I think we can atleast work around it, if not solve it, in due course.

NickTheNick wrote:

@Seregon: At the bare minimum, I would want hope for everything until the end of aware stage to be completed, but that is only the bare minimum.

I agree on that, and those stages are the ones which most interest me personally. They're the ones which are perhaps most challenging, and most unique. I see the later (tribal/civ) stages as practically a different game, but definately still interesting enough to consider, and maybe someday build.

@Ido
Thank you, and your welcome.
1 - That is a problem, but as noone is submitting much code right now, it's not an urgent one. For the moment I'll handle it, once people start submitting more than I can deal with, whoever is actively contributing good code will also get review rights.
2 - I have no intention of dissapearing, but you never know what might happen.
3 - Don't worry too much about it. If it's for your own use, and your comfortable using it, keep using it. It'll be a lot easier to work with us if you use github, but it takes a little getting used to. It also really helps if your IDE has github integration (I really recommend netbeans here).

I use codeblocks, I think it has a git integration.

Maybe we should include common IDE's project files.

I tried codeblocks, but didn't get on with it very well, though I do think it'll work with git. One of the benifits of using CMake is that it can generate project files for many IDE's (including msvs, codeblocks, make, and mingw-make, which netbeans can use). While we could include project files, they tend to get fairly large, and I'm not sure how portable they are between different peoples setups.

I believe the portability depends greatly on the particular IDE. Eclipse is really good for portability, as it works over java, and java works on basically everything. Althrough they can be big, that is only a minor problem, as they only have to be downloaded once. I believe that a setup for windows 32 could work, althrough i dont know anything about how registers affect that.

Daniferrito wrote:

I believe the portability depends greatly on the particular IDE. Eclipse is really good for portability, as it works over java, and java works on basically everything. Althrough they can be big, that is only a minor problem, as they only have to be downloaded once. I believe that a setup for windows 32 could work, althrough i dont know anything about how registers affect that.

We are talking about project files, not IDE's themselves.

Ok, sorry, misunderstaunding on my part

Daniferrito wrote:

Ok, sorry, misunderstaunding on my part

No problem.

Seregon wrote:

Very easy, and I've probably had something similair done before now, but not posted it as I had other goals. I definately see your point here though, I've been too worried about having all the libraries in place before doing more (for good reason, adding them later could be significantly more painful), but as that effort seems close to stalling, it may be worth simply producing something, anything, and moving on from there. Ofcourse we're going to run into the GUI issue again fairly quickly, but I think we can atleast work around it, if not solve it, in due course.

Then I would strongly be in favour of creating an application soon just to get the foundation done, and then work up from there. I'll leave this call to you programmers though.

Hello there, long time no post. I still lurk occasionally, but unfortunately I don't have the time to contribute..

I agree with mostly everything Roadkill wrote. Nick has done a lot to clarify the concept and guide the work, but at the core the problem remains the same - complexity. While I don't oppose the idea of cell/civilisation gameplay, why all the talk about cell physics? Why all the compound stuff? Why learning AIs? Unless you want to turn Thrive into a statistics game, these will remain mostly hidden from players anyway. Remember the KISS rule.

As for the libraries, I personally prefer to use a few small ones and get in touch with OpenGL directly. GLFW and GLEW for OS-independent OpenGL are more than enough. Things like Ogre and especially any and all GUI libraries tend to bring all sorts of trouble with compatibility and especially their design. Look here and here if you want to know why. But if you really want to go with Ogre, do so, many great projects were built on it. All I'm giving here is my opinion

Oh, and accusing Roadkill of not doing anything is not fair at all. He was the one to make the first cell prototype (wich still remains the only playable version of the cell stage). The first coding attempt that actually made some progress was also his work.

Quote :

This is a question to all the programmers. What would need to be done simply to get the basic .exe that opens a program that simply displays the below?

My point is, that is all we need right now. Then, once we have that done, we populate the screen with some cells. Then we add a main menu before you actually go into the game. Then we make it so that the cells can move.

Was already done at least once. I ended up abandoning it and leaving both because of personal problems and since at the time, people didn't have a real idea what was the cell gameplay supposed to be like. Nick wasn't here back then..

Commander Keen wrote:

Hello there, long time no post. I still lurk occasionally, but unfortunately I don't have the time to contribute..

I agree with mostly everything Roadkill wrote. Nick has done a lot to clarify the concept and guide the work, but at the core the problem remains the same - complexity. While I don't oppose the idea of cell/civilisation gameplay, why all the talk about cell physics? Why all the compound stuff? Why learning AIs? Unless you want to turn Thrive into a statistics game, these will remain mostly hidden from players anyway. Remember the KISS rule.

As for the libraries, I personally prefer to use a few small ones and get in touch with OpenGL directly. GLFW and GLEW for OS-independent OpenGL are more than enough. Things like Ogre and especially any and all GUI libraries tend to bring all sorts of trouble with compatibility and especially their design. Look here and here if you want to know why. But if you really want to go with Ogre, do so, many great projects were built on it. All I'm giving here is my opinion

Oh, and accusing Roadkill of not doing anything is not fair at all. He was the one to make the first cell prototype (wich still remains the only playable version of the cell stage). The first coding attempt that actually made some progress was also his work.

Quote :

This is a question to all the programmers. What would need to be done simply to get the basic .exe that opens a program that simply displays the below?

My point is, that is all we need right now. Then, once we have that done, we populate the screen with some cells. Then we add a main menu before you actually go into the game. Then we make it so that the cells can move.

Was already done at least once. I ended up abandoning it and leaving both because of personal problems and since at the time, people didn't have a real idea what was the cell gameplay supposed to be like. Nick wasn't here back then..

Hey, keen, how are you doing?

I agree with you on the fact that complexity is the project's demon, it is like a dogama, I mean, I think that big parts of the project needs to be dumbed down, before this will turn into some kind of mathematical simulation.

Also, have you noticed that it seems that the more time a user spents in the project, the more anger he has for it.

Well... hugest Vaporware l know:
1. Thλive - Life 0 - CellStage 1.
2. Thrive Nukam: ForevorVapor.
3. Thrivlite.

Commander Keen wrote:

Hello there, long time no post. I still lurk occasionally, but unfortunately I don't have the time to contribute..

I agree with mostly everything Roadkill wrote. Nick has done a lot to clarify the concept and guide the work, but at the core the problem remains the same - complexity. While I don't oppose the idea of cell/civilisation gameplay, why all the talk about cell physics? Why all the compound stuff? Why learning AIs? Unless you want to turn Thrive into a statistics game, these will remain mostly hidden from players anyway. Remember the KISS rule.

As for the libraries, I personally prefer to use a few small ones and get in touch with OpenGL directly. GLFW and GLEW for OS-independent OpenGL are more than enough. Things like Ogre and especially any and all GUI libraries tend to bring all sorts of trouble with compatibility and especially their design. Look here and here if you want to know why. But if you really want to go with Ogre, do so, many great projects were built on it. All I'm giving here is my opinion

Oh, and accusing Roadkill of not doing anything is not fair at all. He was the one to make the first cell prototype (wich still remains the only playable version of the cell stage). The first coding attempt that actually made some progress was also his work.

Quote :

This is a question to all the programmers. What would need to be done simply to get the basic .exe that opens a program that simply displays the below?

My point is, that is all we need right now. Then, once we have that done, we populate the screen with some cells. Then we add a main menu before you actually go into the game. Then we make it so that the cells can move.

Was already done at least once. I ended up abandoning it and leaving both because of personal problems and since at the time, people didn't have a real idea what was the cell gameplay supposed to be like. Nick wasn't here back then..

Oh my god, this discussion is bringing back all the old vets! Its wonderful to see you Keen, and actually I was heavily involved in the Strategy Mode a month or so ago and it would have been nice to work over that concept with you. Now though I focus on Microbe Stage.

First off, those links you gave on GUI look really neat, I'll have to have a look at them tomorrow.

The reason I was pushing for the physics and the compounds and everything else to be implemented with the initial build of the game was because I thought it would be far too difficult to come back later and add them in. However, this was an assumption based on little programming experience (doing triggers in the Warcraft III World Editor), and no one told me that its okay to do otherwise until this thread.

If that's the case then, I would strongly advocate for getting creating the base application, just the raw basics, just to get something done. Then from there we could start adding in everything we want. The huge benefit of this would be, correct me if I'm wrong, that the game would be playable at all the steps in between; so basically we could even play the game before all the compounds and physics and other complex stuff is added, instead of making it all at once.

That link you gave at the end Keen, I think that's exactly what we need right now. Just to get something like that up and running, with possibly a better tiled background (no offense), would be a huge step forwards.

Would you be able to help out with the coding these days Keen? If you are preoccupied with other activities, then don't worry about it, but it would be really awesome if we could get an old member with such talent back on board. I was even thinking of starting a thread (not myself though), like the Microbe Stage Progress Report, except for programming. It would have an OP with all the tasks for coding outlined, it would have a list of all the programmers doing what, and the discussion would take place below. Would you like to start such a thread? I would be more than willing to help out, such as by first sending all the coders I'm in contact with to that thread.

If the compounds and physics and learning AI aren't necessary at the moment, there really isn't that much to creating this first stage. I want to and am willing to work with you Keen, or you Roadkill, as well as everyone else, on the first stage, and omit these complex systems for now, just to get Microbe finished. I have a lot of time and effort on my hands these days, and I would like to be able to use it before my schedule starts getting muddled up again.

Quote :

the more time a user spents in the project, the more anger he has for it.

Anger? Do you mean passion? Or frustration?

Quote :

Well... hugest Vaporware l know:
1. Thλive - Life 0 - CellStage 1.
2. Thrive Nukam: ForevorVapor.
3. Thrivlite.

Or better yet, Thrive Wars Battlefront 3!

EDIT: Sorry Keen, now that I reread your post I see you said that you don't have much time to contribute. Don't let me pressure you then if you can't do it.

DOUBLE EDIT: Are there any programmers that are willing to start the thread I mentioned above? I would be ready to help.

Yes, my learning AI is a bit of overkill. But nearly everything in this project is.

What i have to say in my defense is that my idea is possible, we have a plan into how to implement it, and will work.

NickTheNick wrote:

Commander Keen wrote:

Hello there, long time no post. I still lurk occasionally, but unfortunately I don't have the time to contribute..

I agree with mostly everything Roadkill wrote. Nick has done a lot to clarify the concept and guide the work, but at the core the problem remains the same - complexity. While I don't oppose the idea of cell/civilisation gameplay, why all the talk about cell physics? Why all the compound stuff? Why learning AIs? Unless you want to turn Thrive into a statistics game, these will remain mostly hidden from players anyway. Remember the KISS rule.

As for the libraries, I personally prefer to use a few small ones and get in touch with OpenGL directly. GLFW and GLEW for OS-independent OpenGL are more than enough. Things like Ogre and especially any and all GUI libraries tend to bring all sorts of trouble with compatibility and especially their design. Look here and here if you want to know why. But if you really want to go with Ogre, do so, many great projects were built on it. All I'm giving here is my opinion

Oh, and accusing Roadkill of not doing anything is not fair at all. He was the one to make the first cell prototype (wich still remains the only playable version of the cell stage). The first coding attempt that actually made some progress was also his work.

Quote :

This is a question to all the programmers. What would need to be done simply to get the basic .exe that opens a program that simply displays the below?

My point is, that is all we need right now. Then, once we have that done, we populate the screen with some cells. Then we add a main menu before you actually go into the game. Then we make it so that the cells can move.

Was already done at least once. I ended up abandoning it and leaving both because of personal problems and since at the time, people didn't have a real idea what was the cell gameplay supposed to be like. Nick wasn't here back then..

Oh my god, this discussion is bringing back all the old vets! Its wonderful to see you Keen, and actually I was heavily involved in the Strategy Mode a month or so ago and it would have been nice to work over that concept with you. Now though I focus on Microbe Stage.

First off, those links you gave on GUI look really neat, I'll have to have a look at them tomorrow.

The reason I was pushing for the physics and the compounds and everything else to be implemented with the initial build of the game was because I thought it would be far too difficult to come back later and add them in. However, this was an assumption based on little programming experience (doing triggers in the Warcraft III World Editor), and no one told me that its okay to do otherwise until this thread.

If that's the case then, I would strongly advocate for getting creating the base application, just the raw basics, just to get something done. Then from there we could start adding in everything we want. The huge benefit of this would be, correct me if I'm wrong, that the game would be playable at all the steps in between; so basically we could even play the game before all the compounds and physics and other complex stuff is added, instead of making it all at once.

That link you gave at the end Keen, I think that's exactly what we need right now. Just to get something like that up and running, with possibly a better tiled background (no offense), would be a huge step forwards.

Would you be able to help out with the coding these days Keen? If you are preoccupied with other activities, then don't worry about it, but it would be really awesome if we could get an old member with such talent back on board. I was even thinking of starting a thread (not myself though), like the Microbe Stage Progress Report, except for programming. It would have an OP with all the tasks for coding outlined, it would have a list of all the programmers doing what, and the discussion would take place below. Would you like to start such a thread? I would be more than willing to help out, such as by first sending all the coders I'm in contact with to that thread.

If the compounds and physics and learning AI aren't necessary at the moment, there really isn't that much to creating this first stage. I want to and am willing to work with you Keen, or you Roadkill, as well as everyone else, on the first stage, and omit these complex systems for now, just to get Microbe finished. I have a lot of time and effort on my hands these days, and I would like to be able to use it before my schedule starts) getting muddled up again.

Quote :

the more time a user spents in the project, the more anger he has for it.

Anger? Do you mean passion? Or frustration?

Quote :

Well... hugest Vaporware l know:
1. Thλive - Life 0 - CellStage 1.
2. Thrive Nukam: ForevorVapor.
3. Thrivlite.

Or better yet, Thrive Wars Battlefront 3!

EDIT: Sorry Keen, now that I reread your post I see you said that you don't have much time to contribute. Don't let me pressure you then if you can't do it.

DOUBLE EDIT: Are there any programmers that are willing to start the thread I mentioned above? I would be ready to help.

I will start it, I have much time to edit and update it, but I will need some help from Seregon and Dani with it.