Caimans quest (Finished)

[Traveler]

Do you think this is a better idea than the pokemon idea?

For sure. But I think the real question is, can you pull this off?

[savage]

Do you think this is a better idea than the pokemon idea?

I think this is great idea, but may be too ambitious to start off with and maybe better as a sequel to the first game.

Also by incrementally improving the game and engine you will feel less discouraged if the list of features is too long and you cannot see the end in sight.

Best to finish a smaller game first and use the knowledge gained in that to then build the next version which will be bigger and better.

[Smotsholle]

I doubt it will really become any more difficult.

Remember the text field in the demo?
I just made myself an image, the size of the textfield.
I placed each letter on it, one by one.
I placed the image on the main "canvas"

With the robots:
I make images for each part of the robot. I plan on making a complete robot in Truespace (The same program reiner uses).
I'll render the animation with only one part visible at a time, this will result in about 8 rendered animations.
I'll simply paste the animations on top of each other to make a new spriteset ingame.

This means I indeed have to make more images (So at first this should increase the necessairy diskspace), but this will save me loads of animating time on the long run.

Example:
I have to start out with a full robot.
Later on I can expand the game with only 1 part at a time.

On the short run it will indeed cost me more time in coding,
On the long run it will save me loads of time in animating.

Think of it....
When I have 10 objects of each set (head, l-arm, r-arm, feet, back) this will mean the game has 10^5 possible combinations.
This is 100.000 different robots
And I accomplished this by only making 1 body and 50, which is only 51 parts (I'm not even talking about complete robots yet)
With the same amount of work, I would be able to make only 10 pokemon

Coding is less of a problem to me than animating. (I'm about as creative and graphically skilled as a sack of potatoes)

[savage]

Any updates?

[Smotsholle]

A little one... Only on info though...

I've found out that Truespace 3.2 is now abandonware.

I want to do everything on the full legal scale.
I'm working legal now, but for a limited period of time:
I can use the school delphi license to devellop, so that's legal for as long as I'm studying, so I want to go to open pascal when it is finished, so I can re-compile there.
Truespace 3.2 is legal, so I can use that in combination with paint to make sprites.
Nice thing about that is that everyone can use it.
Fans of the game can draw their own parts and contribute to the game in their own way. This will work as follows.

For each robot I'll put a seperate Truespace Scene online.
The skeleton (which is invisible) will be fully animated. This means fans can make their own pars in Truespace.

What to do:
- Download the skeleton of your choice and download truespace.
- Make a part in truespace.
- Connect the part to the skeleton.
- Animate the part (this will result in some bitmap images)
- Use my spritemaker program to convert these bitmaps to a single spriteset image.
- Send me the spriteset.

What do I do?
- I'll test the spriteset.
- If It is nice I'll integrate this as a new part in the next version.

[Smotsholle]

Sorry I haven't been on this forum for a while, We got new internet and it took a while...

Anyways... Here to tell you I got 3 other people to join my project.. It's become a school project which is a good thing and maybe a bad thing...

After discussing it with the other 3, we decided it should be an entirely different game based on this engine...

It will be a turn based strategy like final fantsy tactics and ogre tactics...

We're using reiners spritesets and some home made tiles. We're using tilestudio to make the tiles and other trinkets.
At the moment the engine looks better because we made better tiles now.
We added a battlefield, isn't much yet, but at least you can move the cursor around and with only a little bit of extra coding we managed to add a nice scrolling function.

Only problem we're facing is that we can't manage to get an alpha on the sprites
Any alpha above 0 gives full vision.
0 gives invisibility... Nothing in between it would seem
We're working on it though.

I'll put a demo online when we have a nice battlefield.

[K4Z]

Good to see that you're still working on this project.

When using OpenGl most things require floats. To get Alpha try something like:

glColor4f(1.0,1.0,1.0,0.5); //R,G,B,A



Any screenshots?

[Smotsholle]

I'm using the jediSDL sprite-engine, so no opengl.

I think I found the problem too.
Due to some "too quick" programming on my side I failed to notice the 8-bit color display. (DOH!)
Do you guys know what the minimal color requirement for an alpha is? (I hope 16-bit is enough).

On the comps where I'm developping 16 bits color display is enough to run the game smoothly, A higher color depth causes lag.

Btw, another little question, not as high a priority...

I use the sprite-enigine as follows:

I have a surface.
On the surface I place a background (an image)
The sprite-engine is directly linked to this background.

I face one major problem with that.
When I give a single sprite the kill-command. The image sticks to the background eventhough the sprite is gone.
It's difficult to explain, but I hope the above is clear enough. Maybe this sprite-kill-thingy has something to do with the alpha problem

[technomage]

I'm not 100% up to speed with the sprite engine in JEDI-SDL. But i don't think alpha isn't usually supported in 16 bit only 24 and 32bit (correct me if I'm wrong guys). However you can use a ColorKey to render transparent areas. I don't know the specific call but I think there is a SDL_SetColorKey function and as long as the surface has the correct flags (SDL_SRCCOLORKEY I think ) it should work.

With regards to the sprite problem , I woulnd't link the sprite engine to the background image, but to the surface you draw the back ground image onto (if that makes sense), it sounds like the sprite image is being permenantly rendered onto the back ground image, where what you actually want to to leave the a background image alone , render that onto another surface then render the sprites onto the same surface, so the sprites never get drawn on the source back ground image.

I could have missunderstood the problem. :?

[Smotsholle]

No, you perfectly understood the problem.

I managed to get the alpha working. This is making programming a lot easier and the game looks better too.

About the background problem... Still don't know how to fix it though.
Anyone here got a little basic code on which you simply paste a sprite on the background? Would save me some work

Anyways, a little info about the battle engine.
The demo version (on which I'm working) will have 6 knights. 3 of the blue team, 3 of the read team.
A single battle phase will consist of 6 phases (of which 2 active)
0a. The computer picks a unit for you to move.
0b. (with computer AI) The computer gets assigned a player to move.
--> Using the alpha-beta system the computer will determine it's next move.
0c. (Network play) The computer determines which player moves and sends this to both players.

1. The computer draws a movement grid for the active unit (all possible moves are in a darker shade (alpha layer ofcourse ))
--> You get to select a tile to move to

2. The computer shows the selected movement (unit and destination)
2c. The move is also sent to the other player in netplay.

3. The computer draws an attack grid for the active unit (which tile/unit do you wish to attack? Attacking yourself results in no attack)

4. The attack is being processed and shown.
4c. The attack is also sent to the other player in netplay.

5. Endprocessing (animation for a dying unit, checking if the battle is finished, etc...)
5c. Netplay can send check-info (in case of lag, like that'll happen)

Afterwards the game goes back to phase 0 for the next player.

Currently phase 1 and 2 are finished.
With the AI version phase 1 and 3 will be skipped of course.
With the network version phase 1 and 3 will be waiting phases if it's not your turn.

Anyways. Seeing the progress thusfar, I think I can put a demo for all 5 phases up by next week.

If you like I can post a screenshot and the current progress tomorrow.