Candle'Bre - The Early Releases

[Velociryx]

Per reader request, I've begun a thread to discuss *specifically* the state of the game in its present form....this should, as time goes by, enable everyone to get a pretty good feel for where we've come from, developmentally.

Part of this comes to diffuse any potential disappointment when the first public release comes out and it doesn't have all the bells and whistles that we've been kicking around here.

Trust me...it won't. Not even close. (but it'll get there! )

In fact, our first in-house version that we'll begin our testing with, will essentially be a map, the combat system, and the ability to build temples (for intercessions) and barracks to train your guys.

That's it.

Combat will be handled at the strategic level, no techs, no military improvements....none of that fancy stuff.

With each successive build, we'll add in one or more components and begin fleshing them out...and next on the add-list is the Fate Engine....that should be cool....

-=Vel=-

[Velociryx]

Just to keep everybody updated on the state of the game at present, we've decided that for the v0.1 build, we're gonna have all combats auto-resolve (computer handles the actual combat and reports the results).

Our reasons for doing so are manifold, but the major ones go something like this:

* Right now, we're designing the basic framework that'll support the rest of the game (all the coolio features we've been talking about here). It's not so much a test of the combat system per se, as it is a test of the structural integrity of the basic program....once we know it's working, we'll be able to start buildingn onto it and fleshing it out.

* We're planning on having an "auto resolve" option to present to players, and this will FORCE our attention on it...make sure it's giving acceptable/expected results for those who choose to use it.

* Ease of coding. Since there are no data packets flying back and forth between players in an MP environment, the whole structure to support that is not yet needed. Should be a snap to just have the computer worry about it all and report the results.

* It's an in-house release...not going to the public, so it doesn't have to be elegant or pretty just yet, it just has to work....

More news as we get closer to v0.1's release!

-=Vel=-

[moomin]

Originally posted by Velociryx
* We're planning on having an "auto resolve" option to present to players, and this will FORCE our attention on it...make sure it's giving acceptable/expected results for those who choose to use it.

Grog wants auto combat!

* Ease of coding. Since there are no data packets flying back and forth between players in an MP environment, the whole structure to support that is not yet needed. Should be a snap to just have the computer worry about it all and report the results.

I'm honestly at a loss 'bout what MP has to do with this - or packets, for that matter. Surely combat is going to use the same coding in single/multi player, "farming out" the update of state to routines that affect variables directly in single player or routines that update state via network connections in MP?

* It's an in-house release...not going to the public, so it doesn't have to be elegant or pretty just yet, it just has to work....

Are you gonna consider letting a select few with a proven interest take a peek and get some comments in? People like, say, GP?

[Velociryx]

:: shrug:: Hell if I know...I don't claim to understand all the ins and outs of it, but it's got something to do with the fact that combat will be an interactive operation in this game, requiring player input to proceed, thusly:

player 1 gives his tier one orders

player 2 gives his tier one orders

resolution

player 1 gives his tier two orders

player 2 gives his tier two orders

resolution

player 1 gives his tier three orders

player 2 gives his tier two orders

resolution

Alternately, we could give all orders at once and have one large resolution step, but this would still requiring passing data back and forth between the two players in MP to update both the screens and their "world packet" (not sure what word I'm looking for there, but the file that contains all pertinent info on the game world as they percieve it).

Either way though, there's a higher degree of interaction in MP Candle'Bre than there is in MP Civ....where two units meet and slug it out without player input.

Different from the SP environment, I would think, in the sense that the data doesn't have to "go" anywhere....although, I will readily admit that this isn't my area of expertise...lol...so take all of the above with a grain of salt.

All I know is, v0.1 will be autocombat....

-=Vel=-
PS: For the pre-alpha releases, we gotta keep those in-house, but...I'm hoping that fairly soon we'll have some screenies and or other art to showcase!

[Chowlett]

One slight thought - how will the autocombat button work in an MP game? Do both players have to agree, or what?

[Zealot]

Huh, I forgot to ask, so:
Will the game be for Windows, Linux, or both?

[moomin]

Originally posted by Zealot
Huh, I forgot to ask, so:
Will the game be for Windows, Linux, or both?

I understand they're targeting Mac OS X initially.

[TechWins]

Well, if the first version is for Windows I would really like to be able to take a look at the game. So if you do decide to let a select few look at the game, like moominp said, I hope I could be one of those select few. What do ya say, Vel?

[xRamsesx]

I'm honestly at a loss 'bout what MP has to do with this - or packets, for that matter. Surely combat is going to use the same coding in single/multi player, "farming out" the update of state to routines that affect variables directly in single player or routines that update state via network connections in MP?

You're right moomin, the actual combat code will hardly change. But the current combat model in the rules uses interaction from both players. Whilst we're including MP from the get-go in the game, adding MP combat communication and display is a whole other set of code that won't be used for our first version. It just makes our lives that mush more easier when integrating all the little pieces as well as make combat debugging easier.

Will the game be for Windows, Linux, or both?

The game is in Java, and so far we're not planning on using any OS specific APIs. So theoretically it should run fine on both Linux and Windows. However, if that ends up not being the case we'll prolly put in the extra effort to make it work with both since both Linux and Windows are our target platforms (keep in mind though that we are in the early stages so if/when we run in problems we'll need to think about that more carefully).

[Velociryx]

Yeah...what Ram said....

-=Vel=-

[TechWins]

So is that a yes or a no to my question, Vel?

Ram, are you using OpenGL for your API then? SDL? Allegro?

[moomin]

He already answered upthread, TW. The answer, I'm sorry to say, is no.

[ravagon]

Originally posted by Velociryx
Combat will be handled at the strategic level, no techs, no military improvements....none of that fancy stuff.

Is this only for the first public release or is the involved tactical level combat going to be restricted to the commercial version?

If the latter I think that may be a bad move publicity-wise as a large element of the appeal to the "average gamer Joe Bluggs" would lie more in the classical rts-style "throw-troops-at-enemy", "watch-enemy-troops-being-obliterated-in-large-numbers" vein...

Oh, er, hi Joe

[Velociryx]

Hiya Rav...actually, that's for the first private release, tho I suspect that when we're ready to show something off to the public, we'll still be at the point where combat's handled at the Strategic level.

You're right though, that there seems to be quite a calling for tactical level resolution, and if there's any way we can work that into the later stages of the free release (perhaps not in it's fullest complexity, but we can certainly shoot for that), then at least in some form or fashion.

Can't promise it, cos at this stage, there's no way of knowing exactly how much of a bugbear that'll be as far as implementation and tying it into the existing design, but yes, based on the feedback I've gotten so far, it's something I'm VERY excited about!

-=Vel=-

[xRamsesx]

Originally posted by TechWins
So is that a yes or a no to my question, Vel?

Ram, are you using OpenGL for your API then? SDL? Allegro?

Sorry TW, I didn't see this till now. We're using Java2D and Swing for now. So we'll be doing everything in Java and the JREs in turn use the APIs available on the OS they're running on. I don't know what APIs Java uses but my guess would be directX on windows and maybe SDL for linux (but I'm just guessing, I never actually looked up that info ).

[moomin]

And you should stick to it too. While I don't particularly approve of the Java choise to begin with, once you've chosen that road J2D and Swing are definetly the right tools for this particular job.