Allegiance 2

[Spunkmeyer]

QUOTE (cashto @ Feb 9 2013, 01:21 AM) I don't see what makes games special in this regards. That is to say -- "the old code is a mess, but we know what the problems are, so our second system will be better architected" -- is exactly the sort of hubris Joel describes in that article. The truth is, in any mature system, a rewrite is essentially throwing away years hard-earned knowledge, years of bugs that had to be dug up and fixed. When you see messy code, when you see complexity, you can't just assume it's accidental, unnecessary, avoidable complexity. The code just might be complex because the problem domain is more complex than you thought.

No, Joel is talking about a system that's had a far longer development cycle, in use, sustaining a business and still under continuous development. Throwing away that would be a difficult choice, but we have much less to lose with Allegiance. Note I'm talking about Allegiance here, not games in general. And architecture has little to do with it overall.

As for games in general, think why Doom series (I'm using them as an example since the source is available) don't share code. Technology changes.

QUOTE And in the specific case of Allegiance, I guarantee you none of us are privy to the thousand little lessons the original developers had to learn in the process of building the system.[/quote]
...which is another reason in favor of a rewrite, because we don't have their lessons, insight, documentation and development setup.

QUOTE I'm curious what specific improvements either one of you would make to the architecture of Allegiance, the "fundamental aspects" that you would improve if you had the time and motivation to do so.[/quote]

Like I said architecture has little do with it - although it's fairly tightly coupled in places and proper testing is pretty much impossible, and these are not simple refactoring issues. In the end it's the effort required to extend the existing code base vs effort required to rewrite from scratch, and the quality of the resulting product, and it's fairly obvious to me that if you want to go beyond anything that's currently assigned a milestone on Trac, you have to rewrite:

1) You will hit walls with the existing code base if you want a marketable, modern product.
2) Even when it can be done, for the implementation of a given functionality, you will spend far more time trying to shoehorn into the old one. This is true for almost anything the original game wasn't designed to handle.

[Orion]

QUOTE (Adept @ Feb 9 2013, 05:55 AM) I'll just throw this out there. Only mega studios like Valve create new game engines these days. Nearly everybody else buys one off the shelf and maybe adapts it a little to their needs. The Alleg devs couldn't do that in the late nineties, but for a remake of Allegiance that would be the sane way to go.

Yes, this is entirely true.

QUOTE (Spunkmeyer)As for games in general, think why Doom series (I'm using them as an example since the source is available) don't share code. Technology changes.[/quote]

Cashto, you have no idea how many system's I've had to dig into that are so overly complex and poorly architected written in some old VBScript or early VB .NET web forms. Anyone in the industry will tell you (or ought to); if you have an old code base which has had dozens of different hands on it for 10+ years, the code will look like a $#@!ing mess. After a certain amount of time, it becomes more costly to maintain old code than it does to cut your losses and rewrite the application from the ground up.

I'm not speaking from theory here, I've done ground-up rewrites on multiple enterprise level applications for many clients in many industries. They always have benefited from new practices and technology.

[KGJV]

QUOTE (cashto @ Feb 9 2013, 08:21 AM) I'm curious what specific improvements either one of you would make to the architecture of Allegiance, the "fundamental aspects" that you would improve if you had the time and motivation to do so.

The #1 aspect to change is to have a real scripting system in the game and have all the 'game logic' parts of game written with this scripting system and as a pluggable module (or core if you prefer).
From here, people can choose which module(core) to play and people with no deep "C++/game engine" programming can change or create modules (cores) with simple and easy to use tools

The idea is to extend the 'core' concept of current Alleg to more than just a bunch of values by adding all the game logic code to it.

then add a completely automated module (core) management system so that anyone can add a module to the common 'pool' of modules so that every other players can use it without requiring any admins or 'god' to decide if that module is worth sharing. As well as adding/changing maps, game settings, scenarios (games with scripted events)

why that ?

it's basically to enhance what worked with Alleg : cores and new models/factions (and maps to a much lesser degree).

and fix what did not work:
- programming knowledge requirement too high to make a gameplay change that require code change.
- long and complex build chain to release a code change
- manual and centralized system to add cores (and maps) to server(s).
- difficultly for the "event team" to do stuff without the intervention of admins and programmers.

well you get the idea: make a game that anyone can change and enhance without depending on anyone else to do so.

[Orion]

QUOTE (KGJV @ Feb 9 2013, 05:34 PM) and fix what did not work:
- programming knowledge requirement too high to make a gameplay change that require code change.
- long and complex build chain to release a code change
- manual and centralized system to add cores (and maps) to server(s).
- difficultly for the "event team" to do stuff without the intervention of admins and programmers.

That's a pretty good idea.. what scripting language are you thinking? Is this a "thin" layer on top of an engine, or relying on an existing engine's scripting model (ala UDK or unity)?

[Monkage]

I recommend going the middleware route e.g. Unity3d, with a much reduced target for Kickstarter if it's even necessary. It won't be a top tier game, but it'll be a hell of a lot better than what we've got now, and it'll take a fraction of the man-hours to get things going.

AFAIK, the MS licensing allows the old assets to be reused. So we could get things up and running quickly with them, then petition for new assets in our community and on the blenderartists.org and Unity3d forums. There may be a lot of ppl willing to do it for credit (i.e free) if the game logic is already setup and there is a playable demo.

I'd also recommend making it exactly the same as Alleg1 at first, too, so the gameplay doesn't get ruined in the planning stages. It is very easy for small projects to stall in the planning stage when ppl can't agree on what the game even is. So, yeah, just make what we've already got, first, and go from there.

Realistically, how long do you think it would take to remake the game in Unity3d using the existing artwork and core databases? With volunteer work only it could be as short as 6 months to a year would my best guess.

[dusanc]

Wouldn’t FS2 based allegiance2 be better than going from scratch? You’d already have eyecandy, npcs, scriptable modular game.
All you need to do is revamp FS2 multiplayer and net code.
And they already have active modding community.

[KGJV]

QUOTE (Orion @ Feb 10 2013, 12:38 AM) That's a pretty good idea.. what scripting language are you thinking? Is this a "thin" layer on top of an engine, or relying on an existing engine's scripting model (ala UDK or unity)?

I'd prefer a thin layer on top of an engine.

actually, I really believe HTML5+WebGL is the way to go for something like that but I'm still waiting for some good engine built on top WebGL/HTML5.

we almost have everything we need to build high quality games for web browsers (real games not casual puzzle stuff).
Google with Chrome is pushing very strongly in this direction. We have already Gfx (2d canvas and css, web-gl), sounds, networking (websocket), input devices (controlers, joysticks, etc).
Everything can be done directly in the browser and it'll run whatever the OS under it.

we're still missing some high quality platform/engine to write games so that we don't have to start directly from scratch above web-gl.

So it's a bit early to tell more yet but that's what keep me busy these days.

ofc, this shouldn't hold anyone from rebuilding Allegiance using more conventional methods

as for the language I really believe in Dart.
Once its specs are stable, I might even try to embed the Dart VM inside current Allegiance code... that would be a way to start moving the game logic code to script for a future move to a new platform while giving the game immediate oxygen. stay tuned.

[Raveen]

Kage, if that's possible (or at least plausible ) it seems to me to be a really good model for going forwards. Platform agnosticism can't be a bad thing and removing obstacles to play like fiddly installation is a smart idea and probably the way of the future.

[Orion]

QUOTE (KGJV @ Feb 11 2013, 05:44 PM) I'd prefer a thin layer on top of an engine.

actually, I really believe HTML5+WebGL is the way to go for something like that but I'm still waiting for some good engine built on top WebGL/HTML5.

we almost have everything we need to build high quality games for web browsers (real games not casual puzzle stuff).
Google with Chrome is pushing very strongly in this direction. We have already Gfx (2d canvas and css, web-gl), sounds, networking (websocket), input devices (controlers, joysticks, etc).
Everything can be done directly in the browser and it'll run whatever the OS under it.

we're still missing some high quality platform/engine to write games so that we don't have to start directly from scratch above web-gl.

So it's a bit early to tell more yet but that's what keep me busy these days.

ofc, this shouldn't hold anyone from rebuilding Allegiance using more conventional methods

as for the language I really believe in Dart.
Once its specs are stable, I might even try to embed the Dart VM inside current Allegiance code... that would be a way to start moving the game logic code to script for a future move to a new platform while giving the game immediate oxygen. stay tuned.

Ha, I've considered this as well.. unfortunately the game would only really work in Safari/Chrome (and Opera, once it switches to WebKit, lol). Firefox and IE would have issues. Firefox can render WebGL okay, but cant do spatial audio, and IE doesn't support WebGL at all.

I've written a PoC of a game in WebGL on top of three.js (graphics) and ammo.js (physics), it works well on Chrome, okay in firefox (minus spatial audio), but it runs into performance issues with javascript. In a game like allegiance, the logic would be a LOT more complex, and I have yet to see a physics library that efficiently splits its logic out into web workers (I've tried one of them, about the only one I could find, it was pretty bad..) Another issue here is loading assets, right now allegiance uses a *lot* of assets (textures, meshes, sounds, etc).

It might be better to target NaCL and use C#/Mono.

[Orion]

http://peerjs.com/

Interesting new library for P2P communication via the web browser (using the new WebRTC standard), could be handy if someone continued down this line of thinking (making an Allegiance clone in the browser)