The Shining Source

Great news Peter It's always great to read DR updates, and I look forward to seeing what you have in store for us

Good news from Dev too! I think the Shining scene will only get stronger over the next few months

I finally got around to one of the niggles that bothered me from the start.
The way all the screentext was displayed , was adjusted manually.
And boy, is that boring or what ?

So now I have rewritten the code in such a way that it will take care of it automatically.

1) you need a sentence.(of course  )
2) It counts how many words (including the length of these words) there are in that sentence.
3) Set the maximum length of the string.
4) Start with an empty string.
5) Update the empty string by copying the next letter from the sentence.
6) If the program encounters an empty space, then it will add the length of the NEXT word to the current length of the string.
7) And if the sum of the previous two lengths exceeds the maximum-length then it will
simply start a new line.

Very simple really.

I'm almost finished with a BloodBorne Model. The model itself looks nice . but the textures look a bit bland. 
And the head (or rather: Skull  ) looks a bit naff. So I searched for Skull references on the Intarweb, and I found some great examples. So, when the skeleton is complete , I'll post some screenies , ok ?

One thing that IS finished, is a carriage. When in the game, I can make a few copies of the carriage and attach them to the train.
(I made a small movie of this train a few months back.)
I'll make a few screenies of the carriage.

It's safe to say that the carriage looks very good, even if I do say so myself     

See Ya 

Great news Peter!  Keep it up.  Can't wait for more screenshots etc.  ^_^

Hi Everyone,

I've done some major stuff lately.

First off:

The event-system:

This system will take care of events that are currently running:
Each event has a unique ID-number. This way I can check if a certain event is initated or not.
It is flexible enough to do a number of things:

1) Play a sound
2) Start a scripted event (cutscenes)
3) Start NPC-related stuff
4) Change active zones (see Zone-System for more info)

There are a number of events:

1 ) Switching from Day to Night ( O rly ?)
2 ) Switching from Night to Day ( Ya rly !)
3 ) Fog
4 ) Rain
5 ) Storm (mainly storm-SOUNDS for now)
6 ) Thunder
7 ) Falling leaves from the trees
8 ) (De)Activating lightflares from lanterns
9 ) a few other ones I'm working on at the moment

Switching between Day/Night (and vice versa) will take approximately 2 to 3 minutes. So it's hardly noticable.
Until you realize: Hey , wait a minute, it's dark (!!) 

######################################################################################

The Zone-System:

Each map or dungeon is divided into a number of zones.
Each zone has a unique ID-number.

Here's how it works:
Each zone checks its location in the Gameworld and its relation to other zones nearby.
Each zone checks also its contents: trees , treasurechests , torches . Basically all NON-moving stuff.
And because these entities are non-moving, it's very easy to catalog these things and store their ID-number,
entitytype , X-Y-Z-position , X-Y-Z rotation , etc.

All this info is then put into a datafile. The program reads the file, copies the appropriate models and puts
them on the same position and turns them at the correct rotation.

Now comes the tricky part:

Please look at the picture below.



The BLUE zone is the zone where the camera is in.
This zone is related to all the surrounding GREEN zones.
The YELLOW zones are currently 'sleeping" because they are not close enough to the camera.

The camera is always connected to the player ( it moves to a position behind it -> = third person )
Thus, when the player moves, the camera moves with it. (so far so good )

Eventually, the camera will leave the current ( BLUE ) zone and move into a GREEN ZONE.
Now, this zone contains info about all the zones around it.
The camera will now activate the nearest sleeping zones and deactivate the furthest active zones.

And as long as a zone is active, it will perform a number of tasks.
(Move trees , leaves , check visibility of lanternpositions in relation to cameraposition etc.)

########################################################################################

Lanternflares:

Ooh boy. Do I have this one sussed out or what?
It's actually a lighting trick you can find in today's AAA-games.
In c++ (and pascal I think) there is a statement called PRIORITY. The Blitz-equivalent is ENTITYORDER.
If you activate this for a certain entity, you can determine it's "drawing-order"

Normally it's default position is 0 (zero). Now, when I change this into a "1" or a "-1" you can change the order.

"1" means that it is drawn FIRST, so that it appears BEHIND everything else. ( SkyBoxes are a very good example )
"-1" means that it is drawn LAST, so that it appears in FRONT of everything else. ( A good example is said lantern-flare).



The lantern on the left has its flare drawn first and looks very unimpressive.
The lantern in the middle has its flare normally , and is just plain wrong.
The lantern on the right has its flare drawn last , and looks very good.     


More news very soon,

Toodle Pip

Wicked, the difference is pretty obvious.

The other two do have some merits though, I'm guessing you're going to keep them in mind for slightly different situations?  Like maybe the one on the left for a place that is supposed to seem "darker" ?

Well, a few years ago I played Warhammer 40K on the PC. In that game I noticed that some characters did have some sort of 'aura' around their heads.

Especially the Space Marine Chaplain. Other character did have a flare for the Magic Rods. Don't know for sure if it's the same flare or perhaps only differently programmed.

I can sure use it,.. only NOT for lanterns. 
   

I've programmed an "equipment-check"... finally
It was one of the things I "forgot" to do

All you need is the name of the character who does the buying, and
the name of the weapon that the character buys. The function takes care of the rest.
There's even a check for weapons meant for the characters that did not have a promotion.
(in other words: weapons that can only be used by promoted characters.)

#####################################################################################################

Other things that are finished:
When a character levels up, he/she receives a certain number of points, distributed over:
HP , MP , AGI , ATT , DEF. The computer deals, ... and that's it.

My idea for point-distribution is the following:
 
Let the player decide how many points go to HP , MP , AGI, ATT or DEF.
As long as you are in "distribution-mode" you can change the allotted points to your heart's content.
I'll even throw in a check to make sure that all points are used , before you return to the battle-screen.   

According to a walkthrough made by Apathetic Aardvark (at GameFaqs) it seems that promoted characters receive
a bit more point than not-promoted characters. I'll take that into account.

######################################################################################################

There seems to be an annoying bug in Blitz: it looks like there's a maximum number of data-statemens you can use.
I struggled with this one for a long time.
It doesn't matter if you divide the code in numerous files.
( one file for globals , another for constants etc)

When I use a DATA-statement and then run/compile the code, it automatically opens the "OPEN BLITZ FILE" window
for no apparent reason. ...What a bummer . Luckily most of the data is already present , and this works.
If , for some reason, I still need more data, then I'll simply create a very small program to store all data in a DAT-file.
The program will read the Data and stores it into a DIM , very simple.
Now that I know where the bug is, I'll work around it    

Tally Ho, 

 BTW (here's the code for the equipment check:)

The last two weeks were used to find a respectable way for implementing a pathfinding routine for computer-enemies.

Eureka...... as Archimedes would say( except I'm not running around in the streets naked  )

Okay, it's (very) early days at the moment, but for now... a red cube is chasing a white cube, and if you click anywhere on the screen, the white cube is moving towards the mouse.

Yup, it starts out in 2D and it ends in 3D . That's because it is a reprogrammed version of the 2D A*-pathfinding-lib by Patrick Lester.

( http://www.policyalmanac.org/games/aStarTutorial.htm )

The goal is to turn the entire 2D lib into 3D, but this shouldn't be much of a problem. 

More news soon....

Kthxbye 

what methods are you using for enemy choosing?

I came up with several different options which I would then attach to each computer unit based on which method I wanted that unit to use.

-closest
-highest attack
-lowest hp
-type(and give the character type it prefers to attack, so this includes leader - also allowing skeletons to try to attack priests more often, etc.)

then you set up to 2 methods(one which has a stronger "influence" on the badguy than the other) for the unit and it will use them in order to decide which out of a bunch of enemies within its fighting range it will attack.

eg:
-type: leader
-lowest hp

so it will first look for the leader in its move/attack range and if so, attack the leader.  If not, and lets say there are 2 force members in the badguys range who are both on 10hp, it will then automatically go for the closest, and if they are both at the same range will randomly choose between them.

the closeness and random chooser is after your first two protocols have been worn out.
you can do a lot more with it, but the idea is to keep a few different routines for the AI so they aren't all reacting the same way to every situation, and secondly so that it's easy to set the battle maps up without designating an array of hate values for every unit.

Thanks Elvenfyre, 

There already were a few thoughts about which enemy to attack.
A quick look at your list made me realize that you have thought this process over far more better than me

The methods I have so far are:

1) Attack closest one
2) If leader is closest and not targeted -> make leader the target.
3) Check enemies in range for less than half HP of maximum
4) Check the position to attack enemy.
( attack from the side , rather than from the front / attack from the rear , rather than from the side )

-------------------------------------------------------------------

My 1) , 2) and 3) are on your list too. So these are definately 'in'.

-------------------------------------------------------------------

What do you think of my no. 4) ?

-------------------------------------------------------------------

I like the randomness of choosing, so that goes in as well.

-------------------------------------------------------------------

Your 'type'-attack looks quite interesting.
Is it possible to compile a list of enemies that would 'prefer' to attack certain characters ?

-------------------------------------------------------------------

It is probably a good idea to give all possible actions a certain priority and combine
them with the flow-chart I made some time ago.

*rummaging through year-old posts*

Ok.. found it.



-------------------------------------------------------------------

More news from the 'programming front':
The entire pathfinding Lib is now in 3D . HUZZAH! 

Started adding code from characterdata-arrays.

Also found some old code for smooth cameramovement. That goes in as well.

Looking back ,....the biggest hurdle was getting some good pathfinding.
Lucky for me it's now a thing of the past.  

Well.... that;s it for this time

Ta.
       

I'm sure there is some kind of list or logic you could use, Devlyn would be the one to ask, he plays a lot of the games that require that sort of thing.

However, think outside the box too:
For some quests a certain character in the force will be particularly invested and for this reason, their unit type may be picked on by the enemy.

If I remember correctly, The Sims has a system whereby each object "emits" information about which desires it will satisfy. For example, a shower would emit a "cleanliness" signal. The closer the person is to the object, the stronger the signal. At any time, a person has needs of varying levels, and will aim to move to objects which satisfy the most.

For a Shining Force game, each character could emit various bits of information, such as their health, strength and how dangerous and important they are. One idea would be to have their danger level increase every time they kill an enemy or heal an ally. As Elv said, AI controlled characters would need to have different "personalities" to prevent everyone going straight for the leader. Dark mages might hate healers, or might go towards groups of players to inflict the most damage.

The pathfinding algorithm could be tweaked slightly to give a better experience too. A* chooses the fastest route, but for a smarter challenge you might want to factor in land effects and map objects too. Enemies might take a slightly longer route to avoid archers or to seek cover in forests etc.

Hopefully that's given you a few ideas you can use

Thank you , Ty and Elvenfyre for your input. 

I've emailed Devlyn about this , and he supplied me with a small list with a number of
possibilities for attack-preference. He's on the case right now.

First, I'll start with a basic "when-near-then-attack" pattern.
When this works well , I will add more choices for random attacks.
(Probably a combination of all the ideas that were discussed previously.    )

Again,... Thanks     

Fire Emblem tends to work with rock-paper-scissors like triangles. Perhaps that may be a nice idea?

e.g. Swords win from Axes win from Lances win from Swords?

Dev, I'm pretty sure SF3 has a similar system to this. You're more likely to have critical hits and do more damage when attacking a weapon that's weak against your own. I remember it being quite a neat system, especially once big boss characters arrive and you have to pile the correct players up the field.

I can't recall how the rods, wands and ankhs work but I seem to remember ankhs being very nifty against undead creatures.