I've checked back here and there over the last several years, and am sad that this project has seemingly dried up. The Sundon Resurrection site is now gone, and this forum hasn't had an admin post in a long time.
Is there anyone close to the project who knows what happend? 45 developers signed on, but none to carry the torch? I hate to see such a promising remake disappear like this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyway, sometimes a resurrection takes more than three days... :) In this case, it's a LOOOONG resurrection, but don't count it dead yet. Please see the NEWS section for my latest post, and I can assure you that work is heavily underway at the moment on the trade engine: a collaboration of a friend of mine and myself. In fact, I am taking a break from working on play-testing the stock market right now, looking for bugs and less-than-desirable outcomes. The beauty is once the trade engine is perfected, it can be dropped under the game's hood with ease (theoretically), and the in-game GUI will feed right off it. It is a VERY dynamic market system that runs completely by itself (no need to script anything!), keying off of 14 variables that affect market prices (as opposed to the original Sundog's 3 variables and some forced manual-coding), which create very real-world market reactions and price fluctuations. Such variables are crime, wealth, planet fertility, temperature, political instability, and population, just to name a few. There are 40 stocks to play with (basically all the original stocks plus a few extras).
So don't despair! Even during the past couple of years of apparent inactivity here on SF, I've been drawing more artwork for the game. Some of my artwork (which was posted on Jeremy's old Sundog art page) has found its way onto Wikipedia's Sundog page, though a few of the graphics there are old and have been retired for newer versions since his page went down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Jeremy... I think at the moment we have the trade engine under control. There are a large number of modifications I have identified that need to be made in the next version, but after that I think it will be working fine. It is currently coded in C (I think...I'll have to ask my friend to confirm that) but he says it should not take much work to transport it to Java.
What we do need badly is what we've needed all along - the java framework for collision detection and triggering hotspots, enabling the player to finally move about in the Sundog world. I see this being absolutely critical for two main reasons: (1) Until there is some "playable" skeleton of the game, it will be hard for people to contribute to the project and place meat on that skeleton. Without anything tangible for the potential contributor to associate with, the project will seem too abstract, fragmented, and daunting for people with little free time to spare, and the project will remain essentially stalled. (2) Once we have a navigator engine built so we can walk around and trigger hotspots (for those nifty ZoomAction windows), this will allow the project members to add components and test them out, in helpful "real time" gameplay, such as engineering bays, cockpit, city tile layouts, the stock market, etc. This will also have the added benefit of infusing the excitement of seeing the game grow, and help keep project members engaged.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got some code laying the foundations of a general game loop in Java (gather input, update world, render world). It's made for action games mostly, as it continuosly updates the screen. But it is well structured and it could be used for Sundog, are you interested?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This little game framework still needs some work, but it does layout the appropriate places where things should happen. I have the beginnings of a vector Oids type game (an Atari ST classic) built on it, which should be removed but is good for understanding how the classes should be used so I'd include it in the upload as well.
Seb
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll try and come up with a small description of the classes. For the time being I think the best way is to ask any questions you might have and we'll go clearing up things as they arise. You'll find some comments in Spanish, hopefully the minority, as I wrote this to teach my brother some programming.
There are two runnable classes, Game.java and Oids.java. If you actually want to see something happening you should go for Oids.java as the other one just sets up a window and does nothing.
It has support for fullscreen, just change to: new Oids(true).start(); instead of false in Oids.main() but it's not well tested (last time I tried it worked on my windows box but not in my Linux)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Collision detection: I guess it means between the player and the obstacles like buildings, fences, rocks, trees.
I suggest to use a mask : black and white picture; white means traversable, black means obstructed.
Each tile already desinged needs to have its mask desinged too.
Collistion test:
solution 1 test only the center of the player.
solution 2 test every player's pixel.
in each solution each tile's mask needs to be designed so as to take into account the radius of the player (as everybody knows, every living being is a sphere :).
note that in solution 2, the test can be accelerated by transforming automatically every mask tile into a solution 1 tile (provided the set of tested pixels does not depend on player's orientation)
Hotspot : use another mask (the hotspot mask).
One could also use a 256 colors mask. Each color could then code for the type of the pixel: water, earth, road, mountain, wall, hotspot, etc... this involves a bit more work from the mask desinger, but could be useful in case we want to add more vehicles (like an amphibious car) in the wilderness mode.
Let me recall that in SFL, the pixel traversability (tested on the 4 pixels of the square player (at that time, every living being was a square)) was directly related to its color. I wrote ages ago a little tribute to SFL ( http://www.picard.ups-tlse.fr/~cheritat/Nost/nost.html ) where I took the same principle. However, I do not recommend to do that for SResurrection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the multi-colored mask idea. But if we went that route, we would need to think through all the possible hotspots we would need - otherwise there would be a lot of re-editing masks to be done. For instance, do the tables in the bars have to be hotspots? Is this how the NPCs can home in on the table to sit down? Can the game easily detect a mask color and send NPCs towards it? Otherwise, the other hotspots make sense: doorway, counter area (to trigger the vendor to come to you), gambling machine, etc. Each of these could have a color assigned...that could work.
As far as the collision test, would it be vastly harder to check every pixel or just the center? While the dot might not need to be too sharply tested, the larger player character (used on the ship, in bars, etc) would probably need to have every pixel checked.
I already have masks drawn for the ship, pod, and most of the city tiles. Once we determine how many types of hotspots there are, I can start rendering new masks with the colors in addition to the black and white.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We'll think about what you may do. Could you tell us more about you?
I'm about to leave for one week of summer vaccation.
Afterwards I hope to be able to work a little bit on the project again.
Arnaud.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, please tell us a bit more about what you are able to do. There are a number of things we could use some help on, which all need be coded in Java, so if you have some proficiency in Java and some time that you can dedicate to the project, we'd love to have you help out!
Thanks!
-Jake
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Some proficiency" in Java would be about right. I'm interested in helping and looking to get some experience as I have not had much luck getting a job in programming yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Matthew, I think a project you can jump on is to code the engineering bays. What we need is for all six of the bays to be coded, so that (a) the rows of parts only accept the right parts and "special" parts, and that the bays add up the health and efficiency of the subsystem.
For general information, check out this page here: http://www.silvae.net/sundog/game%20outline.htm and scroll down to the bottom where it says "SUNDOG ENGINEERING". This page shows how the program adds up the value of each part and row to come to the total health of the subsystem, and shows what parts are used, in which position, etc. I can send you additional info that might help you, so shoot me an email at jake (at sign) silvae (dot sign) net. These pages are also helpful: http://www.lukin.com/sundog/ship/systems.html and http://www.lukin.com/sundog/ship/parts.html.
The graphics you'll need are found here: http://www.silvae.net/sundog/gallery%20-%20interface.htm and here: http://www.silvae.net/sundog/gallery%20-%20objects.htm. It's possible that the part graphics won't line up easily with the connectors in the background image, since each part might be aligned differently than the others - if this is the case let me know and I'll re-save the graphics into new files and make sure that they are all identically lined up.
Email me if you have questions, but if you can tackle this project and deliver a functioning set of engineering bays, that will be a huge help to the project!
Thanks!
Jake
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I had a start on that back when we worked on this in the past that is still up on the CVS. I think it has most of what you need already. I'll look over it again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds good! I might be wrong, but I think the system health thing (the 0-16 points as described here: http://www.silvae.net/sundog/game%20outline.htm\) might be new or changed, so just make sure the code reflects that stuff in the outline, or if you think you have a better way of tabulating things, shoot me an email.
Anyway, see what you can do with it, and let me know if there are any graphical adjustments that need to be made. Your help is hugely appreciated!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've checked back here and there over the last several years, and am sad that this project has seemingly dried up. The Sundon Resurrection site is now gone, and this forum hasn't had an admin post in a long time.
Is there anyone close to the project who knows what happend? 45 developers signed on, but none to carry the torch? I hate to see such a promising remake disappear like this.
Sundog* rather, evil typo.. evil.
lol.... indeed. SPELL IT RIGHT! :)
Anyway, sometimes a resurrection takes more than three days... :) In this case, it's a LOOOONG resurrection, but don't count it dead yet. Please see the NEWS section for my latest post, and I can assure you that work is heavily underway at the moment on the trade engine: a collaboration of a friend of mine and myself. In fact, I am taking a break from working on play-testing the stock market right now, looking for bugs and less-than-desirable outcomes. The beauty is once the trade engine is perfected, it can be dropped under the game's hood with ease (theoretically), and the in-game GUI will feed right off it. It is a VERY dynamic market system that runs completely by itself (no need to script anything!), keying off of 14 variables that affect market prices (as opposed to the original Sundog's 3 variables and some forced manual-coding), which create very real-world market reactions and price fluctuations. Such variables are crime, wealth, planet fertility, temperature, political instability, and population, just to name a few. There are 40 stocks to play with (basically all the original stocks plus a few extras).
So don't despair! Even during the past couple of years of apparent inactivity here on SF, I've been drawing more artwork for the game. Some of my artwork (which was posted on Jeremy's old Sundog art page) has found its way onto Wikipedia's Sundog page, though a few of the graphics there are old and have been retired for newer versions since his page went down.
Wow, Jake, you are great. Yeah, maybe it would be time to revisit it. How's the stock engine? Want some help?
Thanks Jeremy... I think at the moment we have the trade engine under control. There are a large number of modifications I have identified that need to be made in the next version, but after that I think it will be working fine. It is currently coded in C (I think...I'll have to ask my friend to confirm that) but he says it should not take much work to transport it to Java.
What we do need badly is what we've needed all along - the java framework for collision detection and triggering hotspots, enabling the player to finally move about in the Sundog world. I see this being absolutely critical for two main reasons: (1) Until there is some "playable" skeleton of the game, it will be hard for people to contribute to the project and place meat on that skeleton. Without anything tangible for the potential contributor to associate with, the project will seem too abstract, fragmented, and daunting for people with little free time to spare, and the project will remain essentially stalled. (2) Once we have a navigator engine built so we can walk around and trigger hotspots (for those nifty ZoomAction windows), this will allow the project members to add components and test them out, in helpful "real time" gameplay, such as engineering bays, cockpit, city tile layouts, the stock market, etc. This will also have the added benefit of infusing the excitement of seeing the game grow, and help keep project members engaged.
I've got some code laying the foundations of a general game loop in Java (gather input, update world, render world). It's made for action games mostly, as it continuosly updates the screen. But it is well structured and it could be used for Sundog, are you interested?
> are you interested?
Yes !
Allright, where should I upload it to?
This little game framework still needs some work, but it does layout the appropriate places where things should happen. I have the beginnings of a vector Oids type game (an Atari ST classic) built on it, which should be removed but is good for understanding how the classes should be used so I'd include it in the upload as well.
Seb
Seb, that sounds good! We'd love to look at the code. Thanks for offering it to us.
You want me to put them up somewhere?
> Allright, where should I upload it to?
Usually, for files I want others to download, I put them on my webpage (on a hidden link). Do you have one ?
Hi,
I uploaded it to my server.
http://ushi.ferreyrapons.com.ar/sundog/oids.zip
I'll try and come up with a small description of the classes. For the time being I think the best way is to ask any questions you might have and we'll go clearing up things as they arise. You'll find some comments in Spanish, hopefully the minority, as I wrote this to teach my brother some programming.
There are two runnable classes, Game.java and Oids.java. If you actually want to see something happening you should go for Oids.java as the other one just sets up a window and does nothing.
It has support for fullscreen, just change to: new Oids(true).start(); instead of false in Oids.main() but it's not well tested (last time I tried it worked on my windows box but not in my Linux)
Hi everybody.
Collision detection: I guess it means between the player and the obstacles like buildings, fences, rocks, trees.
I suggest to use a mask : black and white picture; white means traversable, black means obstructed.
Each tile already desinged needs to have its mask desinged too.
Collistion test:
solution 1 test only the center of the player.
solution 2 test every player's pixel.
in each solution each tile's mask needs to be designed so as to take into account the radius of the player (as everybody knows, every living being is a sphere :).
note that in solution 2, the test can be accelerated by transforming automatically every mask tile into a solution 1 tile (provided the set of tested pixels does not depend on player's orientation)
Hotspot : use another mask (the hotspot mask).
One could also use a 256 colors mask. Each color could then code for the type of the pixel: water, earth, road, mountain, wall, hotspot, etc... this involves a bit more work from the mask desinger, but could be useful in case we want to add more vehicles (like an amphibious car) in the wilderness mode.
Let me recall that in SFL, the pixel traversability (tested on the 4 pixels of the square player (at that time, every living being was a square)) was directly related to its color. I wrote ages ago a little tribute to SFL ( http://www.picard.ups-tlse.fr/~cheritat/Nost/nost.html ) where I took the same principle. However, I do not recommend to do that for SResurrection.
I like the multi-colored mask idea. But if we went that route, we would need to think through all the possible hotspots we would need - otherwise there would be a lot of re-editing masks to be done. For instance, do the tables in the bars have to be hotspots? Is this how the NPCs can home in on the table to sit down? Can the game easily detect a mask color and send NPCs towards it? Otherwise, the other hotspots make sense: doorway, counter area (to trigger the vendor to come to you), gambling machine, etc. Each of these could have a color assigned...that could work.
As far as the collision test, would it be vastly harder to check every pixel or just the center? While the dot might not need to be too sharply tested, the larger player character (used on the ship, in bars, etc) would probably need to have every pixel checked.
I already have masks drawn for the ship, pod, and most of the city tiles. Once we determine how many types of hotspots there are, I can start rendering new masks with the colors in addition to the black and white.
*sticks head in*
Wow this thing is actually having work done again? If you need some coding done gimme a shout I'm still interested in seeing this come to life.
Excellent.
We'll think about what you may do. Could you tell us more about you?
I'm about to leave for one week of summer vaccation.
Afterwards I hope to be able to work a little bit on the project again.
Arnaud.
Hey, welcome back!
Yes, please tell us a bit more about what you are able to do. There are a number of things we could use some help on, which all need be coded in Java, so if you have some proficiency in Java and some time that you can dedicate to the project, we'd love to have you help out!
Thanks!
-Jake
"Some proficiency" in Java would be about right. I'm interested in helping and looking to get some experience as I have not had much luck getting a job in programming yet.
Hey Matthew, I think a project you can jump on is to code the engineering bays. What we need is for all six of the bays to be coded, so that (a) the rows of parts only accept the right parts and "special" parts, and that the bays add up the health and efficiency of the subsystem.
For general information, check out this page here: http://www.silvae.net/sundog/game%20outline.htm and scroll down to the bottom where it says "SUNDOG ENGINEERING". This page shows how the program adds up the value of each part and row to come to the total health of the subsystem, and shows what parts are used, in which position, etc. I can send you additional info that might help you, so shoot me an email at jake (at sign) silvae (dot sign) net. These pages are also helpful: http://www.lukin.com/sundog/ship/systems.html and http://www.lukin.com/sundog/ship/parts.html.
The graphics you'll need are found here: http://www.silvae.net/sundog/gallery%20-%20interface.htm and here: http://www.silvae.net/sundog/gallery%20-%20objects.htm. It's possible that the part graphics won't line up easily with the connectors in the background image, since each part might be aligned differently than the others - if this is the case let me know and I'll re-save the graphics into new files and make sure that they are all identically lined up.
Email me if you have questions, but if you can tackle this project and deliver a functioning set of engineering bays, that will be a huge help to the project!
Thanks!
Jake
Ok, I had a start on that back when we worked on this in the past that is still up on the CVS. I think it has most of what you need already. I'll look over it again.
Sounds good! I might be wrong, but I think the system health thing (the 0-16 points as described here: http://www.silvae.net/sundog/game%20outline.htm\) might be new or changed, so just make sure the code reflects that stuff in the outline, or if you think you have a better way of tabulating things, shoot me an email.
Anyway, see what you can do with it, and let me know if there are any graphical adjustments that need to be made. Your help is hugely appreciated!