While catching up on the Graphics forum, I realized that some of the discussion there overlaps with things that I have already done in the combat engine, or had already planned to do. Little surprise there, since I haven't been keeping anyone informed about whatever it is I'm up to. So, this is an attempt to remedy that.

In general, what I'm doing in the battle demo is get the basics down. This means you should be able to see what's going on and interact with everything. So, here's the

DrivewayMap ('cause we're not quite in the road yet):1) Add star, planets, ships, and backgrounds to the scene.2) Add a way to move around in the scene, looking at things.3) Add a way to give simple orders to things that can obey orders.

Also, I needed to learn how to use Ogre to the full. As a bonus feature, it would be nice if the basic demo were pretty enough to attract some more developers from the Ogre forums.

What has been done:- Integration of Ogre and GG. Ugh.- Basic implementation of stars, planets, and a mouse navigation-interface.- Basic (big fat bounding-box-based-) picking of objects.- Selection and de-selection of objects, for e.g. forming groups or giving orders to multiple objects.- It's pretty pretty.

What needs to be done still:- Better picking, using a physics engine for hit-detection (in progress, using the Bullet physics library).- An interface for adding ships to the scene for testing (possibly partially reusable as the interface for placing ships before combat).- Basic graphical effects for LR and SR/PD weapons.- Fighters! I plan to integrate OpenSteer to give us Boids-like flocking behavior for the fighter squadrons.- An interface for giving movement and firing orders to ships and fighters.- A turn system, so we can test out movement, firing, and other orders in queues over multiple combat turns.

At this point, we will be nearly feature-complete, at least for the basics. We'll have enough stuff in place to know what needs tweaking, and enough stuff in place to start adding actual game logic from the 0.4 Design Pad. We will be officially back on the road at that point.

Alright, the last post gave you a bit of detail about what I have planned. The stuff covered in the last post is mainly the preamble to the real work of turning the 0.4 Design Pad Wiki document into an actual usable combat system.

The progress towards this goal has been slow (I don't need to tell you that, right?). This slowness has essentially been due to the fact that I've been learning how to do things with shaders, Ogre, and now a couple of other supporting libraries that are getting dragged into the mix. Hopefully, once we're out of the driveway, things will go much faster. Hopefully.

Now I'd like to dump as many decisions as I can think of that I've already made about the combat system without anyone else's input. These kinds of decisions are made by the programmer because the Design Pad (DP) does not have sufficient detail from which to write a program -- it's more of a sketch, and a lot of the detail has to be added later.

This will be as complete as I can manage, which is probably going to be pretty incomplete, but here goes anyway:

- Assumption: Ships can pass through each other. That's right! I said it! Ships are not solid wen it comes to other ships. This is done because its much easier to implement than doing collision detection and pathfinding to move around potential collisions. All the ships will be in the plane of the system's ecliptic. This means that we're not using that third dimension for anything, so it's reasonable to say "They could fly past each other at different heights, so let's pretend they are." Actually implementing this passing-each-other business is a lot harder than you might think, so let's KISS and fake it (so to speak).

- Assumption: The system will be 1000 units in radius, centered on the system's star. This is a bit arbitrary, but some of the 3D math (the far clipping plane to be exact) works better with smallish values for the scale of the space in the rendered scene. I played with several numbers, and that one fit nicely. The (up to 10) planet's orbits are spaced about every 100 units out around the star. The smallest planet is 2 units in radius; the largest is 11. The star's radius is 80 units. A "medium" hull is 1/4 units long (note that this makes ships very out of scale, but you otherwise wouldn't be able to see them). These look about right, but are certainly open for tweaking once we have enough of a system to see how everything works together.

- Assumption: You don't have a piece of crap video card. Whoa, now he's getting personal. There's a lot of work put into using the latest 3D techniques to make things look good. I could do more to accommodate people with older cards, and I might do that if it's really easy. However, my time is usually pretty limited, and by the time this game reaches 1.0, today's $150 card will probably be in the $5 bin, so I may not want to spend my precious time on your precious hardware.

- Assumption: No one needs to see the seedy underbelly of their fleet. I have taken the analogy of a table-top game and applied it to the combat map. You can think of the system map as lying on a Lazy Susan on a table. You can look at the map on the table from your seat, or rotate the map to get a better look at some particular area, or you can stand up to get a better look at the whole thing, but you can't climb over the table, or look under it. (I might be willing to relax this and let you look under the ecliptic, down to ~15 degrees below or so.) Sound skeptical? Don't knock it 'till you've tried it. It really keeps you well oriented at all times.

- Assumption: Planets are at fixed positions during any given combat. They do however orbit their star, at a speed related to their orbital position (close-in planets move faster). I've taken an orbit-3 planet (like Earth) to have an orbital period of 4 turns (which makes a turn implicitly 3 months long). This means that multiple combats in the same system on different game turns will show the planets in different positions, as they move through their orbits.

I'm sure there are more, but these are all I can think of right now that are already implemented. Enjoy.

Alright, the top item in the TODO list mentioned in the first blog entry is done. In fact, it was done about 24 hours after that blog entry went out:

Quote:

- Better picking, using a physics engine for hit-detection (in progress, using the Bullet physics library).

So, what I've been working on since then is

Quote:

- Fighters! I plan to integrate OpenSteer to give us Boids-like flocking behavior for the fighter squadrons.

Yes, I know that skips a couple of other items on the list. I tend (like everyone on this project) to work on stuff I find fun first. The basic fighter behaviors outlined in the Brainstorming thread are implemented, and the few that are already testable have been tested. The rest will have to wait until the ships get protoyped too (and I'm just starting on that -- look for a Ship Missions thread in a few days).

The fighters look great, or rather their movements do. The fighters themselves look like little boring trangles, because I'm just trying to get the motion part down right now. The fighters fly in squadron-formations of 5. The layout of the positions in the formation is like a pyarmid. Imagine a fighter laying on its tail, pointing upwards. Now imagine that you place on fighter like this at the top of a square pyramid, and one at each of the four base corners. That's the formation. The formations are loose. That is, the fighters don't move in unison. They do more realistic, complex maneuvers like: if something hostile comes close, they tend to spread out to avoid it; if they make a turn, they tend to bunch up on the inside of the turn; etc.

The nice thing is that the formations can be anything we like -- I just chose the pyramid shape to have something simple and easy to test. We can also change the numbers of fighters per formation. Eventually (i.e. post-0.4), we might want to give each race its own formation size and shape.

The fighters have the NONE mission set, which means bombers fly around aimlessly, since they have no ships to attack, except that they do try to avoid enemy interceptors. It's really cool to see them break formation when trying to run from them. The NONE mission also means that the fighters are all chasing around the nearest enemy bomber formation they can find.

Next, I'm going to add a few ships to the prototype app and have the bombers attack target ships while avoiding PD ships. After that, it's ship missions.

Finally, I'm sorry I haven't been able to make the Windows demo of the fighter prototype work, but I haven't. I made a demo and uploaded it for all to see, but it doesn't seem to work on anyone else's system. I have no idea why this is, or how to fix it. Once things are further along, I might make a Fraps video and put it on YouTube (no promises, though).

One other thing to blog about today: my wife Krista is pregnant. This will be our first kid. She's due on October 16, and we're having a boy. This isn't so much a "Hooray, congratulate me" post as a "I don't really know how this will affect the project" post.

Here's my worst case scenario: She has the baby early, like September 1, and I have no time and/or lose interest and focus on the project. And there's an earthquake and my house burns down. I said worst case. This may be unrealistically pessimistic.

Here's my best case scenario: She has the baby on time, October 16, and I drop off the face of the earth for at most a couple of months while my life adjusts, then slowly start back to work on FO-related stuff until I'm at the same level of involvement I'm at now. This may be unrealistically optimistic.

The reality will probably fall somewhere in the middle. There is almost certain to be some amount of time around two months or so that I won't be able to do much work on FO, if any. After that, I hope to be in a better position to do more. Time will tell. At the very least I can say that, while my interest in the project sometimes diminishes for weeks or months at a time, I feel I've put too much into this project to walk away now. So, I'll be around in some capacity at least, and I hope I'll be able to contribute almost as much as I am now.

Alright, it's been months since I updated you guys. Man, I didn't realize how long until I noticed the date on the previous post. So, in the last 6 months, I have had a kid, Max, who is consuming most of my free time now. I have also been working on improving GG (the GUI library we use in FreeOrion), specifically adding Unicode support. Unicode, for those of you who don't know, allows you to represent text in any language, not just English and a few western European languages. I'm still trying to finish this work. It should be done by the second week in January. My pace of work is very slow ATM. It's about a quarter of what it was before Max was born. I really have to work hard to steal time to work on FO.

As for the Ogre 3D integration/tech demo and the stuff with the fighters, there has been no progress at all. I know, I'm disappointed too. I hope to get back to all that stuff after my GG work is complete. On that bleak note, I'll leave you for now. I'm off tomorrow for a week in St. Croix in the U.S. Virgin Islands.

Ok, I thought I'd post again now that I have some good news to report. I have merged the ogre-integration code branch onto the trunk. If that means nothing to you, basically it means that our main coding effort (the "trunk") is using Ogre now for our underlying system support instead of SDL, and we now have access to the Ogre rendering engine. This also means that the next point release will have the Ogre tech demo in it as a special mode. You'll be able to run FreeOrion in a special mode and see for yourself the current state (very early) of the combat engine. I'll post again when the next point release is ready (hopefully in a couple of weeks or less).

Another update... I've put a new release, FreeOrion 0.3.12. Hopefully we'll get an announcement up soon with all the changes listed, but in short, it has a few key bug fixes and a rather oversized Easter egg. If you run FO from the command line (it should be somewhere like c:\Program Files\FreeOrion\freeorion.exe) with --tech-demo, you'll see much of the work so far on the combat engine. There are some things that are only partially implemented, slightly ugly, or just plain broken. If you have the chance, try out the tech demo and report anything that looks like a bug on the SourceForge page. As always, please log in, even if you have to create an account, so we can ask follow-up questions to your bug reports. The combat engine is actually using much more of your video card's abilities than the rest of FO ever has, so different hardware, drivers, etc., are more likely to cause problems. This means that we need lots of people to look at it on lots of setups, and to provide us with feedback if we're going to get the combat engine moving forward.

Using the mouse in the demo requires a bit of explanation:

You are always looking at a point or object in the ecliptic of the star system. You can zoom in or out from that point by using the mouse wheel. If you're looking at an object, you can zoom in only as far as the size of the object allows -- you can get closer to smaller objects than larger ones.

You can also move around that point by middle-dragging the mouse. You can only look down on the ecliptic, but can't rotate underneath it. This is to keep you oriented. You don't have to worry about looking at the map from underneath, and thinking that the starlane entry point on the right takes you to the right on the main map, when in fact it would take you to the left.

So, think of the zooming and rotating as "the middle mouse button/wheel controls my POV".

The left button can be used to select objects with a simple click. You can left-double-click an point or object to change your look-at point.

The right button is reserved for later use. It will be used to give move, attack, and other orders to your units.

Potential issues:- The highlighting effect on the single ship in the demo is messed up. It's a problem with that model, not the code. We're going to get a fixed model soon(tm).- The textures used on the planets are placeholders. Some look better than others, and some are combined in a way that looks pretty terrible. This is not really a bug either.- The Windows cursor is showing on top of the FO cursor. I'm working on that.- FO now requires OpenGL 2.0. Update your video drivers and hope for the best .

Things that are not implemented yet:- Almost everything that will eventually be part of the real combat engine, like movement, fighting, starlanes, ....- Planets will have night-side city lights. This is in progress; the Barren planet already has some lights in the demo.- Ships will look a lot better. This is also in progress.

Another update. I've been working on the combat engine a lot lately. Here's an update on the original list I posted back in June, since I realized I never seem to revisit these lists:

Quote:

What needs to be done still:- Better picking, using a physics engine for hit-detection (in progress, using the Bullet physics library).

Done.

Quote:

- An interface for adding ships to the scene for testing (possibly partially reusable as the interface for placing ships before combat).- Basic graphical effects for LR and SR/PD weapons.

These haven't been started yet.

Quote:

- Fighters! I plan to integrate OpenSteer to give us Boids-like flocking behavior for the fighter squadrons.

The fighter control code is done, but it hasn't been integrated into the combat engine yet.

Quote:

- An interface for giving movement and firing orders to ships and fighters.

Not started yet either.

Quote:

- A turn system, so we can test out movement, firing, and other orders in queues over multiple combat turns.

The server and clients now can talk to each other in terms of turns, and the orders that can be passed to the server are defined, but there's not yet a way to give orders in the combat engine, so the turn-based logic is disabled.

And here's another more recent list update:

tzlaine wrote:

Things that are not implemented yet:- Almost everything that will eventually be part of the real combat engine, like movement, fighting, starlanes, ....

In progress, obviously.

Quote:

- Planets will have night-side city lights. This is in progress; the Barren planet already has some lights in the demo.

Done.

Quote:

- Ships will look a lot better. This is also in progress.

Done.

Also, I implemented asteroid fields finally. Before, you could only see planets; there was a big gap where the asteroid belt should be. Here are some screen shots:

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum