Log in

Time to start making some technical decisions - On this day in 2017

Jun. 4th, 2005

09:20 pm - Time to start making some technical decisions

Previous Entry Share Next Entry

I hereby declare the initial software research stage of this project over. I’ve immersed myself in this undertaking for five months now, with occasional breaks for other commitments, and I’ve used that time to poke around under the hood of quite a few technologies looking for the best fit between ease of development and general performance. Some of it has been frustrating, some enlightening, but above all the process has reconnected me with the belief that I can develop a complex system on my own terms (which is a bit of a given, seeing as that’s what I’ve been doing for a living since 1996).

You see last year I had The Fear. I had lost the will to code, and I’d lost that deep abiding arrogance that any good software developer needs: the arrogance to believe that no matter how complex the task, it can be resolved into discrete chunks and expressed in code. I’ve had The Fear before, and I’ll probably have it again on future projects, but for this one I know that with a modicum of luck, a truckload of hard work, and a sensible degree of planning it will be possible to write a game engine to support the Silicon Beach setting. All I need to do is commit to the basic technologies involved, and then open the creative floodgates.

If this were a commercial project this would all be a no-brainer: we’d be adopting C++ for the engine side of things and then binding in Python/Lua/Ruby for use as the high-level scripting language. I have no basic problem with this combo of technologies, and over the last few months I even seem to be overcoming my decade-long deep-geek object to C++. The STL looks like a pretty decent way of handling generics, and there are a range of cross-platform graphics engines available.

So why have I not committed to using this combo then? I don’t know. You might as well ask why I’ve written most of my commercial systems in VB5 when Visual C++ would probably have made more immediate sense. I do actually have a good answer to that - it’s the only option I was allowed by various employers! The trouble is that when you’re used to the conveniences of higher-level languages, and have proven that those advantages don’t have to mean sacrificing raw performance if you fully understand the problem you’re solving, well the appeal of working at a lower level isn’t so strong.

But don’t worry, even though it is possible to get OpenGL kicking it old school with VB, that’s never been an option. I want cross-platform. I want to write this beast once and deploy it to Mac, to Windows, and to Linux, and the only way to get that with VB is to embrace .NET/Mono but if this project goes down that route I think it would be better to use C# and kiss VB goodbye.

Aside from C++ and .NET, the other mainstream option is to embrace Java. The new Java 1.5 standard has some interesting additions such as templates and autoboxing that should cut down on code volume, and since Apple have been contributing ideas to the Hotspot JIT there has been a considerable boost in runtime performance. It’s still not as fast as C++ for most purposes, but it’s close enough to be acceptable data-intensive tasks and there are also OpenGL bindings available which support OpenGL 2.0 with hardware acceleration on all the major desktop platforms.

For those who like Python there’s also Jython, a Java native implementation, and also JRuby. There’s also a Java implementation of Icon (JCon) that currently targets UNIX but might be of broader use. For these reasons, and the richness of the JFC standard libraries for network and GUI programming, I’m quite keen on the prospects for Java.

Completely off from the mainstream is my preferred development language of fifteen years standing, Icon - a lot of the work I’ve been doing over the last couple of months has been investigating how easily this can be turned into a credible games development tool. Unfortunately the current codebase would require a complete overhaul (and as much of it is written in a meta language this is not an easy task), the addition of proper threading support, and all whilst keeping either to GCC/ANSI C or C++. I’m of the opinion that whilst this would be an interesting project in its own right, it’s not the route to take this project in. I had to have a look though, just to satisfy my curiosity.

So Icon is a no go, VB/C# and .NET doesn’t really appeal, C++ would require carefully code control to maintain cross-platform compatibility (even with the aid of the STL), and so it looks like Java is the best choice for the game engine.

On the higher-level scripting side I’m not going to restrict options, because code at that level should be using the tool best suited to the task at hand. Mixed-language development has a reputation for poor maintainability, but having worked on a number of combined C/VB/Assembler projects I’ve learned that these problems are greatly reduced by having good semantic conventions and writing the most transparent code possible.

I know that some of you are keen on Python, and I’m happy to see fair chunks of the application-level aspects of the game written in this if that’s going to be productive. I’m likely to any coding I contribute at that level in Ruby or JCon just because I don’t have the time to devote to learning Python, but as long as we all use our heads over naming conventions and code commenting this will not cause problems.

Much of the data that the game engine will handle would be suitable for storing in an appropriate relational database back-end, and accessing via JDBC or a similar technology. Considering the widespread availability of MySQL this provides one possible option but there are also a number of pure Java database engines that might well be more suitable due to their platform independence. The alternative of numerous small data files that seems to be common in the games industry isn’t as appealing, although I suppose adopting XML would at least make end-user mods a possibility. I’m open to arguments both ways on this, but it is a decision that needs to be made before too much effort has been expended on writing file filters otherwise we’ll be locked in regardless.

As a general design strategy we’re going to identify major engine objects as we go, starting at a fairly high level and then seeking to build up a database of requirements that will expand throughout the project’s life-cycle. There are many academic techniques for requirements analysis, most of which work poorly in the real world, and in my experience it’s hard stick to a single approach when dealing with performance constraints. Keeping a requirements catalogue though is a must, as is figuring out effective mechanisms for requirements reuse, and I propose doing this via an area of the project website.

I’m thinking of a slight modification to the Mediawiki codebase that will allow requirement, code and general discussion to be tracked all on the same page - essentially adding a code page alongside the discussion page. Requirements can then be tracked across multiple categories and will allow reusable code to be identified quickly. Ideally the wiki should be able to tap straight into a CVS backend, so that we can keep code in CVS, but conversely it might be possible to use the wiki itself as such a repository.

Building the initial set of high-level requirements for the project as a whole is probably going to take several months, but I can see that this work will divide into at least three areas of competence:

gameplay design
game engine design
tools design

I already have a few ideas regarding the general direction that I want gameplay to develop in: the underlying conception of Silicon Beach is the gulf between the reality of how things are, and the perception of them by participants. A key objective is to have the player’s character (PC) in the game responded to by other characters based upon whom they believe the PC to be - the shifting sands of identity define a very different experience to the usual 1st/3rd person shooter.

The game engine should be capable of handling both 1st and 3rd person playing styles, and should make the use of vehicles a simple process. Few if any assumptions should be made in designing the engine about the appearance, characteristics or nature of the PC and I envision a style of play that supports internal/external/sub-aquatic environments with equal ease. If it were possible I would also like to see a text-only implementation of the engine that still supported the behaviour of a full 3D environment (I have an idea as to how this can be done), opening up a whole new realm of interactive fiction.

I suspect that tools design is going to be focused primarily on collaborative mechanisms for helping game content developers do their task effectively. Whilst I have a very clear idea as to how the Silicon Beach setting works on a philosophical level, there are huge quantities of detail that need to be developed regarding its history and culture. You cannot develop a game that effectively explores issues of identity without having a diversity of cultural elements available to the player. There are more than enough conventional shoot’em-ups out there that I’m not bothered about us turning off those players by choosing to aim at a more artistic level.

One thing I would prefer to steer this project away from is an obsessive use of design patterns and UML. It’s possible that we may find some use for both techniques at various stages of the development process, but I don’t think that overall the additional effort is going to be reflected in better-quality code.

As most of you have probably noticed when the subject comes up, I’m not a big fan of the GPL/LGPL licenses. I’d really like to get some active feedback from other people as to how they feel about each of the various competing open source licensing agreements, or for that matter the placing of code in the public domain. As you’ll note from the wiki, our current content licensing is basically on a co-operative model whereby contributing content gives a reciprocal right to use content. Is having our codebase open source a desirable move? And if so what restrictions should we be placing on people who have access to the source code but who aren’t contributors to this project? Similar concerns apply to any tools developed to support the project.

Until such time as we have a consensus on this I’m inclined to say that all code should be developed under a similar co-operative framework so that we don’t open source it at all until we’re sure that that’s what everybody wants. Obviously if we make use of third-party code licensed under the GPL or other open source licenses this may well result in us having to go down that route anyway to comply with the terms of their licenses.

I know that many projects just go for GPL anyway, but I think we should think over the ramifications carefully before proceeding...

Current Mood: focused
Current Music: Time Honoured Tradition:Kaiser Chiefs