Par4site
Members-
Posts
3 -
Joined
-
Last visited
Profile Information
-
Modding Interests
Jack of all Trades
-
Gaming Specialty
Dueling
Competitive Play
TFFA -
Operating System
Windows 10
Par4site's Achievements
-
Smoo liked a post in a topic: Open source Jedi Knight in a modern engine
-
Teancum liked a post in a topic: Open source Jedi Knight in a modern engine
-
ShakeThatSalt liked a post in a topic: Open source Jedi Knight in a modern engine
-
Open source Jedi Knight in a modern engine
Par4site replied to afi's topic in Art, Media & Technology
Absolutely, the end goal is to eventually merge them all into one, so that the players from all of the JK series games will have to abide by the same gameplay. But for now, separating them accordingly will only be a good thing, it means the community will be able to retain its current standing with players who are comfortable with the old base mechanics, while the new systems and being developed and tested for accuracy and balance. Think of it like two inverse slopes. At some point in time, those slopes will intersect. This will be the point where the new mechanics, animations, and functionality will be completely implemented, and the servers can come online without much change for the next however many years they will stay up. The old base players will start to migrate, and eventually, The Base version will receive no support, and eventually be cut entirely when we feel it is time for everyone to make the move. But there does need to be 2 or more versions initially I believe. -
Open source Jedi Knight in a modern engine
Par4site replied to afi's topic in Art, Media & Technology
I disagree to both of the above. Having two versions of the game will alleviate a lot of issues both communities will have. For starters, having a version that is very close to BaseJKA will allow all of the older players who prefer the old mechanics (such as the timings and accuracies with saber combat and animations) to still play and enjoy the game on newer graphics with more fluid network functionality and registration. Deviating just a little bit from this will cause the game to not feel like people remember, and it will cause people with a high skill level in the game to have to relearn all the mechanics they learned over 13 years. Since we already have the source code, making this version should be the logical first step. The second version of the game is where we can really dive deep and give players the option to learn and experience a new combat system. Keeping all of the same functionality (more or less) with the movement code and saber mechanics, we can expand on how different styles can be used to counter each other, and keep everything fair and balanced. Keep in mind just something as easy as changing the animations around will affect the gameplay in a very dramatic way. Each saber swing has active frames, passive frames, math is used on parts of the frames to calculate blocking, all of these things play into how saber combat ties into player's current fighting styles and muscle memory. One of the reasons JKA and JKO were so diverse in combat was because of the movement code. Fine tuned movement can make or break a fight, whether it is to aerial strafe an opponent who jumped away or to speed back to main after a death. These things are very critical to JKA, and without them, it would no longer be a Jedi Knight game. -
afi liked a post in a topic: Open source Jedi Knight in a modern engine
-
Smoo liked a post in a topic: Open source Jedi Knight in a modern engine
-
ShakeThatSalt liked a post in a topic: Open source Jedi Knight in a modern engine
-
Open source Jedi Knight in a modern engine
Par4site replied to afi's topic in Art, Media & Technology
As a very junior level developer in C#, C++, and Java, and as an enthusiast of the JK series, I'll add my input here. As a dabbler in many different projects to improve my skill, I have started on JKA conversion projects here and there, a bit in Unity and a bit in UE4, and as such, I believe I can shed a bit of light on some of the problems and visions that I've had over the past couple of months. Since the JKA source code (in its original state, not part of the 3000+ commits from the JKHub guys) is a sloppy mess to navigate around, and with all of the engine mechanics, it is a daunting task for a programmer. First, lets speak about the engine. The comparison of the two engines is a bit laughable. Modern constraints at the time did not allow for many programming habits we have today, such as separating different objects in different class files, as they needed as much efficiency as possible to deal with CPU and GPU limitations. The Quake engine was a work of marvel, being one of the first real good engines that handled 3D graphics. In order to achieve this, they had to make sure the engine was almost flawless in how it handled RAM usage, like defining EVERYTHING in the lowest common denominator, so that it could take full use of the low available RAM and CPU speeds in the 90's. Today, that is not so much the case anymore. While efficiency is still a very important factor in programming today, most people from what I have seen want to make sure the code is not only reusable, but also that it is easy to read, understand, and replicate. Looking at the different components in UE4 makes this very apparent, as it feels like UE4 has every bit of it "wrapped" to make it layered, like a cake. That introduces the first of my roadblocks into doing a project of this magnitude: converting over functions and classes that are self contained and modular. While some of these functions and methods are easy to read and understand, a LOT of them have their hands stuck in many different classes, and are all used and defined in different ways. This makes my already modernized mind have a panic attack when I see a variable that has the same name and usage spread out over 40 C,C++ files that all define the same thing. Not that I am a great, or even a good programmer by any means, but this is a big roadblock for me. Next, let me talk about the different systems in JKA. Usually, in modern terms, things like movement, collision, and character controllers are defined as things called "Components". We hearken back to the previous paragraph: modular, reusable. Ideally, you can take a component from different source code, and as long as you have it wrapped correctly, and use it in another project. JKA's source code has no real sense of these types of components. It feels to me as if a developer said "Okay, we need collision now. Lets just make a new method and call it every tick to see when we need it. Its going to live here in the move code. Done." This makes it hard to find, even when you have search capabilities, because it is defined in so many ways. I have started on trying to find the functions I need, like collision, and separate them in a way that I can simply pass parameters to it, have it do its thing, and its over. But to separate a big chunk from JKA's source is frustrating, like trying to find several needles in a haystack, and make sure you have all of them. And then theres the inherent engine functions, like vector tracing, and how the system will define a slope or a plane. I feel in some mystical way the Quake engine has somehow wrapped this in a way that is usable, but still a far cry from what I can actually use. Somewhere buried in the structs of the engine itself is how a trace can be defined and used, but still I have not found it. These values are being stored and sent to the PMove class, and represented in a meaningful way, but to send that straight to UE4 is a lot of work, seeing how the two engines are vastly different in how vectors are defined and used. To wrap this up in a long upcoming TL;DR, I still have a drive to continue poking in JKA's insides to see what I can pull out and rework to use in UE4. I want this more than anybody, believe me, but game engine stuff with 3D is still beyond me at this point. I also understand that a team of people is pretty much required to work on such a project, but until recently, there has been a big push to improve JKA, which I don't entirely agree with. I believe the best shot for the game and the community is to bring it to a new engine and rework it in a way that can make upgrading it in 10 years a much easier task. I also believe that 2 versions should be made with a project like this: A base version, where all of the original functions, variable values, and animations should be used, and a new version that has updated everything. Both of these versions are separate from each other, more akin to JKA and MBII, but both can be accessed from the same launcher. The newer version I imagine will be like a well tuned car; closely monitored and tweaked for the most accurate experience. I also envision the newer version to be made in a way that would appeal to the competitive player on the highest levels, but still an enjoyable and fun experience for the new player who wants to sit in a server and duel. Hopefully these are visions that are reachable with enough collaboration and support, as I would love nothing more than to see thousands upon thousands of people playing it to become good duelers who only strive for perfection in combat; to reach the top of a competitive ladder and form a tournament scene. That's enough of a rant from me I believe. I hope this potentially helps out one or more of the people out there looking to get into this seriously like I was.