Outpost Universe Forums
Projects & Development => Inactive Projects => GORF => Outpost 3D => Topic started by: Celledor on September 04, 2008, 04:12:10 PM
-
Welcome to the Outpost 3D project!
This project have moved from Truevision 3d to Unity3D. It is a huge difference and I will try to focus on the basics to get as much gameplay working as possible. Just don't excpect a full game within a year or two ;)
Content from any erlier versions will be replaced with new when there are some.
I will try to have a playable version on this URL (http://www.veus.se/Outpost3D/Unity/OP2.html).
(http://www.veus.se/Outpost3D/Unity/OP2.html)
Play, test and ggive feedback on the progress right in your browser!
-
http://forum.outpostuniverse.net/index.php?showtopic=3373 (http://forum.outpostuniverse.net/index.php?showtopic=3373)
Feel free to use those to help :) Sorry I didn't texture any of them.
-
Yay, another attempt :)
Just don't let anyone flush your drive on it...
Has anyone been recording the number of attempts at such projects?
-
http://forum.outpostuniverse.net/index.php?showtopic=3373
Feel free to use those to help Sorry I didn't texture any of them.
Cool thanks, I was hoping that stuff like this was laying around here after all the other projects so that I (or others) didn't have to do all the stuff over again.
If you or anyone else (i'm not that great at it but will give it a try) got the time, start texture some. Theses models only need to be done ones.
Yay, another attempt
:) Yep yet another, and if this one fails there will be another and another until someone just need to pick up the pieces and put them all together.
Just don't let anyone flush your drive on it...
Has anyone been recording the number of attempts at such projects?
Don't think so, but perhaps this page would have a counter... to inspire people to keep trying.
Will soon start puting source code and other stuff up so that anyone can take a look at it, will make a development special site for it. (I also believe that all the free, open source stuff should be collected in one place so if anyone got more links to more material, please post them)
I'm using Visual C# 2008 with the Truevision 3D engine.
-
Hehe, Hidiot, darn you for speaking everyone's mind. :P
I'm must say I am somewhat impressed that a screen shot was actually posted. Seems like all too many projects are announced before any work is done, and then disappear before any work is presented.
Well, just try to get some small and useful game component completed (and posted) before you decide to up and quit on it. :P
... not that we'll hold it against you if you don't. ;)
-
Well, just try to get some small and useful game component completed (and posted) before you decide to up and quit on it.
Will do... :lol:
-
Nice work!
Please keep working on it :)
-
What are those Satelite dishes on the left? Looks nice tho.
-
Maybe just satellite dishes.
The SF and garage don't have docks and the ground-part of their structures...
The universities blue color looks a bit bad It looks like it's made of large blue squares, instead of a gradient shadow-like texture.
Looking closer I see that that's because the color was just added over the metal texture of the structures. Since it's paint, it shouldn't be affected by the way the structure is build other than by its shadows.
Course if you make a sun moving around, shadows would have to be dynamic, including the color shadows.
Other than that looks good
-
What are those Satelite dishes on the left? Looks nice tho.
Just a placeholder structure and I would like to see a lot of npc campaign buildings so they might be used for that. Also had an idea that you would need to build satellite dishes to have satellites but things like that will come later.
The SF and garage don't have docks and the ground-part of their structures...
Again, low poly placeholder models... I’m not that good at modeling or texturing so I hope someone else is. Fenrisul gave better models, but they need to be textures and animated.
Right now I'm focusing on making the game work. Graphics come later...
Question:
Is there any place where all the info such a armor, health, description, tech-tree etc. for structures and vehicles are listed? Also game rules as when children are born, chance of accidents happen and all that?
-
seems awsome o.O!
-
There's the outpost text files. They can be extracted from a .vol I can't remember. I used op2mapper for that long ago. You have files with info on any data relating to initial unit/building stats, as well as damage types, etc. Improvements made to weapons or buildings later on can only be found in the tech files, as the game's text files only store base stats.
-
Tell you what - if you show me some Lynx vs Lynx combat and some basic pathfinding; I'll come back and model/texture/animate. Deal? :)
-
Heh.
Sheets.vol is a good place to look for a lot of game variables and stats, but it won't have everything. The tech trees (in Sheets.vol) also have a lot of stuff about the upgrades, but they're fairly large and it might not be quite so easy to read and extract all the info by hand. Many values also seem to be hardcoded into the game. We do have ways that could automatically extract some of the hardcoded info, but you sort of have to ask for specifics to get the code written to do it. There is a lot of internal details posted in the Programming forum (mainly the Coding subsection). If you can't find anything about it in Sheets.vol, then check the Programming forum. If there's nothing there, then ask and we'll probably look into it.
-
Tell you what - if you show me some Lynx vs Lynx combat and some basic pathfinding; I'll come back and model/texture/animate. Deal?
Sounds like a deal!
Hooman, Hidiot, will look into it...
-
I have downloaded the mapper but I can't extract the files in sheets.vol... there is some error.
"Non-fatal error in VolManager::ExtractFile: Extraction failed
Err = (-2147467259) Automation error
GetLastError = 0, Erl = 0
OS Version: NT 5.1 Service Pack 2"
Can anyone email me the .txt files?
-
Try extracting one at a time. Extracting all of them at once fails. If extracting one at a time fails, then I'll make you a .rar with them.
-
Use VOL Extractor (http://www.outpostuniverse.net/files/coding/VOLExtractor.exe).
-
I tried the VOL Extractor and all files except the sheets.vol worked.
Extracting one file at the time with the mapper also failed for some reason.
-
http://forum.outpostuniverse.net/index.php...e=post&id=65185 (http://forum.outpostuniverse.net/index.php?act=Attach&type=post&id=65185)
-
Thanks
-
2 new screenshots (see first post).
The first is an early main menu... I'm trying to make it look the same but in 3D. The planets and the missing Conestoga are 3D models that rotates and more.
The second shows a base and a few Lynx. The building-vehicle scale is diffrent from the original. Vehicles are smaller but (at least I think) more realistic and giving you a better overview and more epic battles. Did a very early battle test (no pathfinding or collision) with 200 vs 200 lynx, still looked pretty cool.
-
Looks really nice, but those lynxes are too tiny. I suggest making them somewhere between 1.4 to 1.6x bigger (I think).
Keep up the good work. You're showing promise.
-
I think the lynx are fine. I'd expect them to be about that size to fit inside of the structures.
-
The size of the lynx is fine Sincve every thing doesnt have to be one tile scale and out of proportion things would look like the belong together even more with proper proportions.
-
Ok,ok... I was just imagining playing with such small units and it didn't look good to me.
Then again... anything that shows progress is good.
-
Thanks for answers... how big or small the units will be when I release (the beta version) is not written in stone, if they are too small when doing som real gameplay then I make them a bit bigger (cause gameplay is what really matters).
I might even put in a control that lets the player choose size (atleast in single player).
Right now I'm just trying to get every thing to work (like they do in the original) in the alpha version... things will need to be rewritten in the beta as the code is starting to get a bit messy and ugly. I will do proper doumentation for the beta source code and stuff like that.
-
I trust you're keeping your code as organized as you can keep it?
Messy code now will put you down later. Experience dictates...
-
Hmm, very impressive.
I think what might make the lynxes look better, is not making them bigger, but making the ground texture higher resolution. The artifacts in the ground texture seem about as large as the lynxes are, and there is a very noticable difference in the texture resolution.
-
The landscape is not a top priority right now and I will work a lot on it later. Right now there is just one texture that is the same over the entire landscape.
But your right about the resolutions, I will also add some shadows that will make the whole thing look better, an perhaps some headlights of some sort.
-
Changed the second screenshot with a new one that also shows walls.
-
Anyone will tell you I am skeptical and hostile towards all attempts at an OP2 remake/sequel... But for some reason I have faith in you...
Hmm...
-
Will there be gates or anything? Cause your walls kinda partition the base in inaccessible sections
-
Anyone will tell you I am skeptical and hostile towards all attempts at an OP2 remake/sequel... But for some reason I have faith in you...
Well thanks :)
Will there be gates or anything?
I will experiment on gates and see how well that works.
...Cause your walls kinda partition the base in inaccessible sections
Yeah that was just a test to make sure the wall sections change properly (to corner, end, center etc.) when added. The same system will be used for the tubes.
Will also experiment on diagonal walls, always missed that in most RTS.
-
On the new screens. With that Moon scape terrain its really hard to see the lynx. Now if they had there head lights on it might make a difference.
-
I have switch focus on the development... I'm going to make sure that I get the proper design documents and diagrams required to make sure that the structure of the code dosen't get out of hand. And that it becomes as simple as posible to add/change the diffrent parts from one version to the next (and to in the future include/hand over code to others when releasing it open source).
This mean that there will probably not any more screenshots for a while.
After this I will probably put most work into the support programs, which later can be used to make mods (the official main remake will be in the form of a mod to the game engine).
-
It is probably a good idea anyway.
You needn't post tons of screenshots. Just dropping a line as to what you've done in the past days is enough to let us know how you're faring.
We still have confidence in you ;)
-
promising and fantastic. If finished, it will bring me back to op2 ;)
-
Thanks guys... its more fun to do some actual programming and see some ingame results but things like this must be done.
-
That is very true, but not neglecting a clean and easy to work on code is essential, as you'll want to avoid working on messy code you did a long while ago.
-
Hoping that you will continue work on this, so that it can get finish to status that it playable. Specially see how just by what editor you have in support program suggest long way down road mod-ability without has compile code over again add more unit, technology, and structures.
-
The support programs will add more work now, but less later as anyone can add contant such as the official campaigns, the right unit/structure values, ballance and more.
The support programs will also make it esy to change landscape textures, models and all that... I will only add placeholders that is to be replaced later on by anyone.
-
This is an early screenshot of the Mod & Content editor. The interface is more or less complete and I have decided to use XML to store the info, and I can alredy open and modify the files. As I use XML it will be easy to open the files on a webpage to show other what the Mod contains or even make a webbased interface to make some changes (but that I will leave to others ;) ).
To the right I have placed an Model/Map viewer that displays 3D content for selected unit structure etc. Right now all that is showns is a default 3D cube that can be rotated and zoomed in/out.
Starting with the tools and documentations is really the way to go.
(http://www.veus.se/ForumPics/EarlyModContentEditor.jpg)
-
Nice. Looking good! I'm excited :)
-
Btw, "Chassis".
:)
-
Btw, "Chassis".
The units have two parts one turret mounted weapon and a "cassi" (there might be a better word for it) that is the body with wheels/tracks etc.
You add a cassi and a weapon in the editor and combine them to a unit.
-
No, Hooman was telling you that "cassis" isn't a word. The word you're thinking of is "Chassis" as in the "Advanced Combat Chassis" tech.
-
No, Hooman was telling you that "cassis" isn't a word. The word you're thinking of is "Chassis" as in the "Advanced Combat Chassis" tech.
haha :lol: Now when you tell me I see it... thanks, my english isn't always what it should be ;) and I wrote the interface text rather late so I didn't dubble check... so there is probably more of that sort.
But hey thats what I have you guys for right.
-
... "double" ;)
Hehe, now I'm just teasing. :P
Actually I think you write fairly well. And I only pointed out that first mistake because it was in the GUI (twice).
-
I just had do post a new screen. I'm testing shadows and it look really cool, although I must admit that these shadows have very poor performance but it just for test.
And yes the Lynx are tiny (can you find them?) and must be bigger even if I do like them to be of more realistic size... but the gameplay comes first.
The work on the mod and content editor is going along very well...
-
Are you a god? This has to be fake.... i don't want to belive in such a lie, for nothing this good could ACTUALLY be done (it has been tried to many times before :). But, if you secede, i will come to your house, and clean it. You must be some sort of god, no?
-
Hehe thanks :D no not a god (or am I mohahah...) and no not a fake its the power and simplicity of Truevision 3D.
Its amasing to see how big of a change the shadows did so really hope I can get the to eat less performace.
Still there is much work to be done to turn these tests into a working game that dosen't require a monster computer (like mine :) ) to play it, but I will make sure that all possible grafical settings can be modified from the menu.
I just tested that the game will work on Vista, not that I use vista but still that is good... ;) however the game uses DirectX so it will be restricted to windows (and the people that can hack Mac and Linux to make it work that is).
-
Probably the most promising 3D OP project we've had.
(But... the Eden logo on your GUI is backwards :P)
-
Ah your right it is.
-
i've just found out about this project from the "OPU Winter Reunion" newsletter, and this is truly a great news that someone took onto making OP in 3d.
i guess it's way too early to seriously comment the graphic part (as you said it's meant to change anyway), but are you going to use dynamic shadows and bump-mapping? haven't seen how it's done in that engine you're using but usually it's not that hard to make, using the right textures.
and, about the textures, i have a copy of FilterForge software (professional edition) that's meant specially for textures generation. i've got it not long ago and still in a process of learning, but there's a lot of pre-made presets for textures that i can use to generate the new ones. so where i'm leading it, if someone is going to make the graphics part, send me a message and we can see what could be worked out
more about filterforge and examples are here (http://www.filterforge.com/)
-
gimme more screenshots! :kewl pics:
btw: I think this project should be given a bit more importance, because putting outpost 2 into 3d isn't an easy job.
-
i guess it's way too early to seriously comment the graphic part (as you said it's meant to change anyway), but are you going to use dynamic shadows and bump-mapping? haven't seen how it's done in that engine you're using but usually it's not that hard to make, using the right textures.
The shadows i'm using right now are dynamic stencil (I think thats what they are). Not sure about bump-mapping, whould be cool to have and the engine supports it but its to early to tell. Once the core structure of the game works and I put it open surce then people can add to it.
gimme more screenshots!
Will try to have a small demo movie soon, it will not show anything new only what the screenshots shows.
-
Well I was in a good mood so happy holidays to you, here is a short screen recording of the alpha version in action, sorry for the poor quality.
>> Outpost 3D Alpha video (http://www.veus.se/Outpost3D.avi)
(Its 55 MB in size).
Better quality will come later.
-
i love you :D
Any of the admins should really promote this project, as it has huge potential.
As i've seen, build menus are working, however the resources have not been coded yet, vehicles move...
I'm just happy to see something that someone has made and it works.
Respect ;)
-
Is this some kind of dream :blink: ?
Seems like I'll be able to fry those pesky Lynx with the almighty thor shammer (MAHAHAHAHW), and now in 3D!!! :lol:
-
I see that when you order a group to go somewhere, they'll all want to go to the point you clicked.
Maybe (as something to do later) make it so, when you build your RCC (Robot Command Center) or as an upgrade to it or something, groups will move much smoother, as in not the whole group going to just a point; each unit goes to its own point in a formation.
Just an idea :)
So far, you're a dream on its way to coming true.
-
As I’ve seen, build menus are working, however the resources have not been coded yet, vehicles move...
Well they are workingish ;) ... (Buggy alpha code where I just get things to work so that I can write better beta code).
I see that when you order a group to go somewhere, they'll all want to go to the point you clicked.
Maybe (as something to do later) make it so, when you build your RCC (Robot Command Center) or as an upgrade to it or something, groups will move much smoother, as in not the whole group going to just a point; each unit goes to its own point in a formation.
Just an idea
Actually right now the units will move to an individual point to form a "box" formation around the point I clicked (however there is no collision code in right now to make them avoid each other), but yes more work will be spent on the movement (hopefully full steering behaviors) and I will try to make multiple formations available. All ideas are welcome.
More alpha movies will follow...
-
Hmmm...
Talking about units moving in formation bothers me. I never saw the strategic value of having your units move in the shape of a triangle instead of that of a box. If you want to have units move in "formation" make sure there's a way to turn it off, for those of us who like large, disorganized armies and single-file Lynx lines.
-
I've just now noticed something, you are also coding AI?
-
isn't that Eddy-B's thing?
-
Not really?
-
off-topic, i know. But I had heard a lot about Eddy-B doing advanced ai's. Naturally, I assumed that it was his thing Mabye I am wrong......
-
off-topic, i know. But I had heard a lot about Eddy-B doing advanced ai's. Naturally, I assumed that it was his thing Mabye I am wrong......
Indeed, Eddy was doing that for the original OP2, but Celledor coding OP3D (i tried OP23D but that didn't work :P)
-
Hmmm...
Talking about units moving in formation bothers me. I never saw the strategic value of having your units move in the shape of a triangle instead of that of a box. If you want to have units move in "formation" make sure there's a way to turn it off, for those of us who like large, disorganized armies and single-file Lynx lines.
For the formations to work the formation must recognize the different types of units and make sure that e.g. some always stays at the back, behind some other type. But don't worry if I get this to work it will be an additional move option.
I've just now noticed something, you are also coding AI?
Not really that was just a test that includes units scanning for enemies, and the computer choosing which structures to build, never worked properly. So if anyone knows how to code a proper AI please do, the same rules and goals is the same in 3D as in 2D I think.
-
Not really that was just a test that includes units scanning for enemies, and the computer choosing which structures to build, never worked properly. So if anyone knows how to code a proper AI please do, the same rules and goals is the same in 3D as in 2D I think.
OP2 and it's AI were always a problem to code :D
Anyway, you should ask Eddy-B, or Hooman, or anyone else, since i don't know the name of everyone who knows op2 in depth from code to code. I they will be glad to help.
-
isn't that Eddy-B's thing?
that was my specialty :)
I had code to make 8 AI colonies that teamed up and beat the hell out of anyone. Now if i could only find my code lol.
-
so cant wait for a beta for me to tes!
:lol:
seriously send me the beta when it comes :angry:
-
isn't that Eddy-B's thing?
that was my specialty :)
I had code to make 8 AI colonies that teamed up and beat the hell out of anyone. Now if i could only find my code lol.
there is always the search box in windows.
if you have linux, you can send a penguin to recover it
-
Well, I felt that this project really deserved it's own forum. After talking with Celledor, he sounded interested in the idea -- so here it is, in its very own forum.
-
I love you too BlackBox :D
So, any news?
-
so cant wait for a beta for me to tes!
seriously send me the beta when it comes
When I got something for you to test you will know about it... it will probably be some kind of series of beta demos starting with a Menu demo, camera demo, vehicle/structure demo etc. adding more and more functionallity to each one.
Well, I felt that this project really deserved it's own forum. After talking with Celledor, he sounded interested in the idea -- so here it is, in its very own forum.
Great!
So, any news?
No not really, have been working on the code structure.
-
wow... this looks good. :blink: im guessing the radar dishes are lasers, cause the laser weapon kinda looks like a radar.
-
wow... this looks good. im guessing the radar dishes are lasers, cause the laser weapon kinda looks like a radar.
Nope the radar dishes are just radar dishes... or well they are one of the placeholder test models I use with no real purpose. But I have a simple model for laser "guard tower" ready to use when I get to code that part.
-
Just a question though, are you using all the sound fx from outpost2, or using third-party content?
-
I will try to use the sound from outpost 2 but it will be easy to change them later if needed.
-
Pathfinding and lynx vs lynx :P Then I come and flesh out the rest of your models :)
-
hehe, sounds great.. looking forward to the day that I can show a working stable demo with pathfinding and stuff but, it will take a while but I will get there.
-
Take your time. The last thing we want is you quitting the project for any reasons such as accidentally messing something up bad and feeling too distraught to fix.
-
Everything looks cool, though the buildings need to be touched up a bit (though I'm sure you know that)
I 'might' be able to help, since I do modeling of my own on my own freetime, but texturing is not something I'm very good at (plus, I have no idea what mesh type the buildings and vehicles use, so it's hard to touch them up without knowing whether or not Blender 3D *The program I use* will be able to open them)
-
Take your time. The last thing we want is you quitting the project for any reasons such as accidentally messing something up bad and feeling too distraught to fix.
This wont happen i promis, if I would mess something up that would just result in that the project taking longer... programing and designing games is my hobby and I have done it for a while. For me the end product is a bonus and if people like it yet another.
I 'might' be able to help, since I do modeling of my own on my own freetime, but texturing is not something I'm very good at (plus, I have no idea what mesh type the buildings and vehicles use, so it's hard to touch them up without knowing whether or not Blender 3D *The program I use* will be able to open them)
The placeholder models I made are done in 3ds studio and then exportet into .tvm or .tva which are truevision 3ds model format.
-
Yea, not supported on this end, could be due to how old the model format is but dunno, I'd have to ask on the 3d blender board. *sigh*
The best I can do is export to 3DS format, and then hand them off to someone who uses 3ds, right now I just don't have the funds to buy 3ds.
-
The .tvm and .tva is only used by Truevision 3d and required a special plugin. But when the time comes 3DS works fine as I can do the export and besides the game will most likley require some special info like certain groupnames to identify where turrets rotate on chassis, where light comes from etc.
I will create a well documented standard for this that the game uses.
-
how you doing?
any progress?
pease tell me you have another movie,
or a screen shot?
-
Well I got animated textures working... Sure I can make another movie it will not show anything new but more of the same.
Perhaps a massive amount of Lynx moving across the landscape (basic movment only no collision, obstacle avoidance or pathfinding ;) )
Or a Lynx avoiding buildings using a special method (not pathfinding) that finds and uses the buildings corners, sill a bit buggy and alpha state. Will probably not be used once the pathfinding is up and running but I'm testing diffrent things.
-
Coding is very hard, so basically, everything you do is fine :D (As far i get some material proof ;) )
-
Coding is very hard, so basically, everything you do is fine (As far i get some material proof )
Yeah it is, but finding a way/the best way to do things is harder most time when you know how to do it it's not hard to code it... but the challenge id the fun.
-
The "first iteration" of the code structure is complete and I found some dos and don'ts... somethings just ended up good on paper but got to complex when they where used. And as the simplest way is almost always the best way I will rewrite parts.
I have also started to do some work on the interface editor that will make the main menus and sidebar interface much more dynamic than in the Alpha test version. This will take longer to make but when done speed interface things up alot.
-
Thank you for sharing your progress :)
-
Well sure, thats the whole point of this forum.
-
Well sure, thats the whole point of this forum.
I believe that was a dig on the OP3 Genesis project :P Sworn to secrecy.
-
It would have been funny, but it probably wasn't since he wasn't around for all of that... I think?
-
It would have been funny, but it probably wasn't since he wasn't around for all of that... I think?
Yea; thats why i bothered to mention.
-
Touche... or something.
Anyways, I'm going to get back to work on my latest plan to bring untold pain and suffering to New Terra.
-
So... how about releasing a demo of what ur working on, just to thrill the croud (or turn em into man eating beasts making you rush the rest)?
and what (not exactly) would be graphic requirements and potential (like crysis good)? that way i can tell if i will put it on my laptop.
good work :P
-
He'll release a demo when he's ready, and right now it looks like the game isn't even playable.
-
It would have been funny, but it probably wasn't since he wasn't around for all of that... I think?
Hehe no I didn't dig on any project...
He'll release a demo when he's ready...
Yeah the demo will be done when it’s done, lots of work on the tools and code structure right now.
and right now it looks like the game isn't even playable.
That’s right just a bunch of parts lying around doing nothing, the alpha can be "played" but you can't do much in it. Just testing different pieces of code.
Hope you realize that it will take a few months or more before anything that’s even looks like a demo will be ready.
-
i just have a stupid question that may be way to early to ask but anyways:
you already said that there will be an multiplayer system (which i like :3) but will this system
be based on TCP/IP or will you intgrate a hub like system where you can connect to gather servers?
i know that question might dont got an answer right now but i was just interested in your planning or oppinion on this part
to be honest i was just wondering if there will be like a system where you can add your own hub servers on a list and cconnect to an irc like system in which you then finnaly find your opponent
well anyways
as far as i can tell even thought you say you dont did much on the grafics i say they are most impressive by now and i hope you keep up the good work on the code front ^^
if you need any help please ask i somehow feel that your doing it all on your own
and that makes me feel bad ^^
-
i just have a stupid question that may be way to early to ask but anyways:
Hehe stupid no, early yes...
At first it will only work as a single player game, multiplayer will come later. How this is done I'm not sure at as that kind of programing is not what I'm good at. That is one point I will require help with.
I' not sure which way is the best one to use but adding your own hub server would be nice.
if you need any help please ask i somehow feel that your doing it all on your own
and that makes me feel bad ^^
I will start a new thread where I post things that I need help with, right now its hard to bring in others to the project.
-
Hmm, network multiplayer support can be kind of hard to bolt on in some cases if you haven't done a bit of preparation up front. Depends a bit on the structure, but if you ignore network multiplayer issues, then often not all of the needed structure will be there. Things like latency are important to consider. You'll probably need to delay the execution of commands a bit from when the player issues them to hide the network delay. If you're processing the game in ticks/cycles, and you wait for commands from all players without allowing for such transmission delay, then the game will lag horribly and play really choppy. There are also issues like maintaining sync. It's not too hard to build the game so that all random numbers are always generated and used in the same order, but if you haven't considered this to be important, then it can be a huge task to change after the fact. There are a lot of other issues too, but those are probably the two biggest ones, and probably not very hard to solve if you plan for it.
I've come across a few good reading sources on the subject that very clearly explain what the issues are, and properties of different solutions. If you want I can try to dig up those sources for you.
-
What you say is true but I still think I will concentrate on getting the basic functionality of the game up and running first. If you could find those sources that would be great... I will try to have it in mind when I write the code.
If there is any programmer out there that has to little to do, perhaps you could start to do some coding one the network part. Just starting with a simple chat program (in C#) and then something that sends objects back and forth.
At least there will be something to have as a base when the day comes to put it into the game.
-
Working on my own Outpost project I set up an authoritative client/server architecture right from the get go and am very glad I did. My approach is very different to what it would be otherwise.
You'll have to decide right now if you want a peer to peer system (where every client computes the simulation, and only changes to it are communicated, and the "server" does nothing more than coordinate the different clients), or a more traditional client server model where the server runs the simulation and the clients communicate to the server.
If you do decide to hold off writing networking, you might want to consider programming using a paradigm that uses events (Like MVC), if you are not already.
-
What is the strength/weakness between the two?
MVC sounds interesting will look more on that...
So many choices so mush to think of :rolleyes: ... I to just want to get down an do some code... working on the tools do give me some time to think of stuff like this and the first version will not be perfect. A program is never as good as it is after being rewritten a few times.
The help and tips are most welcome.
-
Chapter 2 of this pdf (got it from wikipedia) should help answer the question.: ftp://ftp.tik.ee.ethz.ch/pub/students/200.../SA-2003-16.pdf (http://ftp://ftp.tik.ee.ethz.ch/pub/students/2002-2003-Wi/SA-2003-16.pdf)
Here are pros and cons for the more extreem examples:
NOTE: Server can mean a dedicated server, or the player hosting the game
Server/"thin" client: The server has the entire gamestate and transmits the state to the client, and the client transmits requests to alter the state. There are low computational requirements for the client, but high bandwidth requirements, especally for the server. This can result in a laggy response. Advantages is that any attempts at cheating can be kept to a minimum as a well designed server has to authorize all incoming action requests as valid. On the other hand if the server goes down, so does the entire game. But there is no risk of a client's gamestate from going out of sync from the others.
Server/full client: The other extream is the client and servers all run the entire simulation. The server has the authoritative game state. A change requested by a client is sent to the server and also processed by the client. The server then propagates the change request to all other clients. This increases the computational needs of the client but greatly reduces the bandwidth requirements. Lag seems to vanishes as the client will update its own state before the server or other clients. Cheating will require closer monitoring. The server and clients will also have to make sure the gamestates match up every now and then. Clients which gamestates differ can either get a new gamestate from the server or drop the connection. A user could also access game state information of other players that he might not otherwise have access to in game.
For a client server model there are also all sorts of middle ground too. Another smart way is to have the server have the full authoratative state, and each client also manages a copy of the gamestate that only the user can see (so the client gamestate show the map and process the user's own colonies, but has no information of the colonies of the other useers)
Peer to peer: Is a lot of ways similar to full client server, except that there is no authoratative gamestate. Each client is responsible for transmitting state changes to the auth clients, and the other clients are responsible for authorizing those changes. The bandwidth requirements of a "server" are split among all the peers, but this causes bandwidth needs for each peer to grow expodentionally with each new peer. The major advantage is that there is no server to lose the game, if a player is dropped the peers can renegotiate their connection and the game resumes (preventing the server/host dropping issue).
-
Most RTS's are peer-to-peer, simply because of the huge amount of stuff that needs to be simulated and synced. OP2 itself follows this model once the game is started (not in lobby).
-
the peer to peer system got an bonus which wasnt postet before. since it has the option that you can manualy like op2 chose your ip to connect to or you could use a hub server which provides open server(hosting clients) ip´s which you can connect to for me this seems the best way since cheating can be stop with clients interventing unauth behavior like requesting informations or making unsync moves etc from the other client software etc
-
Unless it's an MMO, it's probably peer to peer.
Btw, peer-to-peer traffic does not increase exponentially. If you have n peers, where each peer has a connection to every other peer, then there are n^2 connections. That's only a quadratic increase. Far fewer than an exponential increase. Also, the more important point here, is that the traffic per node only increases linearly. That is, your own computer will only have n connections, even though the total number of connections between all computers in the entire system might be n^2.
I should also point out that any validity checks done by a server can also be done on each client. It's the same amount of coding either way. You write the checking code once.
The Server/thin client doesn't seem particularly relevant here. That would be like a web based game, where the web browser is a "thin" client, and doesn't know anything about the game, just how to display generic web pages. Not surprisingly, web browsers tend to be laggy and slow. The amount of traffic generated by such a game is usually quite large, and I wouldn't expect to find too many (if any) real time games that work like that.
If you want decent performance out of the game, you're probably looking at doing symmetric processing on all nodes, and just passing commands around. (NOP if they've done nothing, just to keep the timing and confirm that they've actually done nothing, rather than a packet was dropped). Usually, it's one packet type for every in-game command the player can order, but only so long as it actually updates game state. If there's a command to view some information menu, like the morale report, then other players don't need to know about that. It doesn't change game state, and so it doesn't need to be synchronized between computers. If they move a vehicle, or order it to attack, or self destruct, or for a factory to build something, then it needs to be sent to the other players. You'll probably want to do some filtering and dropping of certain commands to save bandwidth though (or rather, leave it to eventually time out and send a small NOP packet), such as they try to build something but don't have the resources. You might also want to drop certain move commands if it's redundant, such as telling the same unit or group of units to move to the same location. That also has the benefit of not having to run the path finding algorithm again, which is usually somewhat slow.
I should also stress the importance of pseudo random numbers here. If you send the same random number seed to each client, then you'll never have to send random numbers over the network, which can save significant bandwidth. If there's some melee of 100 units going at it, you don't want to be sending the huge number of damage values flying across the network (and would you trust them anyways?). Just initialize everyone with the same seed, and they'll all generate the same sequence of random numbers. Note that this requires the game engine to always use up those random numbers in the same order. So things like processing of players or units should be done in the same order on every computer. Don't just assume the local player is always processed first, and then all their opponents. You should probably just have everyone assigned a player number, and go through them in order each time, or something similar to this. (Perhaps process units in the order they were created, or the order they're placed in some internal array). This also has the benefit of making the game repeatable. This can be fun, in that it allows people to save replays of their game, but it's also very useful for debugging. If something goes wrong, they can save the replay (or an error handler can), which can be sent to the developer so they can repeat and track down the bug.
This also has anti-cheat properties, in that the only real way to "cheat" is generally by sending commands that a player could normally issue through the user interface. Mind you, you should do some sort of validity and sanity checks on the data. It's still possibly for them to say, issue a command to move a unit that they don't own. In cases like this, just check for these things, and drop the packet if it doesn't make sense. As long as you check for dumb things like this, it's pretty hard to cheat, short of making some macro/bot to play the game for them with unusually fast decision making. Of course, bots usually suck in comparison to real players at high level strategy, so they probably won't be winning out here anyways if they try this, unless they can still effectively interact with the game, and are also good players to begin with. Btw, those recorded games can also catch and prove someone was cheating if they do find a way to send invalid packets that didn't have proper validation code.
Real time games also likely use UDP, rather than TCP. Generally, TCP is too slow, and too overkill for a real time game. TCP has simplicity advantages with the timeout/auto-retransmit, but it's implemented using ACKs and NACKs. With bursty traffic, such as web browsing, ACKs are important, since the sender sends stuff unexpectedly, and it won't know if it's packet arrived, unless it receives a reply. In a real time game, you're sending packets constantly, at known time intervals, so you'll know if a packet was dropped because it won't arrive on time, and so you won't need to ever ACK. If the packet arrives by the time it's needed, then continue on, otherwise, the game has to pause while you request a retransmit. Although, you don't always have to wait that long before requesting a retransmit. If you know about how long you should have to wait, then you can make the request a little bit earlier than you need it, or if you're queuing a number of packets and one seems to be missing (i.e., you've received the later packet, but not the earlier packet), then a packet was probably dropped and should be rerequested.
You can also use the average timing between packets to set the game speed. If the game speed is set to run faster than the packets are arriving, then it will be pausing for each one. That can result in jerky performance. Particularly if the packets aren't arriving at perfectly even intervals, which is usually the case. If you've ever done any statistics in highschool, such as z-scores and bell curves, this might be a good area to apply that knowledge to.
I remember one of the best articles I read was about the design of Age of Empires. I just googled for the paper, and I came across this: http://www.gamasutra.com/view/feature/3094...88_network_.php (http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php), which seems to be what I read, or at least very similar to it.
-
Thanks for the great answers will read the article later.
-
!OWNED!
-
lol said almost the same thing about p2p system without the many words ^^
but its like this story of the 2 guys infornt of 2 doors and you need to find out who is lying
when there are many clients its much more easy to tell which client doesnt uses the generel rule set of the game or cheats ^^
-
Sounds like the Byzantine General problem. Wikipedia:http://en.wikipedia.org/wiki/Byzantine_Fault_Tolerance (http://en.wikipedia.org/wiki/Byzantine_Fault_Tolerance)
They're talking about faulty systems in that article, but in the case of cheating, that "faulty"/traitor is more like malicious/cheater.
I don't think that applies quite so well to this discussion though, since there are some fairly obvious rules to the game that can be checked against. Plus, each person is telling their own orders to everyone else. You're not relaying orders for someone else, and possibly changing their orders as you do it. In that regards, it doesn't allow cheating per say.
I suppose this could be used to force a desync though. Send different orders to different players, and if they both believe what you told them you're doing is true, then they will go out of sync with each other. Heck, you could even force which one drops by sending bogus data to that one person, and executing the correct command sent to everyone else yourself. Hmm..., that could be an interesting way of forcing one of your enemies allies to drop. But of course, that assumes you detect the desync, and your action in that case is to drop the people that don't agree with you. If you're saving replay data though, you could always resimulate the game from the beginning to find the point of failure, and try to recover. Of course, if this was malicious, you don't really know who tried to cause the problem. It may have been the person who sent the bad message, or it may have been the person receiving the message who pretended they got a different message than they really did. It still lets you narrow it down though, so you'd end up catching the person pretty quick. At any rate, this is really no different from Ham blocking, and people that try that stuff generally get banned pretty quick.
-
the problem of desync is not real since each has its own ip and a port which is used to communicate so a false information can be filtered and wouldnt even affact any part of the active game
my point was about the peer2peer game since there is only a server to get the clients together like telling them the game partners ip´s and then leave them alone to play
one will host the game as a server/Client programm and the others who join in will be client only
then the rules surely apply that there is a common set of rules which each uses in base of the game but you wouldnt send "commands" which you use to command you units to the server
more likly you send a "like" map of you activitys like when you unit moved from 1x1 to 1x2 you will send the id of that unit and also the change of data
like
lynx
100%hp
loc:1x1
and you just update the known information
lynx
100%hp
loc:1x2
the known rule set of the server can search for un normal changes of the game like a lynx which moves 2 times its normal speed or a change of stats of units which wouldnt apply on the rules givin by the game
but still there are ways to cheat
if you server host has a different game rule set which has 2 rule sets one which is comform to the original and one which is a "mod" it would be posible to cheat
a system where the server external to an client (game server /) checks all changes is highly unusable since the connection speed wouldnt allow outside of an lan system to play at eyojable speed ^^
-
Yes, what your suggesting with the server is both slow, and requires the server to be trusted. Unless it's an MMO, that's probably not a great setup. If a player is the server, then they can send whatever commands they want to cheat. As for checking things like unreasonable speed, that requires defensive coding, and it's much harder to forget to check something and let invalid packets slip through. In a setup where only commands are sent, and all moves are simulated using known rules, there is less checking required, and hence less possibility for the programmer to forget something which might allow cheating.
As for the desync, consider three players, A, B, and C. If A sends packet p1 to B, and p2 to B, where p1 != p2, where B and C use the recived packets in their simulations, then B and C will be out of sync. Hence, player A can force his opponents to go out of sync with each other. This has nothing to do with IP and port. It's to do with how much you trust traffic in a p2p setting.
If there is a trusted third party, such as a game server, they can collect and redistribute information so as to guarantee it is all consistent, but this will double the network latency. It also requires such a server to be maintained and paid for by someone.
Failing a trusted third party, you can have everyone tell everyone else what commands they've received, and make sure they are all consistent, but this will also double the network latency, and lead to the same situation as the Byzantine General problems, which means less than 1/3 of the players have to be lying to reliably detect who lies. This implies at least a 4 player game to be able to point any fingers. You do still know ahead of time before a desync occurs though.
You can also send game checksums every so often to make sure the game state is in sync. But the problem here is that you don't detect a difference until after the desync. Still, this is the cheapest method, and doesn't necessarily imply any extra network delay. It might just require an extra 4 bytes per packet (or every few packets) to relay the game checksums.
Keep in mind, that all that extra effort is only if you're trying to detect desyncs. You can always bury your head in the sand, and assume the game plays perfectly with no errors, and that noone lies. This is actually how Outpost 2 works, and it works reasonably well. It takes quite a bit of effort and knowledge for someone to develop this sort of hack, and if you properly validate commands, they best they can do with this hack is cause opponents to desync. Again, this isn't really any different from Ham blocking or similar, which is way easier to do. Granted, it might be nice to throw an error in the face of someone who tries (using game state checksums), rather than have the game silently continue on. Basically, make sure people aren't wasting time playing a ruined game where the players all see something different.
I would recommend either just sending game state checksums every so often to make sure the games are in sync (preferable), or just ignoring the problem (pretty standard, and quite acceptable). You really don't gain anything significant with the other methods, and they have significant cost that will affect playability.
-
well from my point of view i though that there is a central host of a game that valids all actions as right so the only desync can happen to an client so if A is the game host C could be desync by a connection error
to counter work this problem you could liniar number all trafic packs so a failed package could be requestet also there is the posibillity to check against a failure if you use common networking systems like a 3 times repeat of the same package so a client would know if there was an error to the connection as implied by hte problem at hand there is never a fail prove solution the only way to counter work a desync is the mass of data send by the host if you asume that the host never is wrong so a desync that droped 1 package or 2 would be bufferd by 1000 which worked fine ^^
also for the part of posible corrupted files or something like that there is a posibility to use md5 as a checksum and check the files against online stored "auth" files
-
I think you're missing the malicious intent I was trying to illustrate there. Assume that A was trying to mislead the other players. Player A intentionally sent two different packets to two different players. Asking for a resend doesn't solve the problem. Player A can still intentionally send two different packets the second time. This is even worse if you assume the game host, who is a player, is trusted. (Let's say A is the host). That player could make arbitrary decisions about the game state and force them on you. If people get wind of the game working this way, they will almost certainly try to abuse this. A trusted third party is usually fine, such as a server run by the game producer, but that has ongoing cost for them to run. Plus, if the game relies on that server, and it goes down for any reason (such as the company going bankrupt), then the game becomes unplayable. Plus, as I said earlier, having to relay all the packets through a central validating server will double the network latency.
I would already assume linear numbers on packets, or else how would you detect if a packet was dropped or not? (TCP uses byte numbers rather than packet numbers, but it's the same concept). The linear numbers don't help prevent a desync when there is malicious intent. Even if you checksum game state, you wouldn't catch it until after the fact. Trying to undo a game cycle is pretty much impossible. Too much game state has changed, and some information is probably lost along the way. (Like say a unit blows up, how do you know a cycle later that it existed? Sure you could save each game state, but that's probably megabytes of data per frame, and at 30 fps or so, that adds up really fast). If you wanted to backup by one game state, you'd probably have to reinitialize from the start, and resimilulate up to the previous game cycle using replay data (initial state + player issued commands) or something. Suffice it to say, it's not a light operation.
Resending packets without asking for them will probably slow things down. Especially on low bandwidth connections. Some people are still on dialup. What you're suggesting with sending packets 3 times would triple the bandwidth requirements. That would quite possibly noticably degrade performance.
Ignoring framing overhead (PPP - Point-to-Point Protocol (dialup), or Ethernet), the IPv4 header + UDP header is 24 bytes. Additionally, you'll need space for the commands, which will probably include a packet number, a command, and maybe a game state checksum. If you can issue one command per frame, at 30 fps, that's a minimum of 30*(24+(6?..12?)) = 900..1080 bytes per second. If you resend 3 times, that's already 3 KB/s, assuming the player isn't doing anything. Most 56k modems are actually only 56k downstream, with only 33.6k upstream. And those are bits per second, not bytes. If that was all usable, that's 4200 bytes per second. Often there is some overhead on the line so you might end up getting less. Older serial protocols often has settings for a start bit and a stop bit, which lead to 10 bits sent for every byte (8 bits). I don't know if this is still relevant with todays modems, but if it is, that 4200 bytes is further reduced to 3360 bytes. Ok, so you still think that's do-able? Now remember that data is flowing both directions. you have about 1KB/s outgoing per opponent, and 1KB/s incomming per opponent. For a 6 player game, expect about 5 KB/s out and 5 KB/s in. At the full 56k, and getting a full byte sent out of every 8 bits transmitted (which is usually not the case, due to the overhead of the underlying link layer), you would have at best 7000 bytes/sec of transfer rate. If you play at most a 4 player game, and if you only send packets once, and they're all perfectly timed so there is no congestion, and there is no overhead from the underlying link layer, and the player never issues any real commands, and the moon is full, the year is a multiple of 12, and your system bus is facing east, you just might get smooth game play. ... and you want to triple the requirements?
Actually, to be fair, Outpost 2 has a lower command execution granularity than a frame. It's only every 1/4 of a frame, and I think it usually works out to less than 30 fps, so if you do something similar it won't be quite that bad. But still, the average packet size in Outpost 2 is definately larger than the minimum size I suggested above. (I think a NOP was 16 data bytes + the UDP/IPv4 overhead). But still, if you want the game to only run choppy for a bit when a packet gets lost, rather than all the time, then don't resend packets unless you have to.
Oh, and don't forget the latency. The larger the packets, the more latency there will be while sending them, particularly over a modem. For every byte, that's 8 bits/byte / 56000 bits/s = 0.14 ms/byte. In the case of Outpost 2, with 16 bytes per NOP, and 24 bytes minimum of network protocol overhead, that's 0.14 ms/byte * 40 bytes/packet = 5.6 ms/packet. That's just getting between the modem and the ISP of that player, never mind the rest of the internet, or any opponents they may be playing against that might also be on dialup. Plus, you may have to wait for other older incomming or outgoing data to send before you can send or receive that new packet. At 30 fps, that's about 33 ms per frame, so expect delays of a few frames once you account for the full cost of the network delay, and processing time of each frame.
-
just to underline with that md5 autch check i meant a game client file check so there is at least no corrupt game client content a trainer for running games would be hard to make but still if the third party is always evil it will happen that there is an atempt and i guess a complete use of an dialup connection isnt that bad since these ppl shouldnt watch youtube while playing ^^
in the end still there is no net code but maybe there are some other ppl that can deliver this component i dont remember if this project is complete open source or only part open source : )
-
Man that is long answers... will have to read it more than once.
The game itself will be open source but probably not the tools as they can be used in other projects later in the future.
-
truth, i though source forge would be good enough, but hey, idk, i just like commenting.
-
Unless you are expecting branching and remerging I suggest Google Code (has SVN). I'm not a terrible fan of sourceforge.
-
Will see if I use any of these when I start releasing code, I have had a lack of time to do any real work on the project latley so i'm still coding the tools.
-
I give you pathfinding!
This is a little test program that I wrote to test the Truevision3D engines built in pathfinding system and I got it to work, still some smaller things to fix and I haven't tested in of large scale yet but it look promessing.
Here is a screenshot of the program:
http://www.veus.se/ForumPics/AiPathfinding.jpg (http://www.veus.se/ForumPics/AiPathfinding.jpg)
-
Unfortunately, you'll have to make your own (crappy) pathfinding system for when there's no RCC.
Your efforts to dodge work have been defeated by OP2!
-
How do the non RCC movment work in OP2?
Is there a way to get the code?
-
Great work man :D
-
How do the non RCC movment work in OP2?
Is there a way to get the code?
No, but for all intents and purposes without the RCC vehicles tend to hug the walls, though truth be told it doesn't help much...
-
Perhaps I can modify the pathfinding I have now so that it has two modes, one goog and one bad.
-
you could make it like a direkt route where the vehicle trys to get the most direkt way to the target but without evading any colision till its made an colision
like when its in sight its a problem not before
that would make the rcc interesting for more complex maps
and at open maps without anything in the way it wouldnt change anything
-
If any one feels that they have some spare time and whants to help out I think a document containing a complete features list would be nice to have. Sure I could make one but that would take time from the coding.
-
We don't know what features you want, therefore it is impossible for us to make such a document for you. :P
-
i haven't been following up on much in op3d, so can you just sum up your progress. I.E. Main menu rocks, path finder, some other things. thanks
-
Oh, I mean a feature list of op2 so that nothing gets missed when I start coding the actual game.
-
Ah. Well, it might be best to start a new thread so people can add on to it. Unfortunately, some people may think you're asking for feature requests, which could be annoying. Anyways, I'll see what I can think of.
-
I have added a new thread will try to start add some features myself to start with.
I have also uploaded a new version of the main menu demo.
-
Hello there! Outpost 3D sounds like a cool project. It might be what the Outpost-series needs! Let me know if I can of any help. I'm fairly good at 3d modeling.
-
You should have a blog or something, whree only you can add stuff, just to see the prgress of your work. I know it would be hard work, but maybe you could get some one to do it for you.
-
... Let me know if I can of any help. I'm fairly good at 3d modeling.
There will be plenty need for models later right now I’m using placeholders (that still looks like the end models). Will add a special thread where all modelers that want to help can talk to each other so that two people don't work on the same model. Will probably also need at least two versions of each in diffrent LOD.
You should have a blog or something, where only you can add stuff, just to see the progress of your work. I know it would be hard work, but maybe you could get someone to do it for you.
Perhaps, not sure I don't like blogs in general... but I am working on a new version of my site and I might add this project there together with the rest. There will probably be some kind of blog or forum for each project.
-
There will be plenty need for models later right now I’m using placeholders (that still looks like the end models). Will add a special thread where all modelers that want to help can talk to each other so that two people don't work on the same model. Will probably also need at least two versions of each in diffrent LOD.
Ok, sounds good to me!
-
Not much progress for a while no I'm afraid but hopefully I will have some more time soon.
If there is any good client/server programmer (c# .NET 3.5) out there who want to help and got some time over, it would be nice if that person(s) could create some sort of prototype that can send and recive custom objects.
Just a simple interface where the user fills a form with info, the client create a new object for that and send it to the server that send it to every one else.
I have other things right now that I need to code (might also rewrite some stuff in the main menu too get some more speed out of it) and this could speed things up later.
I know it would be better if I know what data is to be sent but it would be nice to have something to look at... or is this a bad idea.
-
If you're doing the whole project in Visual C# I can help a bit. I've got some brushing up to do as it's been a few weeks since I've looked at code but if you want an extra hand I'm around.
-
Yes I'm using visual c# 2008... sounds great, when the time comes you can send over the code and I can integreat it into the main menu (so that one from there can try to connect with others). Just to test that it works with the rest of the code.
I have some fixing (and perhaps some documentation) to do before I can release the source code for the main menu (don't want to release ugly code).
-
Just tell me whatcha need and give me whatcha got and I'll get to it. Best way to contact me is MSN, Email, or forum PM.
-
Okey probably time for a progress report... not much unfortantly. Stuff has gotten in the way but I am still working... This project will have its ups and downs.
What I have been doing:
- A progress bar for the loading screen yay!
- Looked at a network library... that didn't work out.
- Fixed a few things on the menu (misc technical stuff that isn't visible) so I can now start to do the ingame menu and rendering.
So expect in the next version to get a black screen whith the ingame menu when you start a tutorial, colony game or campaign. Will release in a week or two..ish.
-
*hugs* keep up the good work celledor. Keep in mind that your own worst enemy is your bordom, so make sure to take breaks when you start to find yourself sighing over it too much
-
I will :D, it was when I was borded I started replay outpost 2 and got the idea to make the remake in the first place.
-
Damn, spent the whole day rewiting core stuff for the interface. The parent/child relations between diffrent components didn't work in all situations but now this should be fixed now... was a bit tricky.
-
I have started to code the landscape handler so this will be in the next release. And I'm working on a way to move the tutorials ingame in form of extra text boxes and such. Before the instructions where in a separate file.
I think recreating the tutorials one by one is a good way to go but wtill in a way that is as generic way. Will hopefully be able to fit the entire first tutorial in the next release.
-
Great news :)
-
news are allways great ^^
-
The computer is in for repairs and will be so until next week but I have a question for you... As I was working on the landscape handler I found that I have to decide between two ways of displaying the landscape.
As it is in 3D and you can rotate the camera you are able to see outside of the play area so the question is. Should I code so that the landscape extends outside the playarea or should it just end?
I think most modern games have so that the landscape is extended, this is more work but will in the end look better.
Do the border where the playarea ends need to be marked with a line or such or is in enough that the player cant place buildings of move units there?
-
The computer is in for repairs and will be so until next week but I have a question for you... As I was working on the landscape handler I found that I have to decide between two ways of displaying the landscape.
As it is in 3D and you can rotate the camera you are able to see outside of the play area so the question is. Should I code so that the landscape extends outside the playarea or should it just end?
I think most modern games have so that the landscape is extended, this is more work but will in the end look better.
Do the border where the playarea ends need to be marked with a line or such or is in enough that the player cant place buildings of move units there?
Have the camera angle limited. And just have it so you can see a little beyong "invisible wall" but you can't look to the stars.
-
maybe you can create a effect to make it look like a horrizon?
-
Yeah, extended mode would be best, if you're willing to make it.
Just make sure the cursor changes to let you know you can't go/build there.
Are you going to have a minimap of some sort?
If so, it might be worth it to show some kind of line on that.
Will these playable areas be rectangular, or will there be _shapes_ ?
-
Also, my personal update. The Client/Server is going slow, due to half of it being coded in ways I haven't bothered to look into before but for the most part it's all stuff I know just put together in a way I haven't tried before. It should be done within the next decade or three.
-
Have the camera angle limited. And just have it so you can see a little beyong "invisible wall" but you can't look to the stars.
I will play around with the camera angles to see what works best.
maybe you can create a effect to make it look like a horrizon?
There will be a fog system that will make the transition to the view distance look better so you can only look a certain distance. It will kind of look like a horrizon. But if I change the camera angle you won't see much of it but that might be the best in the end.
Are you going to have a minimap of some sort?
Yes there will be a minimap over the playable area.
Will these playable areas be rectangular, or will there be _shapes_?
Rectangular or square.
Also, my personal update. The Client/Server is going slow, due to half of it being coded in ways I haven't bothered to look into before but for the most part it's all stuff I know just put together in a way I haven't tried before. It should be done within the next decade or three.
Well that you are working on it is good enough.
-
Also, my personal update. The Client/Server is going slow, due to half of it being coded in ways I haven't bothered to look into before but for the most part it's all stuff I know just put together in a way I haven't tried before. It should be done within the next decade or three.
Well that you are working on it is good enough.
Just don't ask for a copy yet, lol. It makes the Leaning Tower of Piza look like it was built on stable ground.
-
1. It used to be stable when they built it. (From their point of view)
2. What stretch of land has always been and will forever be stable on this planet?
Just take care not to make it too messy, so you can return to fix it if needed later. Without spending 3/4 of the fixing time finding the issue.
-
1. It used to be stable when they built it. (From their point of view)
2. What stretch of land has always been and will forever be stable on this planet?
Just take care not to make it too messy, so you can return to fix it if needed later. Without spending 3/4 of the fixing time finding the issue.
...damn ye, almighty Smart one...
And don't worry, I usually fix things after I break them.
-
The computer should be fixed today or tomorrow it was the motherboard that had crashed in some way and needed to be replaced... but production will be up again soon.
-
Finaly... the computer is back and I have already started to work on the next release and its starting to look good. Have changed the camera a bit and I like results, but it still needs some work.
-
Glad you fixed your PC issue. Hope it didn't burn a hole in your budget as well.
I'll be waiting to try the next release, but I'm wondering if that error will go away.
-
It didn't cost that much... whar error was that?
-
The error me and another person posted about in Source Files on pages 1 and 3.
-
Ah, that error... will try to find out what causes it.
-
I think you shouldn't bother too much yet, until someone who's had the error decides to install .NET Framework and then test.
It's been on my mind, but I still don't want to risk breaking anything...
Then again, for a game it is best to not depend on anything more than what resources it provides within its own package, plus graphics, processing power and the other standards.
-
True and at a later time I will see what I can do about it.
-
I'm afraid I haven't been able to get much done in a while now, to much work and other stuff gets in the way but during this week I plan to atleast test a new shadow system.
-
Time is against me, its so fun to sit dwon and work on the project but no time so do it more than an hour here and there... so I'm thinking on releasing the code I have so far but I'm not sure thats a good idéa as I would like to have much more done before. It might be hard for you guys to do stuff right now but perhpas the best way is to let you look at the code.
-
Using a program to visual studio called resharper to clean up the code a bit, I can really recommend it for those that is programing in c#... it cost money but I got it through work. And I'm working on changeing the way I sav things in the game to files.
-
I have made a few nice improvments to the overall structure of the code and have the uints moing along thier paths (will need to make sure they don't collide with eachother though)... after I have multiselection up an running I will release a new version.
-
hey i have people tryng to help me on one of my projects http://forum.outpost2.net/index.php?showto...t=0&#entry70556 (http://forum.outpost2.net/index.php?showtopic=4777&st=0&#entry70556)
if no when we finish (im making level 1 map now ) could u try to 3d it?
-
Using a program to visual studio called resharper to clean up the code a bit, I can really recommend it for those that is programing in c#... it cost money but I got it through work. And I'm working on changeing the way I sav things in the game to files.
Im flat broke for buyin stuff (bein only 15 and all) but i would love to help... if posible
-
Happy place... Think of the happy place...
Deep breaths...
Ah, there we go.
Ahem.
I think he's a bit too busy for that.
-
Nice to hear there is progress on this. :)
-
Yes, just a confirmation that it is still being worked on is all we need to be happy :)
Also, jcj... if someone wants to help you, they will let you know in your own topic.
-
hey i have people tryng to help me on one of my projects http://forum.outpost2.net/index.php?showto...t=0&#entry70556 (http://forum.outpost2.net/index.php?showto...t=0&#entry70556)
if no when we finish (im making level 1 map now ) could u try to 3d it?
When I'm finished you can do this using the mod and content editor, or at least thats the plan.
Nice to hear there is progress on this.
Yes, just a confirmation that it is still being worked on is all we need to be happy
Yepp its still in progress, hoping that I will continue to have some extra time over to wotk on it, there will be ups and downs but the futher I go the more fun it its to work on it.
-
Don't forget to stay in touch with us so we don't end up thinking you fell off a cliff or something :P
-
Don't forget to stay in touch with us so we don't end up thinking you fell off a cliff or something
Will try not to... I have started a new topic where I posted a math problem I need help with: Math help (http://forum.outpostuniverse.net/index.php?showtopic=4820).
-
Okey so thing didn't work out the way I wanted... way to many things to do on the same time. So here is all the source that I have right now, if anyone want, be my guest to keep coding but only if you do so under opensource.
This code and any based on it should be open and avaliable for anyone to use.
http://www.veus.se/Outpost3D/Outpost%203D%20Beta.zip (http://www.veus.se/Outpost3D/Outpost%203D%20Beta.zip)
If I get more time in the future I will get back into this project but as of now I won't be able to work on it for an unknown time.
I still belieave that it is posible and hopw my code will help others.
I will ask any question about the project and code as often as I can.
-
A little screenshot of me playing around with unity 3d:
(http://www.veus.se/Outpost3D/Unity.jpg)
If ever a remake is made, unity feels like the way to go.
-
im into this necrophilia
-
Nice to see an update on this project cell.
The graphics you have there are a bit reminiscent of the most early 3D games, but I kind of like it myself. How is Unity comparing to the other tools you've used?
-
Yeah the graphics must be seen as placeholders.
There is a huge difference, before unity I had to program so much basic things myself (just to get things to render and have textures) but with unity it is more about the actual game. And the editor helps with alot even drag and drop with certain things. Its a very powerful tool and I recommend to try it out.
I will update when I have something new. testing different pathfinding packages now and it looks promising.
-
Nice to see, that you're using a platform independent game engine. I hope, the game will also be platform independent.
And are you going to use the free or the pro version of Unity?
-
Yeah that is another really nice thing about unity. Will allow me to upload playable content.
I'm using the free version at the moment but if I do manage to get the time to more or less finish I will get the pro version. But that can take a while.
-
I have updated the first post with some new info.
By using unity you will be able to test things from the browser.
I uploaded what I have now so check it out, its not much but:
http://www.veus.se/Outpost3D/Unity/OP2.html (http://www.veus.se/Outpost3D/Unity/OP2.html)
I will keep that url and update it now and then.
-
I have updated the first post with some new info.
By using unity you will be able to test things from the browser.
I uploaded what I have now so check it out, its not much but:
http://www.veus.se/Outpost3D/Unity/OP2.html (http://www.veus.se/Outpost3D/Unity/OP2.html)
I will keep that url and update it now and then.
Now you're in my territory sir :)
I am currently a full time software engineer whose job is to use Unity.
Please let me know if you need any hints/tips/Unity-pro compiles for shadows/effects n' what not.
Please let me know if you want to collaborate directly on this project. Either artistically or programming wise.
-
I have sent you a PM, read and get back to me.
-
I have sent you a PM, read and get back to me.
Replied.
-
will there be an update on the source files or repository to check out in the future?
-
Hi and sorry for the lack of updates.
There where some plans in motion where Fenrisul and I should work together but after that all kinds of other things got in the way.
During the coming summer I will do my best to take some time and work on this as alot of different things have setteled by then. There will be a period of 8 weeks that I will have almost no plans at all :)
I really hope to be able to at least add some new features and no matter if I do or not place all code in some kind of repository.
Its hard to believe how fast time goes by and how hard it is to focus on hobby projects.
-
Great that you are still caring about this one, though.
-
yeah its a great game worth a remake/reboot or some other re...
I actually hade some time sitting with it yesterday, not much added but some smaller changes.
-
I have uploaded a new version, only small changes...
There is now a simple minimap and you can select structures.
-
I have been working on basic pathfinding and have found a library for steering behaviours that looks promising. Will try to upload a new version next week.
-
I have uploaded a new version, se first post for URL.
-
Well this looks promissing. I will try to take a closer look as soon as I can. Thanks for the effort though.
-
Hey.
Thanks for the work, Its looking good :)
-
Hey all,
New version is up, this is added:
Team colors (on units) and if you move your lynxs close to the red enemies... they will start shooting at each other. No lasers, sounds or explosions so far but its a start.
To multi-select hold the ctrl key.
If multiple units selected at the some time they will move a bit odd but it very early movement and combat code.
-
New version is up, when the structure are selected they will display basic info.
When multiple vehicles are selected a summary will be shown them.
-
(I know I'm necroing but...)
Hey, this looks promising. Any new updates on it?
-
(I know I'm necroing but...)
Hey, this looks promising. Any new updates on it?
I'm sorry to say no, I have only spent a few hours here and there on this Project.
Still trying to get some time fore it but working on play testing a card game project that hopefully will be finished.
-
well, cell, I know I never did much to get involved with these projects in the past, but if you think it's still worth pursuing, I'd be happy to lend a hand where I can now. I've been finding lately that I pick up new things a lot faster than I thought I could and therefore feel that I could learn whatever system you are using for this well enough to do bits here and there. Though, I won't promise expert-quality work
-
well, cell, I know I never did much to get involved with these projects in the past, but if you think it's still worth pursuing, I'd be happy to lend a hand where I can now. I've been finding lately that I pick up new things a lot faster than I thought I could and therefore feel that I could learn whatever system you are using for this well enough to do bits here and there. Though, I won't promise expert-quality work
I have for a while though about placing the code and stuff on google codes or something like that so that anyone can download and give it a try.
Will try to do that this week so that you can download it and take a look.
-
Never give up Celledor, Non-completion is not an option.
-
As is extinction.
However, it's still nice to see it.