Messages

556

Programming / Re: Let there be light

« on: July 06, 2010, 09:22:01 am »

What, showing off without a hint of code??? How dare you!

Hehe, I was actually too embarressed to show the code, whilst the effect looked "okay", the code was pretty sloppy.

Very nice work! Looks a lot less gradual than the X-Com effect though, I presume you're not done yet?

There are a number of issues with it at the moment, the main one being more than 1 sunrise in a day; secondly, I was getting the last longitude of each polygon and calculating a shade based of longitude and hour. This will also contribute to the relatively "jerky" sunrise.

It's populated by Globe::setSavedGame.

Good call (pardon the pun), I didn't see that 

I just tried it myself in the original, you're right that the ocean has 6 shades, but each land polygon seems to have 9-10 shades.

Hmm, perhaps I need to dump the palette out so I can see what I've got to work with. I'm sure if my "shade" variable went negative, or above 6, the globe went psychodellic.

Actually, I dumped the palette out:

At least 16 shades, which will also make a smoother transition.

On with the thinking cap.


Also, one last thing. As you noted that there are shades of ocean, you're just drawing a blue circle. Are there ocean polygons that are just not being drawn yet? or is that going to need some wizardry to paint?

557

Programming / [Solved] Let there be light

« on: July 06, 2010, 12:10:13 am »

I've been playing around with the code
https://www.youtube.com/watch?v=VnQjsGGmeNk

SupSuper, a few things I noted when building this:

• Variable Globe::_save is never populated (I added it to the constructor)
• Day to night palette appears to be 6 shades

You're probably aware of these, but thought I'd mention if not  

558

Programming / Re: [TASK] Detecting if a point is inside a polygon with wrap-around.

« on: July 02, 2010, 09:48:45 am »

The only way I can think of doing this is in your polygon check, is to multiply all the coordinates by 100 (or even 1000). This should increase the tolerance on these crossover points

559

Programming / Re: [TASK] Converting cartesian coordinates to polar coordinates

« on: July 02, 2010, 08:14:23 am »

Excellent news!

560

Suggestions / Re: Configurable alien/civilian counts for terror missions or base assaults?

« on: July 02, 2010, 01:06:52 am »

Nar, editors can be as buggy as hell, just as long as they read and write the data properly, you don't have to go near as much polish as a game.

561

Suggestions / Re: Selling soliders

« on: July 01, 2010, 10:41:40 pm »

I've just been playing Apoc again, I'm thinking it's the first base attack I've ever had (Apoc didn't get as much play time as TFTD), and your right, they get some stats, and you have to control them during the game. I just hid them in small rooms :-)

One other thing I noticed, is that you seemed to get charged a constant value regardless of the scientist's/engeineer's skill. Meaning just grab the highest you can, and not balance expediture and skill.

The idea of junior/senior/chief is a nice idea.

562

Suggestions / Re: Support for interchangeable gameplay features from all 3 X-Com Games

« on: July 01, 2010, 01:10:26 pm »

Apocalypse is too radically different to merge. In both graphics and gameplay. Porting the aliens, weapons, research etc. across to UFO/TFTD would be possible, but you'd have to redo the graphics so they keep the same visual style.

I really liked some Apoc tactical features like Aggression, but some (most significantly was shooting mode) made the UI cluttered and I kept forgetting to set before I shot.

563

Suggestions / Re: Selling soliders

« on: July 01, 2010, 12:54:51 pm »

I enjoyed xcom apoc a lot too, but never cared for personification of the engineers/scientists as they're so auxiliary. I remember they had all the stats of a soldier

Actually, they only had a "Skill" stat, it affected how much they cost, and research was done by needing Total Skill points to complete. You'd sum up all your scientists on the project (I think it was daily), and added that to your Progress. Once Progress >= Total, you had researched the item.

But still, to be able to defend personifying these supporting actors/actresses the game would need some more detailed research/manufacture gameplay imo.

I agree, and to be honest, I would like more involvement in the research side. That said, I have no idea how you could do that in the game, keeping it fun and not massively overcomlicated.

564

Suggestions / Re: Selling soliders

« on: July 01, 2010, 12:44:19 am »

XCOM Apoc went down that approach, but not just with soldiers, but with your scientists and technicians too

565

Programming / Re: [TASK] Converting cartesian coordinates to polar coordinates

« on: June 30, 2010, 09:01:00 pm »

SupSuper: Longitude is thrown out wildly with that - _rotLon

If anybody else is looking at this, my code segment so far is

Code: [Select]

void Globe::cartToPolar(Sint16 x, Sint16 y, double *lon, double *lat)
{
  double dr = (_radius * _zoom);
  double dx = (double)(x - _cenX);
  double dy = (double)(y - _cenY);
  double dz = sqrt( (dr * dr) - (dx * dx) - (dy * dy) );

  *lon = asin( dx / (dr * dz) );
  *lat = asin( dy / dr ) - _rotLat;

  https:// Check for errors
  if (!(*lat == *lat && *lon == *lon))
  {
    *lat = COORD_OUT_OF_BOUNDS;
    *lon = COORD_OUT_OF_BOUNDS;
  }
  else
  {
    *lon = longitudeLoop(*lon - _rotLon);
  }

  https:// Debug
  https:// cout << x << ", " << y << ": " << _rotLon << ", " << _rotLat << endl;
}

With this, you can rotate it any way you wish and the selection will remain central (X axis) to the planet.

566

Programming / Re: [TASK] Detecting if a point is inside a polygon with wrap-around.

« on: June 29, 2010, 05:54:28 pm »

Glad to help.

Interestingly enough, I've noticed the other day, that a few places where the hit test written to cout is incorrect. The only one I can remember clearly is West Africa around Nigeria, Niger and Mali.

I think there was one around the Gulf of Mexico, but I can't remember.

Don't know if these will be fixed with your new method, I'll update my copy of the source when I get home and give it a try (if you've checked the changes in)

Edit: The new source fixed that spot in Africa, but I've found another

567

Suggestions / Re: Anti-suggestions

« on: June 27, 2010, 01:42:55 pm »

Engines are separated not for saving memory. Look at Worms, for example. They have separate GUI for options and "battlescape". It just simplifies program.

If Battlescape died it is a bug. Just handle signals properly so it would be impossible to quit by closing the window.

But it's just completely unnecessary, and adds complications. It also means duplicating certain code (General GUI widgets for menus and buttons etc.)

Keeping it all in one program lets you access *any* data related to the game from whichever screen you're in. If you seperated them, you'd have to change two programs if you needed to expose any new data.

But ruleset probaly won't only contain stats but also formulas / algorithms. For example calculating shot accuracy in battlescape. In original ruleset accuracy won't be dependent on distance, but maybe in "openxcom" ruleset it will be. There can be also another factors for that. How would you like to put this in file? Without scripting language it will be difficult.

I agree with Eeyoocah here, whilst your class which holds the stats in memory, and has the algorithms for the game can be placed in the class, I would load the stats from a file in the constructor. Your algos don't need to change, so that's fine, but it does give you tweaking power...

568

Suggestions / Re: Couple of (mostly) gameplay related ideas

« on: June 25, 2010, 09:44:35 pm »

A window popping up asking you if you're sure... come on, man. 

To be fair, I've never seen or played Jagged Allience 2. All I read was "forces you to confirm any movement command"...

Granted, I was a bit slow on picking up double clicks though 

569

Suggestions / Re: Couple of (mostly) gameplay related ideas

« on: June 25, 2010, 06:24:44 pm »

How about just a "Undo/Rewind" move button?

Undo/Rewind is hard to implement that way it won't let you cheat. Look at The Battle for Wesnoth, they let you undo, but only if you haven't discovered anything or disabled shroud updates at your turn.

True, I did think about that, but could you imagine the "Are you sure you want to make this move?" every time 

570

Suggestions / Re: Anti-suggestions

« on: June 25, 2010, 01:19:12 pm »

For example, you have "Soldier" class.  Most of it's methods just get and set private fields.  There is only one place in code that modify soldier's names, it can handle everything that is related to renaming so you don't really need "setName" function.  And nothing is calculated when you get name so you don't need "getName" method.  Just make "name" field public.

Whilst on occasion I'll do this, it is looked upon as bad practice; it also means that should you want to enter any validation or cascading updates based upon the field, you'll have to reimplment the methods anyway. Example of the latter is if you want to set Arm Damage, you might want to cascade an update to Accuracy to decrease it, then you don't need to be constantly recalculating the value.

Also you have XcomRuleset that is based on Ruleset.  You don't really need more than one ruleset in one game, just create one "Ruleset" class and everyone will be able to modify it if they want to change rules of the game.

I think it was in a news post, SupSuper was referring to a screen to toggle fixes/options on or off (before the game starts). I'm assuming that they will be implemented as rulesets. Could be wrong on this point though.

If you want others to be able to modify game engine, don't try to create bulletproof abstractions and don't add scripting engines. Abstractions don't let you fully modify game until you understand code behind them.  Scripting engines are even more limited.

Have you ever worked with Unreal Tournament (the original, I don't know a lot about the others)? Abstractions are good, because you don't need to understand the code behind them. You just inherit the original (with code), and add/replace the bits with your new version.
As for scripting engines, well, if you break open the Unreal Tournament code, you'll find that almost every aspect of the game is scripting. Okay, so the script gets compiled before running, but it's still scripted.

In all, designing it in the way it's being done should actually make your life easier should you want to start hacking away at parts.

Sorry if this seemed a little negative. I think the structure of the code looks good, and will be more beneficial to hackers and modders with this approach.

As for not implementing new features until the original stuff is complete, I can see where you're coming from, but if you don't plan for some features, you may have to rewrite segments of code to add it in later. I think features do need to be thought about, even if they are not implemented at the time.