FAQ Search
Memberlist Usergroups
Profile
  Forum Statistics Register
 Log in to check your private messages
Log in to check your private messages
Moonpod Homepage Starscape Information Mr. Robot Information Free Game Downloads Starscape Highscore Table
March-04 : World Simulation
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary View previous topic :: View next topic  
 Author
Message
Moonpod Developer Diary RSS feed -RSS Feed
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Tue Mar 16, 2004 5:26 pm    Post subject: March-04 : World Simulation Reply with quote

I've been working on the underlying simulation of the world, this is non-combat stuff that is necessary to frame the fighting. A lot of RTS games just have pre-designed levels that you complete in order, with a linking plot and story, but Battlescape isn't like that. Instead everything is built on a pure simulation and the game play should develop differently every time you play it. I'm hoping certain pre-defined events can be layered on top of that so that a certain amount of story can unfold, but all that comes later. The first priority is to build a world that behaves logically and can give meaning to the fighting.

To this end the Battlescape world consists of a number of cities, each with a random inherent potential for food(farming), geo-thermal energy(power stations) and ore(mines). Initially the cities of the world are shared between a number of different controlling factions and each is given a few basic buildings to start out. As each faction begins to build its army natural dependencies develop i.ae. the recruits need somewhere to be born, homes need food and energy, cities need factories and workers, tech research needs science labs, etc. So the cities grow.

Some resources can be produced more cheaply at certain cities so specialization occurs. For example a particular city might be ideally situated for power generation, so over time it will become the main generator for the entire faction. Given enough time natural strengths and weaknesses develop within a faction's support systems as it grows and shortages emerge. As one faction tries to develop a huge army the maintenance costs require it to control more and more territory, this exposes weakness as its borders grow beyond its ability to defend. It also means he is going to have cities with a lot of buildings covering a lot of area, that is going to be difficult to defend without causing a lot of damage should a city be attacked.

Anyway, the theory is that each time you play, the order of events is different depending on how the map shapes up. The goal is to make it feel like there is thought behind the AI's actions, to give the player the ability to make strategic choices. For example, if lack of suitable land has forced a strong neighbour to consolidate power generation into one city then you might be able to exploit that. Take out that city first and all his factories shutdown so he can't reinforce himself with new units - simple. Conversely if you're the poor schmuck with no access to a decent power supply then you either need to expand your borders or make friends with someone who has a power surplus and can use something you have in excess. The foundation of diplomacy.

A big problem is hiding a lot of the complexity behind this, Civilization did a great job of that. If someone just wants to focus on fighting then they need the option to let the AI take over city maintenance (as long as it doesn't do too good a job). They also need access to advisors who can summarize what is happening and prompt them with what to do (again you don't want them to spell it out, just suggest sensible options). If you don't care about any of this management stuff then at least you should understand why a particular city on the vulnerable northern border has decided to expand itself into a juicy target for the enemy (that you are now hard pushed to defend). Anyway, that is something for later I think.


So all i'm doing at the minute is staring at numbers and watching little graphs grow and shrink. Not particularly exciting, but rewarding when it works correctly.
Back to top
View user's profile Visit poster's website
Goober
Pod Team
Pod Team


Joined: 11 Oct 2002
Posts: 449
Location: Moonpod Central



PostPosted: Tue Mar 16, 2004 5:32 pm    Post subject: Reply with quote

Well, work has been underway on the new engine for a little while now, with most of the effort (so far) directed towards the rendering side of things. This month has been no different in that respect, but it's worth remembering the non-glamourous code when you're looking at a shiny shader effect. I implemented an assert box, with built-in call stack tracing. There are probably a bunch of questions resulting from this statement, (1) what the heck is an assert box?, (2) what the heck is call stack tracing?, (3) how does that help you when you're writing a game?

Asserts, are conditions that you expect to be true at a given point in the code. If the assertion fails, then the code is broken in some fundamental way, and you should investigate why. For example, if the player is supposed to be alive at a given point in the code, then you could add a

Code:
// MPASSERT is Moonpod's assert macro, see further down for details
MPASSERT(pPlayer->IsAlive());


If the boolean expression inside the assert results in false (i.e. the IsAlive function returned false, the player was pegged by an asteroid and you weren't told about it), then you would want the game to immediately stop and inform you that something you thought was impossible has actually happened, which it does by popping up a message box (hence "assert box").

The assert is actually a macro that calls a function. The function is prototyped as

Code:
void MPAssert( const char *expression, const char *file, unsigned int line );


and the assert macro is

Code:
#define MPASSERT(e) if (!(e)) MPAssert(#e, __FILE__, __LINE__)


This is cool, because the preprocessor (the bit that runs before the compiler proper) will expand the macro out in the code to include the proper filename and line number where the macro is used, and even turn the expression into a string. Those three things can then be passed into the MPAssert function and output in the message box that appears.

This works pretty well most of the time, but there is a case where you run your app on a PC that doesn't have the development environment installed, so you can't just launch the debugger and start stepping through the code line by line to see what went wrong. Ok, that's not too bad, until an assert pops up that's in a utility function you call from loads of places. You really want to know where it went wrong (i.e. the function that called into the utility function). That's where a stack trace comes in handy. The call stack is basically a record of the functions that are currently executing, from the operating system call that launched your application, right down to the current piece of code. Now, the latest Moonpod assert includes a call stack trace so we can see in what function the assert fired, which function called that one, and so on, and we can get a better idea of what actually went wrong.

How does this help when writing a game? Well, during development you'll crash your game more times than you've had hot dinners. The more efficiently you can find and fix a problem, the more time you've got left to implement more cool features (and maybe even write a developer diary Smile).
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Mar 16, 2004 5:41 pm    Post subject: Reply with quote

Went to Barcelona! Woo!

Have been working on basic trooper animations. This has made me realise the major limitation wings3d has > no animation support! Plus it's a bit of a nightmare to even deform the mesh in a realistic way. Since each frame has been rendered out through the 3D engine, I only need to make each frame of the animation as a separate deformed mesh. Thankfully, once the run is out of the way, this isn't too hard for the remaining anims.

We are definitely going to have to look into other 3D packages in the future, but for now I can just about scrape by. I can't see us doing anything that involved animated skinned meshes in the future because there is obviously nothing to do that in wings.

All the other units don't really present any new problems over those Starscape has, and Goober has improved the toolset from wings - 3d engine - output sprite so it's pretty much automated for me which has sped things up no end Very Happy

Since the in progress 3D engine has been coming on leaps and bounds, we are considering using it in various capacities throughout Battlescape. So I'm also working on some 3D game models so we can test out what might be possible.

Lastly, I've been mocking up different ways to do the 'World Map' section of the Battlescape. I've narrowed it down to two ideas.

One basically involves making a new map each time, and creating separate masks for each 'zone' you will fight over.
(mockup, not from actual game Very Happy )


The other uses 3D blocks to construct the world map. If I can get the latter looking good, it would also mean that random world maps could be done (or potentially built by end users at some point), it opens up a lot of options anyway. Since Poo Bear is still working on how this will be implemented I need to give him lots of options for how it 'might' look.
Something like this:
Back to top
View user's profile Visit poster's website
jollyreaper



Joined: 20 Jun 2003
Posts: 181



PostPosted: Tue Jun 01, 2004 1:08 am    Post subject: Re: March-04 Reply with quote

Poo Bear wrote:
I've been working on the underlying simulation of the world, this is non-combat stuff that is necessary to frame the fighting. A lot of RTS games just have pre-designed levels that you complete in order, with a linking plot and story, but Battlescape isn't like that. Instead everything is built on a pure simulation and the game play should develop differently every time you play it. I'm hoping certain pre-defined events can be layered on top of that so that a certain amount of story can unfold, but all that comes later. The first priority is to build a world that behaves logically and can give meaning to the fighting.


Makes sense. If you can't get that part working, nothing else is of any value. Fun comes first!

Quote:
To this end the Battlescape world consists of a number of cities, each with a random inherent potential for food(farming), geo-thermal energy(power stations) and ore(mines). Initially the cities of the world are shared between a number of different controlling factions and each is given a few basic buildings to start out. As each faction begins to build its army natural dependencies develop i.ae. the recruits need somewhere to be born, homes need food and energy, cities need factories and workers, tech research needs science labs, etc. So the cities grow.


I take it you will have a research tree, yes? If you only have a small number of cities under control, maybe 12, it's fun to tweak them out with all the new buildings and upgrades. When you play a big game like Civ, Master of Orion, Master of Magic, you could end up with 60 or 80 cities/worlds. Becomes a micro-management nightmare.

If you do want to have a large number of cities, your sanity might be preserved if you have one master economy interface screen and simply treat each city as a contribution to that instead. You start out with one city, you have only 15 production points generated per minute. By the time you have 50 cities, you may have 1000 produciton points per minue. From that interface you decide how many resources you want to devote to manufacture, upgrades, and research. Your cities will then develop logically from there. If a hex has strong energy potential, it's your powerplant city, good minerals, then it's a major production city. You could then set rally cities for your production units to appear in. If you want to physically depict units traversing the map then you could randomly assign a city for one to appear at when it's completed, but that's probably adding too much complexity.

Quote:
Some resources can be produced more cheaply at certain cities so specialization occurs. For example a particular city might be ideally situated for power generation, so over time it will become the main generator for the entire faction. Given enough time natural strengths and weaknesses develop within a faction's support systems as it grows and shortages emerge. As one faction tries to develop a huge army the maintenance costs require it to control more and more territory, this exposes weakness as its borders grow beyond its ability to defend. It also means he is going to have cities with a lot of buildings covering a lot of area, that is going to be difficult to defend without causing a lot of damage should a city be attacked.


It'll be a tough balancing act to provide realism without tedium. The only way to tell for sure, though, is to playtest.

Quote:
Anyway, the theory is that each time you play, the order of events is different depending on how the map shapes up. The goal is to make it feel like there is thought behind the AI's actions, to give the player the


Too bad you can't create a realistically randomly generating risk-type map. Hexes always annoyed me. Smile

Quote:
ability to make strategic choices. For example, if lack of suitable land has forced a strong neighbour to consolidate power generation into one city then you might be able to exploit that. Take out that city first and all his factories shutdown so he can't reinforce himself with new units - simple. Conversely if you're the poor schmuck with no access to a decent power supply then you either need to expand your borders or make friends with someone who has a power surplus and can use something you have in excess. The foundation of diplomacy.


That could prove annoying, depending on how the game plays out. If everything is randomly generated, you could find yourself stuck in a position with truly lousy resources.

Quote:
northern border has decided to expand itself into a juicy target for the enemy (that you are now hard pushed to defend). Anyway, that is something for later I think.


You're really talking about two entirely different games, though, your strategic map and your tactical map. You're basically recreating Master of Magic/Orion and the Total War series since you have your RTS tactical battles and an RTS big map strategy. It would be very easy to have a wonderful tactical game but a miserable strategic game.

Personally, I was always interested in seeing a game that handled the big map strategy and the tactical in the same engine. In X-Com, the globe was essentially 3D. Imagine if you had something like that for a tactical/strategic game and each battle, when it flared up, made the map rotate and zoom in until you are looking at the exact area in question. If you took less tactical control of the battles, if your level of control was that of the grand general who sets the forces into motion and then awaits the results, the timescale slider would be nice. When nothing is going on you set it to advance six hours a second. When the battle is on, you set it to realtime and watch the fireworks. Smile But you're wanting it to be a hands on sort of thing so that won't do any good.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group