Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
Jane's F-15 is a study combat flight simulation game modeling United States all-weather strike fighter F-15E Strike Eagle. The game had two campaigns: one based on the 1991 Gulf War against Iraq, and the other focusing on fictional conflict with Iran. Jane's F/A-18 used an improved version of F-15's game engine.
The game supported 3Dfx graphics, and later a patch was released to support D3D graphics. The virtual cockpit was one of the first of its kind, but the game still featured a 2D cockpit which also allowed the player to switch between the pilot and WSO (Weapons Systems Officer) seat in the back of the cockpit to monitor the different multi-functional displays.
Words from the creators
When considering why SE III had FS/BS and co-op multiplayer and games like “Fleet Defender” (built off the SE III engine) and Jane’s F-15 didn’t you must first look at what was going on in the games and what information needed to be passed.
The first difference is that SE III was only dealing with a very limited number of planes at any one time. There were no other friendly aircraft except one or two F-15s doing touch and goes at your home base. Enemy aircraft did not exist in the game until you were spotted by radar. At that point they would generate up to 4 aircraft to engage you and if I remember correctly that was the maximum number that could be active at any one time. The air defenses were fairly limited and I believe focused around just your target area (not 100% on this). I don’t think anything else in the game, excluding weapons, moved. Ships just had wakes painted behind them, which made people think they were moving.
On the other hand, Fleet Defender could have up to 80 aircraft active at one time and JF-15 more than that (I think 120). Planes could be flying for each side (plus neutrals) doing various missions (more on that later) and existing during the entire game until they died. There were other vehicles that could move around, and some were armed. JF-15 also had a complex air defense network with thousands of elements (FD’s was more complex to SEIII’s but close enough that I’ll consider it a wash). As you can see, there was a lot more going on in these games than SEIII. This means that a lot more synchronization would have to take place in a multiplayer environment.
The next factor was the level of AI that was taking place. SEIII’s was actually fairly simple and I don’t think had changed from F-19 (which was before SEII). It was purely A2A (except the code for the touch and goes) and very straightforward and predictable. Aircraft were unaware of each other and wouldn’t work together. I remember a look up matrix which would determine how a plane would react depending on where the Player was in relation to the AI. I don’t think they would try to avoid missiles and they wouldn’t drop countermeasures. Missiles were known for being one-shot kills. Then again, considering how many cycles they had to work with, especially during F-19, it did what it needed to and people had a good time with it which is really impressive.
For the other games you could have aircraft doing a variety of missions. You had A2A, A2G and support missions (SAR, AWACS, …) going on. A2A aircraft would use group tactics pre-merge and break into wing pairs post merge, using different tactics depending on formation (pre-merge), side and skill level. Combat would take place out of plane (i.e. the vertical would be used) and would take into account orientation, energy state and sometimes a bit of randomness. Countermeasures and beaming of missiles would take place and when a plane was damaged it wouldn’t automatically kill it though it could have its performance degraded as systems. A2A could fly cover for a strike mission and fly ahead to cover the target area as the attack aircraft neared the target area. If a CAP was pulled to intercept incoming bandits then alert 5 aircraft, or possibly another CAP would take over the original CAP’s station. When returning to base an ATC logic would organize the landing pattern. This means, in general, that you’re going to have to have a lot more extensive and diverse multiplayer code to keep these activities in sync.
The reason I said, “in general”, in the last sentence brings me to our next difference. One of the main ways that SEIII kept things in sync on both machines was by frame locking the games and seeding the random number generators with the same value. In this way the main information that needed to be passed was the location, orientation and state of each Player controlled plane (unless you were in the back seat) and stuff like firing weapons, locking up targets, changing radar modes, etc. Assuming everything went well, then both machines should react to things in the same way, decisions by AIs would be made at the same time and with the same results and things would stay in sync. There are a few problems with this method. The first is that everyone is locked into the same framerate. Whoever has the slowest machine will dictate how fast the game will run. Onto this you also have to add the latency it takes for all the messages passed to get from one machine to another. Then again, back then you were happy if your game had a framerate in the low teens so people didn’t usually notice that much of a difference. Another problem is that if the machines start getting a little out of sync the problem can, and did, cascade fairly quickly. Once again though, given how slow modems were and the constraints they were under this was an impressive solution. It also meant that there didn’t have to be a bunch of extra code to handle a bunch of different situations in multiplayer. Unfortunately, given the drastic increase in the number of units, the complexity of the logic taking place and the desire for higher frame rates this isn’t really a viable option anymore.
So, with this in mind, why did SEIII have such multiplayer capabilities when later games didn’t? It’s because it was a much simpler game at a time when expectations weren’t as high. It didn’t have a lot of stuff going on to simulate and it could use a bunch of tricks that probably wouldn’t work today.
If I remember correctly we had to drop multiplayer from FD for 4 reasons (there might have been more). 1) We increased the complexity of the game to the point where the old methods wouldn’t work and the time it would take to implement new methods would have pushed the schedule out too much to make it worth it. 2) Even if we put the code in the bandwidth at the time probably wouldn’t have been nearly enough. 3) Even if we had enough bandwidth we didn’t have enough memory. At the time there was a hard 640KB limit for the core executable and SEIII was pushing the limits of that. We were very worried with all the enhancements we put in for FD that people weren’t going to be able to run the game even without the multiplayer code, let alone keeping it in and the upgrades that would have been needed. 4) Also multiplayer wasn’t really common at the time. The extra money that MPS would have gotten for keeping it in probably wouldn’t have covered the development costs.
As for JF-15 most of the reasons (excluding memory) were the same as for FD. It would take a lot of complex code to get it to work, bandwidth still could have been an issue and, while multiplayer was gaining in popularity it still wasn’t a major selling point. Also remember that this was our first project with a new company and we were starting from scratch and had to prove ourselves again. We had no idea what our limits were going to be or what problems we might hit. We weren’t sure if we’d be able to pull off full multiplayer and even if we could if it would be up to the level of quality that we were trying to achieve. It was felt that it just wasn’t worth the gamble. I don’t think we had even planned on doing H2H multiplayer at the beginning.
Since we had our core engine in place for JF/A-18 it was felt that it was worth the risk. Also during the time multiplayer was becoming more popular. Still, I had to spend the first few months of the project proving that it could work and about half my time on the project implementing it. Initially there had been talk about doing another game with the F-15 and along with co-op multiplayer having FS/BS but for various reasons it was eventually felt that the next game on the engine should be another plane. If we had needed to do FS/BS though it would have made multiplayer more difficult. For one thing, micro-warping would have been much more of an issues. If you’re next to someone and they’re doing it, there’s not much of a problem. If you’re in the plane then it can get rather frustrating and completely pull you out of the experience. Also a bunch of systems would have had to been linked. This would include stuff like slewing tracking IR and cursors around, determining who has control of what, making sure both seats are seeing the same information in all systems and views. Doable but not trivial and I’m sure we would have hit some real bumps along the way and added a few months to the schedule.
I hope this helps you understand why we made the choices we did and that just because something was possible in one game, there can be factors that make it either a lot more difficult, if not impossible to do in another.
CJ Martin: As a designer, there was a lot of things I wanted to include - some I tried to pull off until I discovered how badly they screwed up the game.
Things like major power lines - I wanted these because they were major navigation aids for the F-15E crews (they make great radar targets). I put in several hundred towers and even though I greatly increased the spacing between towers, it was too much of a framerate hit. It looked great though. \:\) Our lead programer nearly had a heart attack when he saw all those towers.
Along the same lines I also wanted metal fences - never got that object though and after the power line mess it was just as well.
Then there was KARI - Elf I am sure remembers this well. I worked long and hard building the Iraqi air defense network right down to the last gun. I had (no kidding) tens of thousands of guns placed in the world - something like 80% of what Jane's said Iraq had. For SAM's I got closer to 95%, and in many cases I had the actual lat/longs of missile sites so I used them. I labored away on this for weeks and weeks.
Then our lead programer, who had been using a fairly "clean" world to test loaded up my latest template.
It was a disaster. Seriously. The framerate hit was unbelievable. Multi-seconds per frame, yes that bad. Moreover, there was no easy way to undo what I had done because of schedule - we didn't have the time to redo all the campaign missions that had been built to that point.
Thus came the culling - and the source of a least one of the bugs in the game. If you place down a plugin with a lot of guns using the mission builder, all those guns won't be there in the actual game. Only some of them will be there. The plugins have so many freakin guns that it's pretty hard to notice we did that, but some people did.
F-15 2.0 - now there was a lot of stuff I wanted to do for that game. We actually got a couple months down the road into that game before we switched to F/A-18. Blame Longbow 2 sales for that.