Cube Engine Games

Cube & Cube 2 FORUM

WANTED: programmer(s) for Eisenstern

by Aardappel_ on 03/21/2008 19:43, 59 messages, last message: 08/08/2008 22:05, 19574 views, last view: 05/04/2024 21:42

The Eisenstern project needs someone who can help drive the project forward more frequently than I can. So far, eisenstern has moved forward in bursts, whenever I had a bit of time in between all the other things me & Lee are doing. The project deserves better.

What we're looking for:

There's two kinds of people that potentially can take up this position.

Candidate type #1: an experienced C++ programmer. This would be ideal, but we realize these people are few and far between, so hence why we also have type #2, below. I say experienced, because taking over the C++ side of Eisenstern requires you to work as part of the main codebase, for which we can't afford bugs that will disrupt the rest of the engine, or sloppy code in general. The programmer must be of a level that they can deeply understand and safely modify the Eisenstern C++, and potentially some engine code. (s)he must understand the software engineering style of the cube 2 codebase, which is about simplicity, minimalism, and non-redundant code.

The code is readily available, so you probably already know wether the above applies to you :)

What would you do? You would take charge of the entire Eisenstern development effort, only discussing global design direction with me, but taking responsability for the details yourself. You would have a lot of influence on game design, by definition. You'd work with content people and make sure their stuff gets added to the game, or you'd work with a type #2 programmer who does this.

For both positions holds that you are very self-motivated, self-learning, and self-directed... rather than needing every detail specified by me, you have a good sense of design (of code structure, ui, and gameplay) to work out optimal solutions yourself. Once you get going you'll become intimately familiar with eisenstern, so good solutions follow from understanding what is already there.

If we can't find a type #1 programmer, I will keep responsibility for the C++ side of things, and hopefully work with:

Candidate type #2: Script programmer

For this position, you still have to be a programmer (meaning you don't have to know C++ at all, but done some programming in Java, Perl, Python, ...whatever). If Cubescript is your first language, you may not qualify.

Your domain would be to maintain the RPG script files, and since unlike the FPS, almost everything is going to be in script, this is a lot. The script is the center of the game, meaning you'd:
- work with me and the C++ programmer (if different) on global gameplay direction
- work with the C++ programmer on what new script functions are needed
- work with level designers on scripting RPG objects that they can place
- work with content people on connecting their art with RPG objects
- generally work on enhancing the gameplay in script, adding new actions and quests.

Since you'd be the central hub for the game, you need to be extremely self directed in connecting all these elements, and working with people. You can't be waiting for me to tell you exactly what to do next, you have to actively seek out people and work with them to get stuff done. You try and get as much stuff done yourself, use placeholders if you must, and modify them later, as opposed to waiting for complete data before you code (much of the current stuff is placeholders too).

The script will get BIG, so even here some software engineering skills will help. If you look at the current code, you can see that I took great care to make sure I write lots of small functions to not duplicate definitions, you'd have to work hard to continue that tradition.

Besides programmers, depending on who we get working on this, it means that art & design people can become more actively involved as well. This is just the first step.

Unlike the FPS, which I have always ruled dictator style, the RPG is meant to be a community effort. The unwritten rule for the Cube 2 community is: the more work you do, the more of a say you get in the projects overal direction, and Eisenstern will work especially so.

You all know I have set a gameplay direction for Eisenstern, but none of this is set in stone. If team members come up with better ideas, then we'll go with them, within reason. I have simply tried sofar to:
- keep things simple. an RPG is a tremendous undertaking, we HAVE to keep things simple to have a chance of finishing. A playable simple RPG is endlessly more valuable for everyone involved than a 5% finished MMORPG.
- keep it flexible: unlike the FPS, I want to allow the scripters/level designers to use Eisenstern to give each map its own gameplay style, anything from "an FPS with an inventory" all the way to a deep complicated RPG.

Board Index

#40: Re: ..

by R0b0t1 on 08/02/2008 00:49, refers to #39

Hmm, I also know a bit of Intel and AT&T assembler, but I don't think that'd be of any use. Everything runs fast enough. (I haven't looked close enough to see if there are asm routines in sauer, though)