next »

The premise rotates around a simple and well established set up.  The player looks down on his character from a bird's eye view.  Where he points his mouse on screen is where the character faces.  Using a-w-s-d, he moves and strafes the character with respect to where he's facing.  It's got the X, Y, and XcrossY (rotation) fields of motion covered nicely.

The idea is rather free form from there.  We can add in magic, medieval weapons, and any other goodies we see fit.  The trick is to do something here that no one expects.  The control scheme is simple, the gameplay is almost assured to work out.  The key is to put it all together in a way that makes it original and addictive.  Whether that's the way we apply magic or something else can be left up to discussion.

This idea has the merits of being simple.  It should not take long to implement the basics of movement, which allows us to spend more time enriching the experience and adding depth.  It also makes it hard to screw up as a project.  The downside is that we really must do something awesome and unexpected in order to get the attention we need.

this is in 2d, i suppose?

i think we could create this as a Java applet, with games being saved in an online database. that way players would be able to play from anywhere, but a downloadable version could also be made for semi-local play

my Firefox spellcheck says that "downloadable" isn't a word

It's an intuitive compound word; I could probably put it in a formal essay (in proper context, of course) and no one would criticize me for it.

I'd agree that Java is the way to go if we're doing 2D, simply because it makes extending it to the internet a helluvalot easier, and it automatically gives us cross-platform compatability.  Java is also nice to do conceptual design with, since it's heavily object oriented.

i think this would be a nice demo to practice with networking and multiplayer

Why do it 2D, if the game engine should be 3D?

I mean, sure it would be harder for us to make it 3D. But this way we learn how to make it in 3D, and this pre-project is ment for learning, right?
My point is that we should try to use as much of the same technologies in our pre-project as in our main project. This way we  can eventually look back at our pre-project and determine what the best structure would be in our main project. Anyway just my 2 cents

And further more I love the idea of this one, only downside I see is that this one may turn out to be to complicated.

well, this would be an excellent demo for e.g. networking practice. for practice with 3D we have other demos, like the star wars game, for example

you are right, we musn't make it too complicated. however, complex is not necessarily the same complicated

Thats why I said complicated

Multiple demos... Possible, but don't expect to make multiple full games... There simply isn't the time to make them. I think it's better to make 1 good demo, then 2 or 3 crapy ones. So why not take this one and add 3D to it and have it all at once?
We also get a better idea then what it is to work on one bigger project.

well, as i see it, the demos are not going to be full games. for example, the star wars shooter is just one level, one mission, with no multiplayer or other kinds of singleplayer

on top of that, we can design classes so that they can be reused both in other demos AND the RTS engine

Well, you could always render it in 3D, and we could probably do something like TA with a height matrix to modify how projectiles interact with their environment (I probably would have wanted that even if we were going 2D).  Beyond that, there are LOTS of RPG's that really don't have any depth in the Z axis... and in fact, that's characteristic of the RTS genre, too.  If we can handle underpasses and overpasses, terrain obstruction, and rendering in 3D, that's all we really need to be able to do for a RTS

As for complexity (or "being complicated", if we're getting into semantics), the real key here will be an interface.  Players have to be able to use their skills and call upon whatever combination they might be thinking of without having to take a time out.  If we can achieve a good interface, the rest of the gameplay should be fairly straightforward.

Of course, there are two other concerns that I'm sure you have other than interface.  That is complexity from a programming perspective, and learning curve for a player.  The key here is to classify and seperate aspects.   You might seperate different aspects into ideas like "shape", "energy type", "projectile path", and so on.  Each piece describes one independant aspect of the spell (or adds or subtracts things from it), which is interpreted by one piece of code that forms the spell's effect.  The most difficult aspect will likely be graphical interpretation, to ensure that all fire effects look fiery, regardless of their delivery method.

From the player's perspective, they are combining very simple ideas to form an intuitive effect.  If you combine a deflection property with a persistant field (don't think I'm reading from a list of skill I've planned, I'm just making stuff up right now ^_^), you're going to get a deflection field.  It's not because we preprogrammed the combination, but because that's just how the aspects interact.  Because these things will work intuitively, people may only have to remember two dozen aspects.  However, it's these two dozen aspects could form hundreds of spell combinations.  The complication is however great as you wish to approach it, by combining ideas and aspects to form something of greater complexity.

If we can handle underpasses and overpasses, terrain obstruction

which gives you 3d geometry, so it's still 3D after all also think about projectiles flying over walls, flying units, archers that miss vertically, height advantage for ranged units, etc..

As for complexity (or "being complicated", if we're getting into semantics), the real key here will be an interface.

i basically meant it from a technical POV:
- complexity: the amount of features etc...
- complicatedness: the difficulty to program it all

If we can handle underpasses and overpasses, terrain obstruction

which gives you 3d geometry, so it's still 3D after all also think about projectiles flying over walls, flying units, archers that miss vertically, height advantage for ranged units, etc..

I think he meant that we only need to learn that with the demo's, not so much that it will be featured in this demo.

Multiple demos... Possible, but don't expect to make multiple full games... There simply isn't the time to make them. I think it's better to make 1 good demo, then 2 or 3 crapy ones. So why not take this one and add 3D to it and have it all at once?
We also get a better idea then what it is to work on one bigger project.

Yes, 5 preprojects is likely going to be too much. I propose that we keep the other demo slots open for now though. Two are taken, but more may come with good ideas. After a while we can select the two best options and focus on those. After having at least doing part of them, we can start on the final demo, which would include aspects of both demo's and perhaps a few other aspects that the two demo's lack, but which we'll certainly need for the main project.

One of the main aspects for another demo would be AI, since the game is going to use automation quite a lot, this is rather an important element. AI and economics. A Transport tycoon sort of game would be what could combine these two.

Solinx

transport tycoon you say? well, that would be a good one for AI, but we musn't make it about transport. there is already OpenTTD, and we're never going to attract a lot of people with it

besides that, a tycoon game is a nice idea, if we keep it simple and small

Yeah, it was just to give an example, not to immitate.

What about choosing only 2 demo's to focus on before a final demo?

Solinx

what about designing 3/4 demos, and choosing one of them to be the final demo?

We may end up doing multiple pre-projects anyways, so let's develop a few ideas and see where they go.  If we end up making four really good pre-projects and delaying OW a year or so, that's probably worth it.  We'll have proven ourselves, we'll have gotten some attention and a larger team, and most importantly, a fan-base eagerly awaiting the next title fully knowing it's "the big one".

Excellent point, thanks to this project being open source

Solinx

and if we make some really good demos, then

on top of that, we can design classes so that they can be reused both in other demos AND the RTS engine

applies even more

I'm not sure what specifically could be reused, but the experience we garner from these projects will be invaluable, and in specific the teamwork experience will define our future endeavors.

I'm continuing the discussion from the "Gameplay Modes" thread over here, since it's gone off topic (and there is no specific topic about interface or networking currently):

The key to the interface is to be intuitive.  We must get all the technical features needed within the simplest possible form.  That is our challenge.  If I may draw upon an axiom: "an inventor knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away".  This is especially the case here.  We want the bare minimum that will get the job done.  This will hold true for all our projects (pre-project or otherwise), and this will be an excellent opportunity to test our ability to do so.

As far as network coding goes, I can't claim any experience there.  We want to support as many players as possible, and to do that we need to make a good design and implement it well.  I'd love to see 64 or 128 players on a massive server, but realism comes first, and if 8 or 16 is a more realistic target, so be it.  This is the kind of game that could be enjoyable both with a frantic and chaotically pitched battlefield, or a tense struggle between a few characters.

I really think that our pre-projects have the potential to build a fan-base and community before we restart the main Open War project, and those with multiplayer capacity can really captivate interest for long periods of time (which is why I was pushing for player vs player combat in the space shooter pre-project).  I think we should put our hearts into the pre-projects, not just as learning tools and publicity gimmicks, but as real games that can be enjoyed for years to come.

On the topic of graphical styles, I'd prefer to look into something that appears more animated.  Not like "looney toons" or anime inspired animation, but like Baldur's Gate, or Warcraft II.  These games had a realistic feel to them, but an animated look.  The end result was that they ran beautifully on low end systems, but still looked beautiful even for those with high end expectations.

Not much more to add on the interface, we all seem to agree on that one without any discussion

The number of players, well, 8 - 16 seems enough for me. Keeping future developments in mind (in a few years, the hosting could be a lot cheaper per GB, PC's much better/more efficient, and playfields larger), you could try to keep a design change to 64 - 128 players as an option. Or as a possible upgrade.

Yes, good point on player vs player. It not only increases the lenght a game is played, it also makes it publicly known that the game is played.

And seeing you design this project, well, I never expected any other result than at least a decent game. Not competitive with good commercial games, but certainly not neglectable either. I have the same intentions for the tycoon game.

Baldur's Gate style graphics would likely be very popular with RPG players. I've always thought that Bioware made a mistake in going modern with NWN.

Solinx

Well, I wouldn't say NWN made a mistake, but certainly pursuing the path they did required a much higher attention to detail, and it assured their graphics would eventually become dated.  If you look back at Baldur's Gate, it now looks arguably better than NWN because of the animation style.  Really, what I want isn't a BG look-alike, but rather something with that same realistic feel in a world that looks animated.

now that you've posted some more information about how you want to do this demo, i think it might get too big for an applet. the download size every time would be too much, and if we make it a standalone game we can achieve better graphics (use full screen) and better performance

We can use applets for testing software modules, and then bring it all together once we have lots of material to make a full program.  That's probably the best approach.  I don't think I ever thought that this would work as an applet due to how many little things are involved in it.

BTW, I have two midterms next week, so if you're wondering why I'm not adding much material that would be why.  If I don't know fourier transforms relatively flawlessly by this time next week, there's no way I can pass this course.

Not being familiar with the American college system, what's a midterm? And what are fourier transforms?

A midterm is just a major test that is placed arbitrarily somewhere in the middle of the term.  The word is often overused to the point at which any major test that is not the final is called a "midterm".  In this case, each midterm is weighted at 20% of our final marks, but due to a poor class average on the first, he's added some weight to this one so it's 25%.

As for Fourier transforms... just scroll down this page (all the way to the bottom...):
http://en.wikipedia.org/wiki/Fourier_transform

Right...my math is good but not good enough to understand that stuff

The new version on SVN runs in a window now, not an applet