Unreal Engine 4 & Battlezone

[bigbadbogie]

Anyway - back on topic.

If Battlezone 2 were able to be recreated in a modern engine (without TOO much difficulty), I may consider assisting in the future - if only to get a tonne of new players interested in the genre.

It could be along the same lines as Battlezone Classic, only massively upgrading the graphics and physics rather than recreating them exactly.

Battlezone 2 Classic?

[MrTwosheds]

The biggest problem with a modern bz style game, I feel, would be that its "commander" style just would not work with the 32+ player games that it would inevitably enable. Even 10 player games place a huge burden on the commander to supply players with the gear they need to maintain the fight. A slightly different resource allocation, unit creation and weapon upgrade strategy would need to be designed to spread the burden more evenly between players and ensure that all can participate fully in the game.

Hmm got 2 pools... all my thugs lost their ships... need 16 blast tanks quick!...Game Over.

[bigbadbogie]

If thugs could have their own scrap supplies and use the recycler/armoury to build empties and weapons for themselves, that problem would be solved.

Combat units could be tooled to pick up scrap.

[MrTwosheds]

That sounds like the beginning of a good idea...it would need a lot of ironing out, maybe thugs could buy gear straight from the base, so rather than just spending all the commanders scrap for him and driving him insane with specific requests, they would actually contribute to the accumulation of overall scrap...but not via friendly fire! The recycler would need some sort of accounting function...Scav drivers might go on strike though
LOl broke pilots picking up 4x1 scrap and carrying it back to the recy before they can get an empty...or a new sniper rifle.
Hmm..The BattleZone Corporation
Command buyouts!
BattleZone 3 Combat Manager

[Nielk1]

The issues with BZ in a modern engine are the same as on it's current engine. The core design of an FPS and RTS is different right down the the logical tick used to govern its internal logic.

This has long been an issue and my best solution is to offload the data to a dedicated server (in the, anyone can run one sense, not the Sim City sense).

FPS logic runs in a way intrinsically different from RTS logic. When you solve the problem of the fluidity of dynamic tick direct input FPS with fixed tick deterministic RTS, lemme know.

The best way I can think is to run both simulations simultaneously with points of intersection, where the acts of the non-deterministic variable logic rate system caused force impulses on the deterministic system that are evaluated on the next logical step. This means that there would be two entirely independent logical systems running in parallel, which enters the hell of resource allocation and sharing as well of a multitude of cases for race-conditions.

BZ2 uses the RTS system with bits of compensation welded on for the issues introduced by FPS. Note that BZ2 does not implement a proper variable logic rate FPS system resulting in sluggishness at times. The interaction of the non-deterministically and non-queued input of the player into the RTS system results in loss of sync. In RTS games, loss of sync means game over. In BZ2, it means resync. This is one of the things BZ2 had to do to try to compensate for this intrinsic incompatibility.

Any existing engine would likely require a rewrite of its core logical and networking systems.
New engines are a bitch to make now-a-days.

I can only suggest taking a multitude of independent engines for graphics and physics, etc, and coding the two needed side by side FPS and RTS engines, and then designing the "integration engine" which handles cross 'world' information input.

Doing it right is basically quantum mechanics.

EDIT:
It might be so far as a case of having the Physics, FPS, and RTS engines all model the same objects, or having the Object pass between an FPS active and RTS active state. Yes, FPS games can have RTS elements, but they are normally limited in count severely. Look at any FPS game that claims to have RTS elements or options and it normally breaks down to a limited scope of battles due to everything being simulated in a FPS geared logic engine. It might be possible to cause items to elevate from the RTS engine into the FPS engine and back as needed.

EDIT: The above assumes no dedicated server. If you have a dedicated server, you can only send to a client their limited needed info. Server might still need to be a bit beefy for dedicated.

[TheJamsh]

Hey guys... Guess what I just got my hands on

Under NDA right now so all I can say is... holy sh*t, this stuff is good. Who wants to make a BZ game without touching a single line of code? Yup. Doable.

[Nielk1]

Who wants to make a BZ game without touching a single line of code? Yup. Doable.

That sounds awful.

Additionally, imposable, given that the game is outside the basic formula of pre-built engines. I am sure you are running into tons of issues with Bionite and UDK are you not?

[TheJamsh]

It's all down to the new Blueprint system, which I can only really describe as a Node-Based C++ Scripter, you can create object classes that behave identical in any given environment or map and save them as fully functional assets.

Can't really say too much on it, but I'll try to get a working hover tank into UE4 at some stage and upload a video, here's just the old Hi-Res Sabre from Serenesis rendered in UE4. I'm just not allowed to talk about the tool-sets or show them yet...

http://www.youtube.com/watch?v=xrawXSbSp5w

[Nielk1]

I'm still dubious. Any programming accelerator wrests away control from the developer. While it might make life easier ti also hurts anything non-standard. BZ is pretty non-standard given that its entire architecture will NOT WORK if it tries to be straight FPS or straight RTS (networking, AI orders, physics).

Basically, I am concerned at the fundamental level. It's like trying to make Minecraft in an FPS engine only to find you can't reliably dynamically generate 3D terrain bitmaps.

What you said so far just sounds like a pretty wrapper around existing well known and documented OOP ideology.

UE3, don't know about 4, actually has a fundamental flaw in how its data is baked in. Where BZ1 and BZ2 use paramaterized instances of HoverCraft, UE3 forced you to have something like SabreTank, WarriorTank, etc as opposed to instances of HoverCraft loaded with the needed data. I can only surmise that this Bluepring thing is a way to solve that *one* problem, but it might not even do that.

[TheJamsh]

You're probably right about a lot of these things, but I think it's certainly worth looking at if anybody was ever serious about making even a small BZ-style spin off. Man it sucks I can't link to the Documentation and stuff but I hope when the technology comes out, a few of you have a good in-depth look at it.

BTW I realise this is a good marketing video for Epic, but here's a few of the possibilities of Blueprint so far (again, no C++ or base code used here). This video is pretty old (they're still calling the system Kismet here), and has evolved a lot since. Just like Kismet though, you can write your own nodes in C++ and add those in, if you feel like the blueprint nodes are restricting you somehow. For simple games though, it's very potent.

http://www.youtube.com/watch?v=IReehyN6iCc

[Nielk1]

It sounds like they are talking the Unity paradigm, which... ug... There is a reason why Unity is STILL thought to be a child's toy and people are shocked when stuff like Guns of Icarus Online and Kerbal Space Program come out of it.

Will probably make it easier for the unwashed masses though.

[General BlackDragon]

sounds neat

[TheJamsh]

Well, I'm starting to work on the touchy 'physics' aspect, but my understanding of how it's done is pretty poor... so if I explain what I'm doing maybe some of you physics/programming wizards can help.

The craft has simple controls for turning and moving forward/backward but currently no altitude, so it can't really move anywhere. The method I'm using at the moment to set the altitude is pretty rough, and there's probably a much nicer way to do this:

Every Tick, the code gets the object location, and does a line trace between it and anything ### units below it. I then add ### units to the impact point of the trace and set the location of the craft to that vector. Although this works, it's incredibly uh... glitchy looking. And doesn't appear smooth like BZ. Anybody know how BZ applies altitude to it's crafts?

[TheJamsh]

I suppose what I really want to do is use a collision sphere or capsule around the object, and repel other collideable objects when the intersect it, but smoothly. heres the above code in action for mega lolz:

http://www.youtube.com/watch?v=7Bflopxmwd0

[General BlackDragon]

needs shocks