Sudden-Strike-Maps

Frag ich mich auch manchmal.

Also wird an Open Strike nicht weiter gearbeitet ?

Doch. Nur die Umstände haben sich verändert. Aber im Bereich MP wird es wohl sowieso nie mit RWM konkurrieren können. Habe es ja schon mal erwähnt. Wenn der Sourcecode offen liegt ist allem nur denkbaren Betrug Tür und Tor geöffnet. OS ist dann praktisch nur für SP geeignet. Oder bei Leuten, die sich wirklich gut kennen und vielleicht in einem lokalen Netzwerk spielen auch für MP.

??? das heißt jetzt was?

macht Ihr weiter, oder nicht?

hmm, wirklich schade...

Wieso habt ihr den Sourcecode nicht bei http://www.sourceforge.net oä. gehostet und das Projekt anderswo bekannt gemacht?
Hätte sich bestimmt der eine odere andere dafür interessiert, daran mitzuarbeiten. Aber ich hatte schon am Anfang den Eindruck, dass das nicht gewollt ist?
Ich bin hier ausgestiegen, als es noch hieß: closed source und 3d ...

What's the status on this? I'm a Java programmer and I'm reporting for duty

Any code written so far? I'm afraid my German is very poor so you'll have to excuse me not reading the whole thread.

If no code has been written, then I suggest writing it in Java - this would allow us to port a version or a special version of it to Android later with ease.

flamming_python hat geschrieben:What's the status on this? I'm a Java programmer and I'm reporting for duty

Any code written so far? I'm afraid my German is very poor so you'll have to excuse me not reading the whole thread.

If no code has been written, then I suggest writing it in Java - this would allow us to port a version or a special version of it to Android later with ease.

Hi flamming_python!

I don´t know what the state of "Open Strike" is now, if there has been made any Progress at all .
But I am currently coding my own Sudden Strike Engine from scratch, at least I am trying .
I choosed Java because of the portability and with the use of an object oriented aproach there should be some fast progress possible. I dont know if Java will be the best option for the GUI stuff - but with a modular concept that layer could still be changed later anyhow.

My first step is to re-do the 2D SuSt2 with the known gameplay mechanics. I am currently messing around with the various file formats of SuSt if you have any information on this please tell me . The main goal for a prototype would be to play original maps like on the real game. After that, i would like to bring in new Features. (Better Graphics, better AI...).

Best regards

schnitzel hat geschrieben:

flamming_python hat geschrieben:What's the status on this? I'm a Java programmer and I'm reporting for duty

Any code written so far? I'm afraid my German is very poor so you'll have to excuse me not reading the whole thread.

If no code has been written, then I suggest writing it in Java - this would allow us to port a version or a special version of it to Android later with ease.

Hi flamming_python!

I don´t know what the state of "Open Strike" is now, if there has been made any Progress at all .
But I am currently coding my own Sudden Strike Engine from scratch, at least I am trying .
I choosed Java because of the portability and with the use of an object oriented aproach there should be some fast progress possible. I dont know if Java will be the best option for the GUI stuff - but with a modular concept that layer could still be changed later anyhow.

My first step is to re-do the 2D SuSt2 with the known gameplay mechanics. I am currently messing around with the various file formats of SuSt if you have any information on this please tell me . The main goal for a prototype would be to play original maps like on the real game. After that, i would like to bring in new Features. (Better Graphics, better AI...).

Best regards

But.. but.. that was my idea!!!!

I wanted to make a Sudden Strike engine in Java And I planned for it to be able to play original maps too!
Great minds think alike eh?

Right now I'm busy writing a utility-program in Java - a Sudden Strike map manager - I developed it from this idea here that I posted a week ago. Initially to just make a map-pack; a big archive of all the SP maps I found, together with scripts to enable the user to select their prefered mod & language.
However I soon came to the realization that a script system would not be enough for a satisfactory solution, and as a result my ambitions grew and my plans subsequently evolved into an entire Java program:

viewtopic.php?f=61&t=10677

The map manager will draw its data from a xml database of all all Sudden Strike 2/SSNM/HS/HS2/HS2: Fusion SP maps I know of. You will be able to sort and filter maps by language, version, mod & supported mods (many mods support maps made for other mods or vanilla SS2 and I take this into account), side/enemy/ally, map size, tileset, map type (historical/semi-historical/general/what-if/fantasy/special forces/mini-game), map series (if any, e.g. Total Victory) historic battle/operation (if any) & author.
As part of the same XML file database, there are also tables on mods (info about compatible mods, versions), authors (email addresses, web-sites, etc...), historical battles/operations (links to more information) and some other things; all this information will also be accessible from the interface.
If a particular map has any readme files, maps, other images - then they will also be displayed within the interface. Hopefully I will figure out the SS2 map format sooner or later, and a later version of this map-manager will eventually be able to show in-game descriptions and bitmaps too.
The map-manager is fully localized; the entire interface, all the names of all the sides/battles/map-types/etc... will be available in a choice between English, French, German, Polish and Russian. This will enable the entire international Sudden Strike community to use it (with the exception of our esteemed Chinese, Japanese and Brazilian SS2 communities - but support for more languages can always be added later; as Java and XML are both Unicode-based this won't be a problem).

Once a user chooses all parameters and all the maps he needs with the help of the filters and automated functions; the map manager will automatically create an archive for him of all the maps he selected.

So far - I've made a small start on the program, maybe about 25-30% of the localisation, and have finished most of the XML database; with the exception of filling in details on the actual maps - I've done 100 of them so far... only 400-500 left to go!

As part of my plans, I may eventually port the manager over as a web-based app based on Ajax or a similar technology, with the XML database and so on stored online, and users being able to use it to create archives of SS2 maps via a web-interface online.
However, just as easily - with a little adaption it can also serve as a full-fledged map browser for your SS2-remake.

I dont know if Java will be the best option for the GUI stuff

Java is just fine for the GUI stuff. Right now I'm working as a UI and backend Java developer in a company which has a very advanced custom GUI for its program - 100% Java. It's definately possible whether by Swing/AWT or by SWT (the later I have much less experience with); all the JDialogs, UIManagers, Borders, etc... can be subclassed or substituted for your own classes and you can make anything you want; while excellent 3rd party solutions already exist for some things like MigLayout as a layout manager.

I am currently messing around with the various file formats of SuSt if you have any information on this please tell me

I've looked a little at the hex-code of the SS2 SP map format (.ssm), but I wasn't looking for anything useful in particular. Maybe I'll take another look and research it more thoroughly.

The main goal for a prototype would be to play original maps like on the real game. After that, i would like to bring in new Features. (Better Graphics, better AI...).

Best regards

Yes!
And I suggest we combine forces - after I finish with the map manager I would like to progress to developing "Java Strike" proper.
So, I think a good first step would be to create a GitHub account where you can upload your code and commits and I can upload my code from the Map Manager too; firstly as a separate project but then later it can be integrated into yours as a map-browser. We can then use the GitHub account as the main development space. It will then be easier to get more people on board once we get the ball rolling so to speak, and the development process underway.

flamming_python hat geschrieben:What's the status on this? I'm a Java programmer and I'm reporting for duty
Any code written so far?

I have been involved with this project in the beginning but not over the last years. To give you a short impression on the status of OS: It started from a discussion about a mod for HS2 back in 2006 (I think). Because of the limitations of the Sudden Strike engine developing a new game seemed to be a better idea. We started to write a document describing the game design but didn't get much further than that. For a short time I tried to get things going again, had written some code e.g. to test localisation of GUI texts and some other ideas but then my job got too demanding... Packard and Striker then developed a graphics demo showing a scrollable map with background music. The download seems to be offline by now though. I wasn't involved in OS at this stage anymore but I think development has stopped. Perhaps Packard can tell you more if you send him a PM.

I have done some conceptual work (rudimentary unit class model, a little AI etc) for myself over the last years but nothing really elaborated. If you start developing I would be interested to participate.

Gareth hat geschrieben:

flamming_python hat geschrieben:What's the status on this? I'm a Java programmer and I'm reporting for duty
Any code written so far?

I have been involved with this project in the beginning but not over the last years. To give you a short impression on the status of OS: It started from a discussion about a mod for HS2 back in 2006 (I think). Because of the limitations of the Sudden Strike engine developing a new game seemed to be a better idea. We started to write a document describing the game design but didn't get much further than that. For a short time I tried to get things going again, had written some code e.g. to test localisation of GUI texts and some other ideas but then my job got too demanding... Packard and Striker then developed a graphics demo showing a scrollable map with background music. The download seems to be offline by now though. I wasn't involved in OS at this stage anymore but I think development has stopped. Perhaps Packard can tell you more if you send him a PM.

I have done some conceptual work (rudimentary unit class model, a little AI etc) for myself over the last years but nothing really elaborated. If you start developing I would be interested to participate.

Good!

I think the main thing right now is to organize ourselves a place on a web-hosting service for code like GitHub, and then we will be able to formulate directions, priorities, tasks and sub-tasks that we or anyone else can just come along, start development on and commit to the main code base.
I know I'll be working on this thing, schnitzel claims that he's already done some work and is prepared to continue - and then you and others like you can simply come along any time you want, or any time you have some spare time, and simply start working on the tasks and/or developing the components that specifically interest you.

Design documents would be very useful as they will help us chart out some of the game mechanics and specifics, but dependent on what type of design document it is - I would think that most such things would only be useful later on.
Right now we need a development plan; what components to start developing and in what order, and using which technologies. I suspect that the main thrust for now would be towards:
- architectural decisions for the program
- data types that we'll use,
- the interface and how the user interacts with the game, some user-models and cases, etc...
- an idea of the features we might want to have further down the line and how we could build the program from the ground up in such a way so as adding the features and stuff that we want to add in the future won't pose a problem or necessitate re-writing the architecture

Followed by:

- a rudimentary graphics engine
- a data model for units and other entities
- basic path-finding

And then everything else

So actually your conceptual work might come in handy soon, if you can dig it up or are ready to continue with it.

Packard and Striker then developed a graphics demo showing a scrollable map with background music. The download seems to be offline by now though. I wasn't involved in OS at this stage anymore but I think development has stopped. Perhaps Packard can tell you more if you send him a PM.

Unless it was coded in Java, I think it's a better idea to start the code from scratch or rather from schnitzel's base, however their research into the SS2 file formats, mechanics, as well as their realizations of the graphic engine, sound, etc... might prove invaluable.

flamming_python hat geschrieben:But.. but.. that was my idea!!!!

I wanted to make a Sudden Strike engine in Java And I planned for it to be able to play original maps too!
Great minds think alike eh?

flamming_python hat geschrieben: Java is just fine for the GUI stuff. Right now I'm working as a UI and backend Java developer in a company which has a very advanced custom GUI for its program - 100% Java. It's definately possible whether by Swing/AWT or by SWT (the later I have much less experience with); all the JDialogs, UIManagers, Borders, etc... can be subclassed or substituted for your own classes and you can make anything you want; while excellent 3rd party solutions already exist for some things like MigLayout as a layout manager.

What I meant with GUI is especially the Canvas / drawing Stuff etc, if we can reach a good fps with Java. But i have seen that there is also a Full Screen Mode available, maybe that’s what we will need.

The only drawback I have experienced with Java yet, is working with raw files, because of the lack of unsigneds and basic Byte stuff (Pointers, WORDS, DWORDS, Big/Little Endian, etc.) in Java it is sometimes a bit of "a pain in the ass" to work with on that level.

Maybe we should start with a privat GitHub repo or something similar?
Because of two main reasons:
- Open Source vs. Closed Source Security stuff / especially when it comes to Multyplayer. I have no experience with that, but with the open source code cheaters may have a big advantage?

- Maybe someone can contact Fireglow, and make sure they agree with our plans? To clarify to them, that SuSt is such a great game we really love and we won´t let it die.
This is concerning the prototype which could use the resources of the Game. Which could be reached with some approach like this: - No resources comes with our code, the user needs an original Sust installation at his side and needs to use the original Fireglows unsue tool. Our code would only use then these files.
I am not a lawyer^^: viewtopic.php?f=7&t=3386
+ EULAs §6

The alternate approach would be to create all the resources by scratch, too. But i have no experience with that... and it will take a lot of time.

Best regards

the first little impressions

Nice to see news about Open Strike

Performance of today's computers is really great but youre sure with Java ? I'm no expert but for such complex game is Java useless. I'm not saying that it'sis bad language, only it has different use. I don't think it's realistic.

Anyway, it would be great if you publish any data which come in reversed engineering - file/data structures etc. Community can made some new tools.

Btw. Fireglow is dead. Do not expect any support from this side. Few people have asked for the source code - no reply.

schnitzel hat geschrieben:What I meant with GUI is especially the Canvas / drawing Stuff etc, if we can reach a good fps with Java. But i have seen that there is also a Full Screen Mode available, maybe that’s what we will need.

It's fine, modern Java has quite good speeds (think Android for example - it's basically just Java with a couple changed libraries and a different virtual machine but there are dozens of demanding 3D games made under it); and even 10 years ago there were some 3D games and apps coded in Java that are a lot more demanding on the machine than something like Sudden Strike is.

In the longer perspective, I want to keep the door open for swapping out the 2D terrain system for a 3D terrain system (albeit keeping the fixed isometric view ofc) and the option for 3D units too (think Blitzkrieg) - and I'm confident Java will handle the load. Even if it only runs at 80% of a C++ based program (and for everything apart from the most processor-intensive games this figure is pretty pessimistic for modern JVM versions); that's still more than enough for any computer built within the last 5-7 years to be able to run Sudden Strike with 3D terrain at decent speeds.

There is no need to use Swing (Canvas, redraw, etc...) to actually build the drawing/graphics system BTW; it's a graphics system for building interfaces. I'm sure there are many more optimized libraries and plugins available for our specific needs when it comes to drawing the units/terrain/animations and so on.

The only drawback I have experienced with Java yet, is working with raw files, because of the lack of unsigneds and basic Byte stuff (Pointers, WORDS, DWORDS, Big/Little Endian, etc.) in Java it is sometimes a bit of "a pain in the ass" to work with on that level.

Yep. Although the whole point of a high-level programming language like Java is to abstract away low-level operations like those involving bit manipulation, etc... into standard libraries of functions that programmers can simply call to do the work for them. I think you'll be surprised just how many such classes and packages there are in Java for dealing with all aspects of I/O, bit manipulation and arithmetic, parsing, etc... even in just the standard libraries alone (a good deal more than in C/C++ I'd wager), not to mention 3rd party libraries.

But of course when working with proprietary data formats like the SS2 data files - writing your own methods and so on will be pretty much unavoidable to a large extent. Java has very good support for I/O operations involving files; in particular check out the java.util.io and java.util.nio packages.
For working directly with bytes - you do actually have an unsigned primitive available; char - which is a 16-bit primitive capable of representing any value from 0-65,535; experienced Java developers indeed use it for operations involving bits/bytes - just be careful not to print it otherwise you'll end up with a Unicode character instead of the number that you were expecting
Also you have the ByteBuffer class in the java.util.nio package, and a few other classes; all of which come in handy for dealing with bytes although I usually just stick with the simple byte[] array personally unless I need to do something complicated involving 2 threads or whatever.
Again - there are very good 3rd party libraries, covering all facets of Java including this - in particular the apache-commons and Google guava libraries; which between them pretty much implement all that the standard Java libraries leave out in just about every area you can think of - data structures, String manipulation, etc... and I'm sure byte/bit stuff too.

Maybe we should start with a privat GitHub repo or something similar?
Because of two main reasons:
- Open Source vs. Closed Source Security stuff / especially when it comes to Multyplayer. I have no experience with that, but with the open source code cheaters may have a big advantage?

I'm not against it - only problem is that private GitHub accounts are paid only, and I think SourceForge ones are open-source-only although I might be wrong.
There is one alternative I know of - Atlassian's Bitbucket which allows an unlimited amount of private repos for free - but with a max of 5 developers per repo. Also, I'm not sure if they have version tracking software available for use as part of their code hosting; because although Atalassian's version-tracking system (JIRA) is among the best in the business - it's a paid product.

But anyway I'm sure there are many other alternatives anyway, if none of these options prove suitable.

- Maybe someone can contact Fireglow, and make sure they agree with our plans? To clarify to them, that SuSt is such a great game we really love and we won´t let it die.
This is concerning the prototype which could use the resources of the Game. Which could be reached with some approach like this: - No resources comes with our code, the user needs an original Sust installation at his side and needs to use the original Fireglows unsue tool. Our code would only use then these files.
I am not a lawyer^^: viewtopic.php?f=7&t=3386
+ EULAs §6

I can see that you're not a lawyer

But I digress.. neither am I.

Honestly, it's a company that has been dead for a long time now. And we're not doing anything illegal I don't think - provided that we don't redistribute any of the resources included with SS2 (graphics, sound, etc...). Which we probably won't get sued for even if we did, a). because there's no-one around at Fireglow and b). because the game was later released for free anyway.

But as for actually building a program to interpret those resources and mimick their own game - I don't think that's something that they or anyone else can stop us from doing; even if they were still around.

The alternate approach would be to create all the resources by scratch, too. But i have no experience with that... and it will take a lot of time.

Screw that

Last Soldier hat geschrieben:Nice to see news about Open Strike

Performance of today's computers is really great but youre sure with Java ? I'm no expert but for such complex game is Java useless. I'm not saying that it'sis bad language, only it has different use. I don't think it's realistic.

You're right

But only if you built a time-machine and went back to 2004.

As I've already explained, such fears are unfounded, modern Java coupled with modern computer systems will easily handle everything you throw at it provided you're not trying to build an FPS with modern shaders/lighting/NVIDIA features on it.

Actually that raises a question - about the extent to which Java and libraries available to it will be able to take advantage of modern OpenGL or DirectX, proprietary graphic card functions and so on. I rather suspect that solutions for all these things have already been developed and are available to use.

Anyway, it would be great if you publish any data which come in reversed engineering - file/data structures etc. Community can made some new tools.

We certainly will

Btw. Fireglow is dead. Do not expect any support from this side. Few people have asked for the source code - no reply.

They're deader than a dead donkey alright. But it never hurts to ask again. You never know..