The Shining Source

I'd like to point out that using blender would save you time, money, and resources. Plus, it'll look better.

Hi Peeps,

Everything is going well with Dark Resurrection. I have lots of experience with Cartography Shop. It's really a great program to work with, once you get used it.

Gamespace is going well too. I'm busy watching the video-tuts for skinning and rigging.
It LOOKS easy, now to do myself      

So far I have:

11 multitextured maps (for outside locations: hills, mountains, cliff, rivers, etc)
4 maps (inside locations: inn's , houses, churches, storage rooms )  
15 different pieces of furniture ( chests, barrels, tables, chairs, vases, pots, cupboards)
3 different house types
11 tree-types
3 grass-types  :roll:
2 rock formations   :roll:  
6 weed formations  :roll:
1 windmill
1 cave-entrance  :roll:

a double layered skybox (both have the same dimensions, but you can only see one of them , the other one is hidden and is used for switching textures, then the hidden skybox slowly fades in, while at the same time the visible skybox is slowly fading out.) It can be used up to 5 different transitions right now  

a multilayered (and lightmapped) sewersystem that consists of a number of modules. I'm using modules because copying/building is faster than a loading a complete level, and lightmapping it afterwards. (btw: All sewerparts are loaded at the start of the game).

I already sent Devlyn a couple of new screenies. So when he puts them up ,I'll make a link.
Very soon I'll send some other screenies of the outside world.

That's it so far , next time I will post some ideas about how the game will look and play.

New screens look excellent, especially the indoor shots.

Hi All,

It's time for a (not so) small update.

Progress so far:

18 maps ( outside-environment )

2 battlemaps ( also outside )

1 enormous lightmapped sewer-system ( 10148 poly's  )  

Waterplanes now have an animated texture (instead of moving the texture)

Also added Lavaplane, it has one texture for now, trying to add waves by moving the vertices of the plane  

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

Foliage-system:

a function where 2D-Bushes are created by placing 2 double-sided sets of 2 polygons in the form of an X
these are brushed with a masked picture of foliage.

Some maps are already filled with these 2D-Bushes and, along with numerous trees, tris-rendering goes up to 70000 (that's seventy thousand),

but after enabling AUTOFADE it drops to 10000, which is more manageable .

The bushes' positions and types are loaded from disk in batches of 200 into a
dimmed array . I've made a separate function for this, so I can call it as many times as I want.

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

Reprogrammed Camera-System:

I was fed up with the old one, basically.
The camera always got stuck in walls and\or scenery, and as a result it jumped all over the place.

Now with the new one, these problems are a thing of the past. It basically consists of a basepivot and two camerapivots which are parented to the

basepivot.

The first camerapivot is put 20 pixels in front of the basepivot, and the second one is put 20 pixels behind it
The camera looks at the first camerapivot and moves to the second.

To be honest, I don't know how I did it, but for some reason the camera does not go through walls, even with collision-detection disabled , just

like the camerapivots. Consider this as an added bonus

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

I've started programming a custom type which checks the distance between itself and the player.
If the player is within a certain distance. it will send a signal to the main process to change maps.

For this to work, each map will have its own unique ID-number.
Some maps have 2 or more exits, so, depending which exit you take, the main process needs to know where you're coming from.

I'll also need a few GLOBALS: Previous_Map , Current_Map , Next_Map , New_Map.

Main process is "stuck in a loop" until New_Map is true.
If this condition is met then Previous_Map is filled with the contents of Current_Map.
And Current_Map is filled with the contents of Next_Map.
Reset New_Map to false.

Place the player on the new map according to the information in Previous_Map.  

ad infinitum et nauseum  

The custom type may need a model of some sort, to inform the player that a certain dwelling can be entered.
I'm thinking of a simple cylinder or a cone turned upside down (think GTA)    

Also, between maps the screen turns black, so I may need a screen which informs the player that a new scene is loaded.
A generic loading screen would be nice, or a screen based on the latest information from the backbuffer to be put in
the texturebuffer. It's just an idea.

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

I've made a new bridge-model.

Picture the Golden Gate Bridge, and you're halfway there.
Replace the steel and iron with wood and rope and ... voil?  

I've used a texture that's half 0,0,0-colored and half textured.
It's used for the part that you walk on.
You can see the environment right through the cracks.  

-------------------------------------------------------------------------------------------
Right!

Now for some more ideas.

idea 1:

There will be 2 types of battles.
The first is your normal run-of-the-mill Shining Force battle. No surprises there
The second is a bit different.

Imagine this:

You're walking from one town to the next. Then you stumble across a monster.
Because these monsters are always visible, you can do one of to things
a) walk up to the monster, and if you get into a certain range, the monster will attack you
b) avoid the encounter and continue your journey.

When choosing a), you get Experience , Gold and Items that are hard to come by.
Also, clearing all monsters on the map , and entering a village or town, will respawn the monsters.
Leaving AND re-entering the map will reset all monsters.
( For those of you who have played GRANDIA on the Saturn or PS1 will know what I mean    )

Now for the tricky part: the feature DIMINISHING RETURNS , meaning: defeating the same monster over and over again, results in less EXP/Gold

each time.

QUESTION: What do you say if I re-evaluate the monsterlevels according to the highest level of the character in the group?  
This (hopefully) throws "Diminishing Returns" out the window ?

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

idea 2:

It's ALWAYS the last one!

Played Cold Fear lately? or GTA San Andreas?
In case of Cold Fear:  when standing in a corridor: you see four doors, no matter which door you choose, the first 3 doors are always closed.

In case of GTA SA: remember the showroom missions, where you have to get a car off the ship. On the ship are 3 containers. No matter which

container you choose, the first two containers are always empty.

I'm sure you get the picture by now

How about a number of situations where these conundrums crop up?
Imagine a sewer-system where you have 3 corridors....oooh........... which one shall I take ?  

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

errmm.. I have a few more, but these need to be worked on. So I'll take a rain-check ok?

Next set of screenies will come very soon.

Bye All

Personally I don't really like Diminishing Returns style of play. If you have a poorly balanced character it can make the game really hard, and also it's not a very encouraging method I guess.

Nice to hear about all the progress though .

Thanks Dev,  

I guess I'll skip the "diminishing returns" part then  (back to the drawing board  :lol:   )

And now that I have your attention....interested in more B.A.B.S.  backgrounds ?

I have Lava- and Sewers-Backgrounds at "Bargain Bin" -prices   :wink:
Just mail me if you them yes?  

And now for something completely different...Updates:

Yessiree Bob,

I have programmed the entire main loop.

First part: loading of textures, models, sounds, type initializations, declaring constants , globals , collisions

Second part: entering attract mode - where an AVI can be played - ( to be implemented in the future) when AVI is finished: go to....

Third part: Main Menu - select New Game , Load Game , Options , Credits , Quit Game

Fourth Part: Game Loop - area where a map is loaded, including textures, all sorts of types , models

The main loop is constantly waiting to initiate a "jump" to another map.
It also checks from which map you came from. (this way a map can have more than 1 entry-point

The map-checkers, as I call them, work perfectly too
These are holding the values of the maps they are linked to.

The time from jumping from one map to another is kept to a minimum. Currently it is around 1 second (no kidding..   ). In the future it may be a bit more, depending on how many models, items etc. populate the map. I'll try my best to keep this to a minimum though.

Currently working on a Fade-Function to use between maps.
A fade-off function just before leaving a map, and a fade-on function
just before entering the new map. ( thinking of using SetGamma and UpdateGamma , these should do just fine IMO )

More news as it happens ok?  

Babs is currently in a bit of a quiet state from my side, due to some rl matters I really have to handle these days, but I heartily welcome any new backgrounds!

I might mail you about them even

I still have to create a 'main loop' thing in BABS actually, but it sounds pretty spiffy!
Btw. do you still have access to the worklogs? It might be fun to store the updates there as well...?

Happy New Year Everyone!  

It's a good time for an small update.

Dark Resurrection is going very well.
There are a lot of things happening, so I'll start at the beginning.

SCREEN TEXT:
------------------
I've programmed my own text-system for Dark Res.
You see, most textdemo's are for 2D and Frontbuffer only. Others are 3D, but write the sentence in one go.

And here lies the problem:
Since the game is 3D , it requires to use the BackBuffer and the FLIP command. If I THEN show text onscreen, it flashes like h*ll.

example:

loop 01 H
loop 02  _A
loop 03 H_P
loop 04 _A_P
loop 05 H_P_Y
loop 06 _A_P_ N
loop 07 H_P_Y _E
loop 08 _A_P_ N_W
loop 09 H_P_Y _E_ Y
loop 10 _A_P_ N_W _E
loop 11 H_P_Y _E_ Y_A
loop 12 _A_P_ N_W _E_R    

Doesn't look good, now does it?
However, I've found a way around it.
I've made a custom TYPE, which is as follows:
 


Writing of the complete sentence is as follows
 


It works great.  
I can pass a text-dump to the aforementioned custom type anytime I want, and the function does the rest
( I know the variable-names are a bit large, but at least it's readable.)
Currently I'm busy expanding the code, so i can use it for text, written during cinematic battles.
Something like this

where <charactername$>  ,  <monstername$> and <int( FINAL_DAMAGE )> are variables and\or variablenames depending on who does
the attacking , who is taking damage and how much damage is done.  


GAMESTYLE:
---------------
I've finally decided on the style the game. It will be modeled after ............wait for it..............Shining Force III (no surprises there )
There are elements of nearly all SF-games in Dark Resurrection

For instance:
- The story starts in URANBATOL (the last town in the first Shining Force game)
- all the data in the game is from Shining Force II (succesfully ported from old DIV-Code)
- Some monsters-models and character-models are from Shining Force III and Shining The Holy Ark
- Some game-dynamics are from Shining Force CD
- Mechanical vehicles/monstrosities range from SF1 (ooooh..... major spoiler ) to Holy Ark ( Yes guys,... there will be flying )
- Towns / Places of interest from SFI , SFII , SFIII

PROGRAMMING:
-------------------
As I wrote earlier , Dark Resurrection was originally programmed in DIV Games Studio , a very powerful 2D computer-programming language for DOS.
Then I bought a new PC with Windows XP. Ouch,....DIV is in DOS ,.... XP does not like DOS, .......DIV does not run in XP.  
Sooo, I was forced to switch to another language. I choose you Pikachu,... erm........... I mean Blitz3D

Looking back, my decision to switch languages (albeit a forced one) looks like a good one . Every day I'm getting better at B3D ( oh really? YES really ).
And it is with great sadness to announce that DIV is now officially dead.
Yup, even the DIV-arena site, where you could download my other games, is gone the way of the dodo. And with that the hope of a DIV-windows version.

DIV is dead
Long live DIV

/* 2 minutes of silence */

Great. Now that that's out the way, let's focus on Blitz.
Making custom types is really easy, when you know how. Even making types interact with each other is now possible.
I've even made an editor for placing objects such as Chairs, Tables, Stools, Cupboards , Crates , Doors, Treasurechests, Trees, Beds. You name it, really.

All the objectdata (such as OBJECT_TYPE , OBJECT_CONTENT , OBJECT_POSITION , OBJECT_SEARCHABLE , OBJECT_ROTATION )  is written into a DAT.file
When a map is loaded, the program will open the DAT.file, read the contents , and places objects accordingly, very very fast.   0_o  
(The latest test has 500+ objects placed at a speed of 0.351 secs)

Gamedynamics-wise, you can search a cupboard  so its OBJECT_SEARCHABLE field is 1 . You can't search a bed so its OBJECT_SEARCHABLE field = 0
Now, if a cupboard object is searchable, does it have contents (let's say.. a herb) defined by its OBJECT_CONTENT field .

The word "HERB" is an earlier defined CONSTANT and it has the number 2 .
Therefore, I can write the following code

Of course you can take a herb out of the cupboard only once. So, you will have to flag it the moment it is searched (the cupboard....not the herb )
So, when you make an enormous list with info about all the objects and its -earlier mentioned- fields , what you're doing, in fact,
is cross-checking and editing a shopping-list the moment you search an object.

Every object has a number, which is always unique. When you have three identical treasurechests next to each other,
each of them is unique because each one has a different number. This number is used for cross-checking with the shopping_list.

The shopping-list is always updated, but only SAVED when you actually SAVE THE GAME.    

GRAPHICS:
-------------
I have made a lot of models lately (see PROGRAMMING: )
The Treasure-Chest and the Door are particularly noteworthy.

The TreasureChest actually consists of two parts: The first one is the actual chest, and the second one is the lid.
Now, in the game, when the player is near a chest and trying to search it, the lid moves upwards in a circular motion, and the contents wil rise slowly out of it.
(along with dozens of falling particles )

The Door is.... just a door. Except that I have programmed it to open when the player is within a certain distance.
And when the door is in an "opened-state" and the player is out of range, it will close itself. Neat huh?

More moving things are: falling leaves , flying butterflies, smoke particles, chickens (honest   )

I plan to model all my towns in MAPLET.
The Uranbatol-Map is a good example. Because the first battle takes place here, and because all battles are gridbased, and because MAPLET is gridbased.

( Creating a town is very simple. You CARVE an enormous box with invisible walls, and then FILL it with boxes. Next you CARVE the "innards" of a box, and
you have the walls of a house, and then you CARVE the space from a wall where the door should be.)

A 2x2 grid-square in MAPLET is nearly the size of 1 square on the battle-grid . So it's relatively easy to scale maps/objects until they are the right size.

BTW: CameraMovement during battles is complete. Picture a Top-Down situation, and an Isometric situation. Now, my "BattleCam" sits somewhere in the middle.
The Camera points towards the cursor, and the cursor moves to the next character whose turn is up.
CameraMovement is always a bit slower than CursorMovement.
This is done on purpose, so you'll get a"rubberband effect" but the result is a very smooth CameraMovement.

CINEMATIC BATTLES:
-------------------------
This is still in the Planning-Stage.

Anyway, here goes: The idea is to "cut away" from the main battle , and then setup the cinematic battle. ( just like any SF-game )
In order for this to work, I need an array that "remembers" all the data for all characters and monsters.

The Shining Force has no more than 12 members per battle , and if you add the maximum number of monsters (around the 25 - 30 mark ),
this means an array of around 42 (=12+30) adresses . Each adress must (at least) hold the following info:

-01 Promotion
-02 Level
-03 Experience
-04 HitPoints
-05 MagicPoints
-06 HitPointsMax
-07 MagicPointsMax
-08 Attack
-09 Defence
-10 Agility
-11 Movement
-12 Weapon
-13 Ring
-14 Spell 1 Type
-15 Spell 1 Level
-16 Spell 2 Type
-17 Spell 2 Level
-18 Spell 3 Type
-19 Spell 3 Level
-20 Spell 4 Type
-21 Spell 4 Level
-22 Kills
-23 Defeat
-24 WeaponEquip
-25 RingEquip
-26 MentalStatus

That's an array of 42x26 . In theory this shouldn't be a problem (as stated earlier) blitz can shift 500 types in less than half a second.
Question is: Update the array every loop OR update only after ending a characters turn?
Well, I can only answer this question when the array is up and running. :/

In order to setup the Cinematic Battle the program needs the following info:

Who is attacking ?
Who is attacked  ?
Where is the battle taking place?

I'm thinking that another CUSTOM TYPE is in order, like this:

Type CINEMATIC
   field ATTACK
   field DEFEND[42]
   field SETTING
end Type

The reason I've typed DEFEND[42] is because some of the spells can affect more than 1 defender. and each character/monster has its own unique number.
Other thoughts are: "where to put the camera?", "where should it go? and "where should it point to?" .

Pfffff, some small update

I promise to put up some more screenies in the very near future.

At least now you know that.................. DARK RESURRECTION....................... (insert METALLIC ECHO SOUND) is very much alive!  

Hi Folks,

Another week , another update.

Code for the itemshop is almost finished. Wahey!
You can buy & sell items and repair weapons.

To buy something:

1- select the item to buy
2- select the character
3- select the itemslot
4- place item in itemslot (provided you have enough gold, of course   )

To sell something:

1- select the character
2- select the item
3- computer asks for confirmation to actually sell it (for half the buying price )
4- item is removed from itemslot
additional: you can also sell UNequipped weapons.    


To repair a weapon

1- select the character
2- computer checks if you pointed to an empty slot OR a slot where an item is placed OR a slot where a weapon was placed
3- computer then checks if weapon is mithril-based or not
4- computer then checks is weapon needs repairing
5- computer will ask player if he/she wants to repair it, in case it's nearly broken
6- computer checks if player has enough gold to pay for repairs

Because there are a lot of weapons that are mithril-based, and therefore susceptible to damage, and each weapon has a different repair-cost, I've  decided to add them all up and divide them by the number of mithril-weapons. This (roughly) translates to one-third of the buying-price.

When the game-development is at the stage of beta-testing , then I can always change this.

One more bit of information, I finally got rid of ALL text-commands. These are all replaced with text-functions that perform a DRAWIMAGE-statement.

Well, that's all for now.

Bye Folks  

Hi,

I've just been going back to various websites which I used for my Final Year Project research and noticed the very VERY cool model!! I am a huge Shining series fan (I made a vague Shining Force rip-off as my project) and couldn't help looking further into what was going on.

Your project looks like it has a huge amount of potential and was wondering whether you needed an extra programmer. I know you have absolutely no idea who I am but hopefully you could have a look at some of my work at some point to see how good my 'skills' are and how committed I am to any projects I have worked on in the past. I have mainly worked with DirectX in the past. Is Blitz3D easy to learn because obviously that would be an issue if you ever considered 'recruiting' me?

Don't worry...I'm not some crazy person even though this post may appear to be completely random...

Hi Mr Twiggles,

Blitz is easy to learn. You can download the demo from www.blitzbasic.com and see for yourself
There are quite a few code-samples to learn from.  

And you know what they say: Two heads are better than one    

I was wondering how good you are with Pathfinding-AI and Group-AI, because that's what I'm working on right now,
and it really takes an insane amount of time to understand the subject.

I'm interested in looking at some of your work. If you want, you can e-mail it to sodalee [COUGH] AT DSO.[COUGH] denhaag. [COUGH] nl

( delete the [COUGH] , and switch AT for a @   ) , or post a screenie

Sooo... if you're still interested, why not give Blitz a whirl , see how it turns out , and post a reply in this thread . Take your time, I'm not going anywhere

So is there any recent news on the status of this project of late?

 

Good question indeed

Hi everyone,

Dark Resurrection development is going a bit slow at the moment.
In my vacation I had enough time to brush up my knowledge of a number of programs:

1: ExGen - an explosion generator that works with animation strips. I now finally know what a deflector and an attractor means.
2: Geoscape3d - Each map now contains a built-in shadow. Very sweet
3: Gamespace - making models is now very fast. the problem was always that texturing models is an entire different kettle of fish.
But i'm happy to report that i've finally found a way to texture a model that suits me. The key is practice , practice and practice .

[start soapbox rant]

 If something doesn't work the first time , just keep at it folks.
Approach the problem from different angles , divide it in small parts , attack each part individually.
Learn from your mistakes
[end soapbox rant]  
   
4: Blitz3D

a) I am beginning to understand the wondrous world of: VERTEX MANIPULATION

b) Tests for Saving and Loading of data are going very well

c) Tests for Keyboard Input are going well too.
     I am considering joypad input, and see how that turns out.

d) Models I make in Gamespace are made up of one large collection with a number of children .
     Now, in Blitz I can load the Mesh and find all children within that Mesh , and treat each child as a separate entity, so I can manipulate it (move / turn / rotate / scale )  

e) How to work with collision detection for entities within types is my latest brain-cruncher. I've cracked it .....( the collision detection...NOT the brain   )
    Funny thing is: I don't  use collision detecton at all   . I use ENTITYPICK ( ENTITY , RANGE ) . This command returns the value of the first entity it touches ,within the specified    RANGE , I then search through the collections , and if the handle of the entity matches the returnvalue given by the entitypick command then I've found the right one.
   EASY HUH ?        
   
   Areas (related tot Gamespace AND Blitz3D) still to explore:

   Skeleton Placement ( Bones )
   Rigging
   Animation
   Exporting to B3D

f) Scott Latham offered to do the Battle-AI . I've sent him my decision flowchart and a few other things to help him.
     unfortunately Hotmail doesn't like big attachments, so i've looked into other possibilities ( websites that offer free storage for a limited amount of time )

So .... if someone has a better idea / solution ??!!!!! ( NUDGE NUDGE WINK WINK )