The Altera Centauri collection has been brought up to date by Darsnan. It comprises every decent scenario he's been able to find anywhere on the web, going back over 20 years.
25 themes/skins/styles are now available to members. Check the select drop-down at the bottom-left of each page.
Call To Power 2 Cradle 3+ mod in progress: https://apolyton.net/forum/other-games/call-to-power-2/ctp2-creation/9437883-making-cradle-3-fully-compatible-with-the-apolyton-edition
Hmm, that's not supposed to happen! It doesn't actually do that on my system, does it do that on anybody elses? On mine it is really transparent, just like a windows cursor, very bizarre.
From Leland:
chrispie: The transparent controls look really cool, the only problem is that they aren't really transparent, they just copy the background whenever it's updated... if you move them around the background stays the same and the illusion of transparency is lost. Hmm. I wonder what it would take to program true transparency, the kind of which isn't lost even when moving the controls around?
Hmm, the windows move? Lol, I think I've not quite seen your point here leland, do you mean the windows move or the background moves? When the bg moves, the picture in the windows 'should' change too. Though you saying this has made me think that maybe I could just ignore the pink colour of the fill, and draw a semi-transparent white block over that, that might work better than copying.
I really need to work through the whole UI, to be honest I'm not that happy with it now, some of the stuff in it I just don't like the way it's done. It might take me a few weeks, but I'm going to concentrate my efforts on improving the way it works, I want to be sure it works well for everyone too. So please start posting anything about it that doesn't work for you, and/or logfiles if it doesn't work at all.
Chrispie
"Wise Men Talk because they have something to say, fools talk because they have to say something" - Plato
Also, I'm reviewing the use of messages in the UI. I've come to the conclusion that the message system may very well be a big waste of time. I think the only need for a message system is in queing, but it doesn't do that! I know I'm talking about some big changes here, but I want us to have a very good UI, which I'm by no means convinced is what it is now.
"Wise Men Talk because they have something to say, fools talk because they have to say something" - Plato
Also, I'm reviewing the use of messages in the UI. I've come to the conclusion that the message system may very well be a big waste of time. I think the only need for a message system is in queing, but it doesn't do that! I know I'm talking about some big changes here, but I want us to have a very good UI, which I'm by no means convinced is what it is now.
we use win32 queue if I recall? I think we should switch to DInput. queuing is absoutely necessary, I have learned so while I was doing UI without it. many mouse states get dropped if you poll for them in a loop or something.
about messages, why drop them? they work, just adapt them not to use win32
I'm sure the UI did originally use DInput, but I took it out because it was slow and you had to call update to make it do anything, meaning it's messages are heavily attached to the code of the program.
The win32 message system is used now because it runs independantly of the UI thread, meaning that in theory, it shouldn't drop messages. Though my UI has a seperate msg system - that's what I was gunna drop until I realised it uses functions like sendMessageToAllChildren, virtually impossible to duplicate in the form of normal functions.
"Wise Men Talk because they have something to say, fools talk because they have to say something" - Plato
Originally posted by chrispie
Hmm, the windows move? Lol, I think I've not quite seen your point here leland, do you mean the windows move or the background moves? When the bg moves, the picture in the windows 'should' change too. Though you saying this has made me think that maybe I could just ignore the pink colour of the fill, and draw a semi-transparent white block over that, that might work better than copying.
I meant that when you move a semi-transparent control around, it doesn't change: the only time it is transparently drawn is when the background changes. I attached a screen cap of a window to give an example of what a window could look like after a little fooling around. Another thing I noticed is that controls that are covered by other controls still seem to catch (some?) mouse events.
About queing, we'll have to include it in one form or the other anyway due to communication between different computers/threads, so perhaps we could refashion the current message/event system to use a queue? As for the message queue of Win32, I see no problem in having it in the background like they are now, that's an implementation detail, IMHO.
Hmmm, I changed it so that it does like you say. It works fine as long as it's just plain transparent, but when I apply the alpha to make it see through, it slows down the drag quite a lot, I think it's just asking too much from most systems. I'll look at the code to see if I can change it, but right now I don't think it's very feasable.
"Wise Men Talk because they have something to say, fools talk because they have to say something" - Plato
As I stated on the site: I am not really interested in keeping up the site (maintaining it). However, as not really good explained in that same post), I am happy to draw more controls, if needed, for the UI. (Altough a totally different version is a lot of work...)
About the transparence: The way I did it in Adobe (Photoshop) was the same as you desciped above; and it was the way I thought you implented it: Draw a white, semi-transparent rectangle (as a background for that window). This would prevend the problem some of you might have (as stated in this post). Don't know if we should change it... Maybe we should go for the less processor-consuming option.
Maybe someday we have the luxury of using hardware acceleration for the transparency effect, but for the time being it's not such a big deal. How about making it plain transparent (or filled) when dragging, and semi-transparent when they're still? Would it look odd?
I'm disturbed by what I read here, guys. It looks to me like you are losing hope. This can't be good.
I will offer some advice. You can ignore it if you like. But this comes from experience, and maybe it will help.
I have programmed MD all by myself for over three years now, going on four. About a month ago, I took stock of where we were at in development. The picture was not pretty, I must admit. I suspect this could be the same place you are now, judging by what I am reading here.
In my case, MD was pretty far along. But looking at the list of things still to do, I figured we had another year left, easy. The plain and simple fact was that development was too slow. Interest was waining, both on my part and on the part of the fans of our project, and something had to be done.
A few weeks ago, the MD source code went semi-open, and I recruited help from our followers to complete the program. I tell you in all honesty I had many misgivings about this. We're talking about code I had spent over three years working on! It seemed a huge risk.
But it turned out to be the best thing I could have done for the program. I am once again confident that MD will be complete, and sooner than a year from now!
Why do I tell you this? Because the model we are following is working superbly. I will tell you of it, and perhaps you can adapt it for your needs, and maybe GG&S will continue to thrive.
I think the coding model you are using is flawed. Correct me if I'm wrong, but I *think* you have several coders, each of which is taking a particular role. One person codes UI, another is doing economy, another is working on the map, etc. This works in a standard office environment, where each person is focused on doing their job for 8 (or more) hours per day, but in a less focused environment, with volunteers and people that come and go, I don't think it works as well.
For the model that MD uses to work, you need four things.
One, which I think you may have (not sure) is a set of coding standards. Everyone *has* to code in the same format, because everyone is going to participate in creating each bit of code. For that to work, you have to agree on how the code will look. MD has it's code standards posted publically on our board.
Two, you need a code master. This is someone that will collect all the bits of code after a subject has been completed, and put it together into the master code base. In the case of MD, that is me. In your case, it needs to be someone who is pretty good with coding and pretty committed to the project, because that person will be heavily worked
Three, you need to post the entire code base somewhere, publically, or privately, however you wish. But the coders *must* have 24/7 access to see the current code. The code master must update this base on a regular basis. Preferably, it should be in sections (for MD, each class has it's own section showing the header and cpp file (and DFM file, if its a UI class)). That way, only those classes that have changed need be updated.
Four, you need to be able to write small and to-the-point routines. The absolute best way to do this is to use an OO methodology. It *can* be done with procedural code, though it's harder. In any event, you cannot be writing fifty page routines. They must be small enough that everyone can follow the routine easily and pretty much at a glance.
So, how does this work? Pick a subject. Make it *specific*. As a for instance, we are right now working on "resource placement on the world map" for MD. We just finished "closed economy resource regeneration" and "open economy resource regeneration". These are very particular routines, and, most importantly, can be coded in under 100 lines.
When a subject is chosen, the entire team focuses on that subject. One person may suggest an algorithm. Another codes it. The algorithm/code is posted on the board. Others suggest changes or enhancements. Changes can be posted as fragments that fit in or replace parts of the original post. This shouldn't take weeks. In my experience, two or three days from start to finish should do it. If it's taking longer, your topic is too complex. When you are done, you have a routine that does some very specific function very well. Once all changes are complete and everyone agrees the routine is done, the code master takes the final version (sometimes having to peice it together from the posts in the entire topic) and plugs it into the code base. There may (probably will) be a bit of extra coding to integrate the new function into the overall game loop. And viola! Subject done, you have a new feature, move on to the next one.
One great thing about this system is that even non-coders can participate. C++ is not all that hard to follow. A coder must do the initial coding, but once thats up, pretty much anybody (even artists! j/k ) can follow what is going on and make minor modifications or suggestions to the code.
Or, even non-team members could pop in from time to time. I might look in on a bit of code and make a suggestion here or there, or Joe Shmo might offer his two cents worth somewhere else.
It seems to me, you guys started off pretty well, make a nice overall design (which is certainly important). But the next step, the coding of all the little details, stopped the project. Perhaps this might help in getting it going again.
Or, you can ignore me and just do what you were doing. Maybe you have other ideas on how to get things moving again.
Ron
Manifest Destiny - The Race For World Domination
-Playable Alpha now available!
http://www.rjcyberware.com
Well, our problems aren't as much in "everybody working on their own" as it is "nobody working at all" when it comes to coding. There has never been a proper leader in programming who would've pushed it forward (at least not in the past year or so), though the designers have been a little bit more active. As a result, the threshold for programmers to split has been very low, there has been a certain lack of direction and motivation haunting us. At least MD has one committed coder.
But hopefully we are changing. I've personally taken the resolution to set up CVS repository at sourceforge for our code, and maybe coming up with some standards on how we're going to use it. I'm not so sure if we could use the MD model directly though... there's no guarantee that any of the coders are permanently committed to the project so we'll need to fix things so that(ideally) no one person is critical to the process. You did make some valid points though:
It's good to have more than one people working on each code snippet. But on the other hand, I don't think we would be motivated to do one thing at a time. It's like saying "you can't do this now, finish your vegetables first!". But anyway, even if we have several things being coded at once, I still think that whatever we do, there should be at least two programmers tackling the same code, and all the rest following the work through the mailing list and such. There may not be much difference between the results of two and three people, but there's a world of difference between working alone and working in pairs.
Code has to be in proper sections. That's almost a prerequisite for doing things in parellel, in an ideal situation the two pairs/groups working on different things wouldn't need to torture themselves with heavy synchronization of their results. Also, the designs of our software architecture we have so far have been made with modularity in mind.
Specific routines. This is very important, because when you dwell into your own code too much it can get very convoluted. Also, each model/algorithm and whatever we do should be, in my opinion, done in a lot of small steps. Object orientation helps a lot in this respect and we're not even dreaming of going procedural (well, maybe some of us are, I can only talk for myself...). Here, we stumble into the lack of design we are suffering from... we have the design doc, but that's definitely not enough. I hope that once we get the basic software skeleton finished, it's going to be easier to develop the models and code them somewhat simultaneously, which should motivate the designers.
It's nice to see that we're not considered hopelessly lost by our fellow alt civ projects. It's not going to be easy to get out of this ditch, but we'll certainly give it our best shot. Maybe you'll see some results in about a month or so, hopefully in form of working demo.
Don't mind us, we are just trying to die here! (Seriously, it would be nice to get the designers at least moderately interested in this project again, now it seems only the programmers are excited.)
There was discussion about turn order and technology models, the latter seems to still be underway but I think it's safe to say that we've got the turn order covered as well as is appropriate at this point of development.
Since ten people still seem to believe we can still accomplish something -however modest- I think we shouldn't give up yet.
Personally I often do not have the slightest idea what is actually going on, though I read the boards quite frequently. I think it is very important that someone -definitely not me- with clear understanding of the programming process, decides on which aspect we should concentrate. Nor should we mistake discussion for progress.
In the past I hope to have made some useful contributions. I am rather uncertain about it, because to me it has always been obscure who take(s) decisions and what was done with my few intelligent and possibly effective ideas. Yet I have some experience with designing games -though not professionally- because I have spent a lot of time designing Diplomacy variants or similar games and have played many differently structured board games. Basically, designing a computer game is -in my view- NOT an essentially different activity. A computer is just a lot faster than the human brain, especially when calculations have to be made.
Before one can become truly creative, one needs some possibly working game structure (read: a game one can play with one another) -however crude- to which features can be added and/or modified. Unfortunately this basic structure is not there yet.
I think we need some document with our "Rules of play".
Something like: "GGS is played on a map containing 600,000 hexes. The goal of the game is to score Victory Points(VP).
There are several ways to win points. When a player has accumulated 100 VPs the game automatically ends and this player wins the game.
The game is divided into megaturns which represent 100 years. When a megaturn has been played out completely, all participating players can score VPs, if any....."
This is of course just an example. Yet I hope this will force us to design in a more structured way.
It doesn't actually do that on my system, does it do that on anybody elses? On mine it is really transparent, just like a windows cursor, very bizarre. 
Tweet
Comment