I've had a bit more free time recently and so I've managed to progress with hxnova http://code.google.com/p/hxnova/ (23,300 lines ). The server is functioning but needs more testing and few more things to be implemented. With the server at least running, I started on the client to enable some better testing and so far I've finished a signifigant part of the map renderer:

http://www.chasekernan.com/map.jpg

The only problem is that I really dislike doing UI work (and I'm not so good at it) and so I'm looking for anyone who'd like to help out (the ui could be made with flash, javascript, silverlight, etc...).

On another note, I've also finished a component editor and I was wondering if anyone had an open set of graphics that I could use.

[Updated on: Sun, 26 October 2008 00:38]

Report message to a moderator

Report message to a moderator

I could make graphics too if desired.

I'm not keen on a Flash-driven interface myself, but if it works it's better than nothing.

How well does your version support customization and modding?

[Updated on: Sun, 26 October 2008 16:44]

Report message to a moderator

Report message to a moderator

ck_drknes wrote on Mon, 27 October 2008 00:21

As far as modding, it should be fairly easy. None of the numbers or components are hardcoded (and can be changed mid-game). The internal workings can be entirely changed too. I'm using a slightly weaker version (but dynamic and interpreted instead of compiled) of haxe called hscript to load the variables from an external configuration file. I could mark any method that some one wants to customize as dynamically-bindable and they could write the new version in that configuration file using hscript.

That sounds really interesting. I was hoping to someday write a server for Stars with these same capabilities, only I seem to never have the time.

Quote:

If speed is required, the changed code could be written in haxe then merged in at runtime as well. However this only works on statics, but it could be made to work on instances too...

On the issue of speed, how well does your code cope with big universes? 16 races slugging it out among 800-1000 stars can be very demanding.

It would also be desirable to have an easier management of fleets and planets. Do you have any automations or other tricks for that?

Last but not least, I hope the unfinished parts will be done soon. I'd love to see the whole thing working and in a playable state. Just exactly what is that isn't yet finished?

Report message to a moderator

m.a@stars wrote on Mon, 27 October 2008 06:09

On the issue of speed, how well does your code cope with big universes? 16 races slugging it out among 800-1000 stars can be very demanding.

Sure, for a 386

I think a generic 1gb+ processor should have no problem.

Report message to a moderator

Coyote wrote on Mon, 27 October 2008 22:03

I think a generic 1gb+ processor should have no problem.

Please allow me to rephrase: we already have old slumbering Stars!2 for "Huge" universes of up to 999 stars. But what about some real challenge, say, 64 races competing for the conquest of 10000 stars?

Report message to a moderator

Report message to a moderator

[Updated on: Tue, 28 October 2008 18:10]

Report message to a moderator

Coyote wrote on Tue, 28 October 2008 03:57

If you want the game to take 20 years to play, go for it!

Actually, I'd rather games were shorter while keeping interest up. Hence my hoping for better management aids in the game.

Quote:

I don't see why we need upper limits on that sort of thing, just input numbers or something.

Upper limits are usually setup so memory or disk or CPU or all of them don't explode trying to gen the turns.

Report message to a moderator

Coyote wrote on Tue, 28 October 2008 03:57

If you want the game to take 20 years to play, go for it!

Actually, I'd rather games were shorter while keeping interest up. Hence my hoping for better management aids in the game.

Quote:

I don't see why we need upper limits on that sort of thing, just input numbers or something.

Upper limits are usually setup so memory or disk or CPU or all of them don't explode trying to gen the turns.

Report message to a moderator

Report message to a moderator

Coyote wrote on Tue, 28 October 2008 20:30

How about starting conditions? It could speed things along if you could start off players with say 5 planets each (+1 for IT/PP). One thought I have is to allow greater detail in starting techs, eg. for each field, when you choose sheap/normal/expensive you also can pick a starting tech level in that field - costing more per level for expensive techs than cheap ones, of course. When PRTs automatically start with tech levels, then they could have those levels selected by default but lower them if they wish for more points. This would take away none of the functionality of the current system, but open up a bit more flexibility.

Interesting ideas. Balancing them will be tricky, though.

Report message to a moderator

Heh, you should hear what I wanna do to CA then. Or AR for that matter.
Those are more ideas for a mod or sequel version than a straight-up Stars! clone however, since they'd mean that you couldn't necessarily build the same races you could otherwise. Not that this would be considered an entirely bad thing, mind you...

[Updated on: Wed, 29 October 2008 20:04]

Report message to a moderator

But, do you have also a way to balancing the cost & power of all these ideas so that the game or scenario keeps playable?

Report message to a moderator

Report message to a moderator

m.a@stars wrote on Mon, 27 October 2008 09:09

ck_drknes wrote on Mon, 27 October 2008 00:21 As far as modding, it should be fairly easy. None of the numbers or components are hardcoded (and can be changed mid-game). The internal workings can be entirely changed too. I'm using a slightly weaker version (but dynamic and interpreted instead of compiled) of haxe called hscript to load the variables from an external configuration file. I could mark any method that some one wants to customize as dynamically-bindable and they could write the new version in that configuration file using hscript. That sounds really interesting. I was hoping to someday write a server for Stars with these same capabilities, only I seem to never have the time. Quote: If speed is required, the changed code could be written in haxe then merged in at runtime as well. However this only works on statics, but it could be made to work on instances too... On the issue of speed, how well does your code cope with big universes? 16 races slugging it out among 800-1000 stars can be very demanding. It would also be desirable to have an easier management of fleets and planets. Do you have any automations or other tricks for that? Last but not least, I hope the unfinished parts will be done soon. I'd love to see the whole thing working and in a playable state. Just exactly what is that isn't yet finished?

the original game was meant to run on a 286, without a coprocessor. the Jeff's took advantage of doing things with binary arrarys (aka double long ints of 64 bits) to do XORing and bit shifting to subtract damage or indicate what components a ship had. made for some very fast computing and an elegant design. also made for the nubian alpha torp stack ... feature. probably still the most flexible way to do ship design, even though it doesn't account for loss of ability when a ship is damaged. I'm just sayin' is all.

Good luck with your development.

Report message to a moderator

Report message to a moderator

FYI, this in what happens in Chrome: screenshot

From what I saw in IE/Firefox, it appears to be centered on the top-left corner.

Please to be having the zoom invariant point in the center of the view.

Also fwiw, I despise flash.

But otherwise very cool

[Updated on: Fri, 31 October 2008 16:42]

Report message to a moderator

Report message to a moderator

swp1 wrote on Fri, 31 October 2008 01:06

the original game was meant to run on a 286, without a coprocessor. the Jeff's took advantage of doing things with binary arrarys (aka double long ints of 64 bits) to do XORing and bit shifting to subtract damage or indicate what components a ship had. made for some very fast computing and an elegant design. also made for the nubian alpha torp stack ... feature. probably still the most flexible way to do ship design, even though it doesn't account for loss of ability when a ship is damaged. I'm just sayin' is all. Good luck with your development.

Thanks, but it seems somebody else will reach the goal 1st.

Report message to a moderator

ck_drknes wrote on Sat, 01 November 2008 00:58

The files are in xml so someone else can develop a client in another language but for now im sticking with flash.

As long as the server works, the flash client shouldn't be a great concern.

Report message to a moderator