Fourth Age screen shots

[Omnirizon]

probably as a circle

color will represent nation, the letter will represent race.

perhaps it could be a circle drawn in another, one color representing nation, the other race, and then the letter represents if the unit is militia, heavy infantry, ect.

or it could just be one circle with two letters

there will also be the thin black outline, it helps set the shape out and can be used to show when the shape is being selected.

in time the game could perhaps move to figures, or even sprites.

[Aezeal]

yeah it seems a general outline of it's type as I proposed wouldn't be much more strain on the game..

[Omnirizon]

FA has progressed immensely in the past couple of days.

no, there's no new screenshots, this progression is under the hood...

I've completed a custom data structure for working with my data model in this game. it is a 'deepdict' data structure that can work with nested hash tables, returning values and doing comparisons no matter how deep or oddly shaped the tables are. this has not only made working with my data model much easier, i've been able to deprecate the host of odd typechecking functions that were driving me crazy. i've also managed to find ways to collapse other functions together. in all, everything is much more polymorphic now.

so you need to check if that item can be equipped?
its as simple as:
if item.fit <= unit.body

this checks that the hash table defining what body structure the item requires to fit is contained wholly within the unit's body. if anything is missing or out of place, it would false and the item would not be equipped. no matter how complex a body type or item fit someone comes up with, the interface to check for equipping is that simple, and that's what I'm shooting for. now stuff can be added almost wily-nily, and the game will handle it with grace.

also, i've made a minor adjustment to how items/units/skills are structured in the game data. everything has a unique id number, just like dominions. this way it is very easy to find the necessary data. even if things are in nested hash tables, the custom data structure can find keys no matter where they are, and since each object has a unique key, it is very easy to pull up the relevant data without being afraid of a mistake being made. of course, it requires everything have a unique id key, but I think that's a pretty reasonable requirement.

lastly, if you're wondering, items are stored at the bottom of whatever relevant hierarchy (the body fit for items, the skill tree for skills). i wanted it that way because it makes it a little easier and more parsimonious to add stuff. the deepdict data structure has functions for extracting the path to the requested item/skill so that it can be used to check for fitting or calculate skill bonuses.

[Omnirizon]

the new screen shots show the working unit generator and selecter.

it randomly generates attributes based upon values provided in each unit. the higher the value for a given attribute, the more the random selecter will favor that attribute. right now, i'm leaning towards having character creation use this too. in fact, waht you see in these screens is character creation using this. i wanted PC and NPCs to be generated the same and have the same mechanics. also, it pretty typical for rogues to use random attribute generation. here at least the randomness is controled

oh also a primitive map position generator is working. in fact, those circle's positions on that surface are being generated using a position generator. its simply been given a 'block formation' algorithm.

lastly, that green surface is built from tiles, i have a basic tiling function working. in the early stages of this game, maps can be built by tiling the entire map with a given tile, and then randomly placing some feature tiles. later on some more complex tiling algorithms can be used.

i will begin working on actual game play soon now

[Omnirizon]

i've finished reforging FA...

it now has a well defined pattern, with good structure and inheritance flow. i dare say its ready to be hacked upon if anyone else here feels like giving it a go.

i've attached the new source code, but i don't have a README written for it that describes how it is put together and should develop.

i also have a working binary. however it is about 60MB and cant really be included as an attachment i dont think
i'll be working on whittling that size down. actually most of it is unused images (stuff in original Gimp format, fonts, and other stuff like that). a lot of it is also the entire python/pygame and other libraries i've imported into the game. some stuff with can be dropped and replaced, or simply added more discretely.


next up is AI...


EDIT: nvm, once packed its only 21.something. i think i can include it. but if not i'll get its size down a bit and attach it next update. it's basically just a scolling screen and some colord dots right now anyway

[Endoperez]

It seems like you're progressing pretty fast.

Have you considered the unit format yet? If it's simple enough, you might get volunteers inputting some basic units, at least for test purposes. You might have to do national units yourself, but others could do general monsters based on Dom3 summons and such.

[Aezeal]

I'd certainly be willing to help.. even to cut down on dom3K a bit for this.. sadly I can't program.. If it can be as easy as dom modding I could easily do it.. stats etc, I could make basic sprites or whatever but that would be slow.

[Omnirizon]

endo:

this is the current unit format:

0 : {
    'id'    : 'Militia',
    'race'  : 'Human',
    'attrs' : {
	      'cog' : 1,
	      'per' : 1,
	      'mem' : 1,
	      'dex' : 2,
	      'str' : 2,
	      'con' : 2,
              'psy' : 2,
	      'cha' : 1,
	      'spi' : 1
	      },
#   'skills': [1]
    'eq'    : [0]
    },

the first number there, the thing to which the whole entry is keyed to, is the unit number. i've adopted an indexing system just like dominions.

the numbers on that attributes are NOT the value of that attribute. rather, they are a relative indication of how much the random selector will favor that attribute. thus, my using 1s and 2s would be equivalent to using 100s and 200s; ie its a ratio.

the skills and eq are index numbers. these are in seperate tables and indexed just like the units are indexed. to add skills or equipment, just add the numbers. i'm kind of torn on having set skills/equipment like this... on one hand it would be nice if they could be chosen using a weighted selection just like attributes. on the other hand contingents of troops should be able to be outfitted all the same in some situations... i havn't developed a solution to this problem yet other than having a unique entry for all different equipment/skill variations.

things like base attributes and body are derived from the race entry. the unit factory handles this automatically be referencing a race table:

'Human' : {
          'attrs' : {
		    'cog' : 3,
		    'per' : 3,
		    'mem' : 3,
		    'dex' : 3,
		    'str' : 3,
		    'con' : 3,
		    'psy' : 3,
		    'cha' : 3,
		    'spi' : 3
		    },
	   'move'  : 1,
	   'body'  : [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10],
	   'size'  : 9
	   },

here the key is a string ('human') rather than a number. I don't know why I did this but I don't expect to have tons of races, whereas tons of units is possible; therefore I think using keyword identifiers will work for races. however, to be consistent, I may begin indexing them as numbers too.

the attributes here are absolute and serve as teh base attributes to which the random selection is added. move is move (the number doesn't mean much right now, but the computations currently treat them as pixel measurements.) body is actually a listing of body parts that's right! body parts are indexed and added to unit objects like they were equipment! of course, you can't take off yhour arms... but the unit object is basically a container for several other objects including body parts, skills, equipment, ect. using this system of body part indexes has allowed me to achieve some things i wanted to do with my hieararchical body system, but in a much easier (more engineering logical) type way. size is just size. also right now the number doesn't mean much, but the computations treat it as n^2 pixels in size.

as the systems are developed for the game, the meanings for these numbers can be stabilised. because they are too relative right now, i don't think too much work should be done on adding a bunch of units in. I'd rather get some simple AI and combat working first so I can see just what effects different magnitudes of numbers will have, and standards can then begin to be set.


azeal: anything would be nice because i'm not sure how the numbers will all work yet, its too early to enter those. but it will actually be very easy to do. if you feel inspired to make a sprite, perhaps a halberdier, dragoon, arquibusier, musketeer, pikemen... whatever. maybe it can become the desktop icon for the game

actually, _some_ sprites from Dom3 are perfectly applicable to this setting; swords, pikes, and flails were all common weaponry in this period. however, i wasn't planning on using them since they are proprietary and I'm not counting on Illwinter ok'ing their use.

[Omnirizon]

AI is added!
i've pasted the new OP here for reference and an excuse to bump my own thread
__________________________________________________ ___
https://sourceforge.net/projects/fourthage/

FA-0.0.1a : The Storm of Progress
FA-0.0.2a : The Angel of Change
FA-0.0.3a : The Master Arriveth

I've decided to do a naming scheme for FA releases. early on, there's lots of releases, so these could get out of hand. I'll just name them for stuff that happened in the code or was added.

This newest update fixes some sillyness in the sprite movement system, and finally adds all the build methods to the unit factory (however, all the objects built are not really used yet, but they're there and all piled into the unit, which is basically a box of body parts and items as far as the code cares!)

big thing added........ is AI!
the master arriveth. there is now a 'master' class that oversees the creation and control of all computer controlled sprites. it uses mostly generator objects since it is operating constantly as the game is being run (this allows the methods for generation of units and their AI commands to be added as objects held by other objects, and to 'freeze' whenever they are finished with current commands, but to continually be checking for a need to generate another command).

the AI is very simple right now, it only moves the unit to the closes other unit. the big thing is the setup of a way to insert it: with the AI generator objects and a global AI update method. it will be very easy now to add new AIs, play with AI, and test it out. what is really needed is a way for determining what _kind_ of AI each unit should follow. at the moment it is simply hardcoded into the unit instantiation. another possiblity is to have it be part of the unit builds, or perhaps a unit generator attribute (so that all units that generator generates have the same AI, this is actually how nationality works right now).

the new source code is at sourceforge. i won't be adding an .app or .exe until I have the combat basics in place and a wizard mode, then people can test out combat while generating data to use to fine tune it