December 24, 2010

NPC and Factions

First of all, happy X-Mas and happy new year (in case i don't come back until next year) to all of you!

Now, back to business. I'm mostly done with the NPC and the Faction editors. They are not linked to the game's NPC generator yet, but, well, details... The most boring part (from a coding point of view) is done on that matter anyway. Same as weapons and zones, NPC will be generated from the pool of available ones in the database. Faction handling will be a bit different. The civilian and the police factions will always be selected as they are necessary for the game engine. The generic gang faction will be used to generate a given amount of gangs based on the map's size.



Here's the NPC Template Editor. It allows to define average values for their statistics and skills, their job, default inventory, and the sprite(s) that can be used for each of them. If you have (and you will) several NPC templates for the same job (or faction), one will be picked randomly. Also, note that the current skills and statistics are, for most of them, placeholders. They are still subject to changes. Names are randomly generated based on the gender.

And this is the Faction Editor. Most values in here are still placeholders, but they should be implemented at a stage or another. So you can define if a faction is legal or not (meaning if it's hunted by the police or not), if it's a police faction (meaning that it can attack people freely). You can also define its aggressiveness, defining how its members will react to threats. Power rating will be the initial amount of NPC spawned at game start for this faction. Initial Money is a placeholder, it will be used when the economic system is done. And Relations is used to determine how factions react one to another.

That's all i can show for this week's progress. We're still missing an item editor (apart from weapons) and theoretically a job editor. The first one will be implemented next. The second one, i don't know if it will make it at all. Even if it has a lot of advantages (wow, anyone can add new custom jobs and less AI related coding), it would require to implement some kind of script system and that's a whole project in itself. So, yeah, jobs will stay hardcoded for now.

I've been running some performance tests. I'll have to warn you. Compared to regular roguelikes, GRA will need a fuckload of CPU power. Display is not really an issue, on my old Athlon64 3000+ (1.8Ghz), it takes only 16ms to refresh the whole screen (not even using DirectX), but pathfinding is another matter. My current implementation of A* can take up to 50ms for a relatively complex route for a single NPC. You can blame my coding skills, but keep in mind that the code isn't  optimized yet. So, I have implemented the various safeguards I've talked about earlier. A* can only can called a few times per turn and a much simpler home-made pathfinder is called first. 
Long story short, with no AI whatsoever, and only moving from a random point to another, we can basically move 4-5 times per second. Which is acceptable, but not great. You may wonder if it will keep up when the AI is implemented. The answer is "Yes". The AI, as explained in this design article, uses very little CPU even with a bunch of NPC. The only CPU intensive part, is the pathfinder.

Well, i think I'm done here, I'll add a screenshot article to the website shortly. [edit: done]

Cheers,
SK.

No comments:

Post a Comment