View Full Version : Caimans quest (Finished)

23-09-2005, 12:46 PM
First some information on why I want to start this project:
I played the game for a while on the GBA and I saw how many forums have dedicated themselves to this game.
Downside to the gameboy game is that you can only play eachother via a link cable. This means you can't play over the internet.
Since there's no PC version I plan to make my own interpretation.

What I plan on making:
-The game world (map) will be isometric, using a tile based world. So I simply stack blocks which are 64x48 pixels each.
-The main character will be an isometric sprite with a walking and jumping animation (I don't see why I should add more, maybe later)
-The world map will be divided in screens of 10x10 blocks, when you walk out of the screen, you enter the next (should save the comp a lot of calculating)
-The way of giving orders to the little critters will be the same
-The visual representation of battling will be the isometric too. You will see 2 critters battling on a 3x9 field (in case of evasion or a miss, the critter will jump sideways and get back on the center row afterwards).
-I will make up my own critters, unless lots of people like the actual pokemon in the game.
-I will make 3d models in truespace (low poly & low detail) and convert them to sprites using a home made program (in delphi).
-When the basic game is finished I will attempt to make an elaborate map editor so I can add extra episodes to the game.
-The critter sprites will be more elaborate. There will be a small spriteset for each basic attack. Advanced attacks will be made more beautiful to watch because I will add effect sprites to make them look more powerfull.

What I've done so far:
- A 10x10 field with blocks of random height (1 or 2 high)
- A walking dude which runs and jumps (keeping the block hight in account when jumping up/down or walking). He's controlled by using the arrow keys.
- A scroll function. This means that the camera always centers on the main dude. This looks funny when jumping because you see the background moving up and down then ;)

I'll add a screenshot and a demo next monday (because then I'll be near the computer with the game again)

A demo of an older version can be found here:

I'm curious about what you thik of this.
Since you seem to have lots of ideas about game making I have a few questions about this game, some advice would be nice:
- Would the ISO sprites be nicer when I draw them in a 3d program or would the cartoon style be better?
- Should I use actual pokemon or would it be more original/better to think up my own?
- Should I keep the Z-axis scroll? (not visible in the current demo) This scroll makes the screen scroll when jumping too.
- I've been thinking of making the game world simple, This means I won't add big houses and mansions.. It will be mostly trees and small huts then. This gives the natural feel. Do you agree with me on this one?
- Most important question. I told you earlier I wanted to make this game because there is no PC version with networking/internet support. Is this actually true?

23-09-2005, 03:22 PM
Hello Smotsholle,

Welcome to PGD!

I don't know the game myself, so I can't really help you there. I've tried the demo and it works pretty good. Only bug I could find is that the guy at some point jumped off the map. He did jump back, but after that didn't move again. But I suppose since you already have a newer version, that bug is probably out as well :)

As for your questions:
1) Do what you do best. If you rock with a 3D program, go that way. Otherwise use a paint program. A 3D has its advantages with animating though.
2) More original: yes. Better: depends on your creativity.
3) It could be. Its hard to judge without actually having seen it.
4) I don't know. As said earlier I don't know the game. But as a general rule of thumb I would say if its an improvement to the game(play), add it. Otherwise don't.
5) Can't say. But if there are any, would that stop you?

23-09-2005, 09:17 PM
Thanks for the suggestions....

Conclusion here:
I will go with the 3d graphics in TrueSpace (same program Reiner uses).

About the Pokemon game, allow me to explain what the game is:
In the real game you play a character. This character can start out with a creature called a pokemon, like animals there are many different kinds and each one has it's own pros and cons.
Like most rpg games these animals can level and become stronger. You can meet other NPC characters who also have there creatures. By fighting them you level.
Nice thing is the fact that you can find all creatures somewhere in the games, the strong ones being hard to find.
This means that every enemy you encounter can later on in the game become one of your own pokemon.
You play the game by collecting some of them and experimenting with them.

The global storyline is to beat 8 so-called gym leaders. They are in some way the bosses you have to beat. When you beat them you get to compete in the leage. You have to fight the 4 or 5 strongest bosses in the game there.

The strength of the game lies in the fact that the game doesn't stop when you've explored every part of the map and have defeated every enemy. You will want to try out all of the strong creatures and you want to make them stronger.

Eventually, when you've created a team of which you think is really good, you'll want to test it against other people playing this game.

Very often you will find another player is stronger. This means you have to change your tactics, catch different pokemon and try again.

You'll keep playing on until you get sick of the game, unlike many games you don't play until you've beaten the bosses.

I hope this sums the game up pretty good.
Like I said before, I'll upload the later walking demo monday.

Ps. The walking out of the screen problem has been fixed ;)

26-09-2005, 02:46 PM
As promised here are a screenshot and the latest version.



Arrow keys to walk.
ESC to exit.

I've decided to not waste time on trying to make my own characters yet. I'm not that much of a graphical artist. I'm hoping that when I have a working version, some people might want to help me do it.

In case of emergency I'll just rip the graphics from the game and make them look better using GIMP or something like it.

26-09-2005, 08:24 PM
Hi Smotsholle,
My son ( who's 8 ) and I are both Pokemon fans. He's logged about 200hours game time and knows most of them quite well and at what level they evolve etc. and also thought it would be great to have something similar on the PC with multiplayer capabilities.

We will be watching your progress with much interest.

From the outset I suggest you make the Pokemon format quite extensible so that others can create and extend the game with their own creations/mutations. Or maybe a way of mating Pokemon to create new ones.

Anyway just some thoughts.

26-09-2005, 10:16 PM
Or maybe a way of mating Pokemon to create new ones.
Just what everyone needs. Pokemon porn. Or would that be Pokeporn? :)

26-09-2005, 11:31 PM
Pokeporn... :lol:

Well you could take the 'trainning' part and mix in some actual learning AI into the mix. Not trying to push the NN &GA stuff, but I have seen this done to some extent(can't remember the program unfortunately :() and the idea was that you had a habitat of little creatures that you could breed and raise and they'd evolve and you could trade creatures with others online...

Basically you get the trill of each pokemon creature not havingthe same 'personality' each time you play, thus making each one more valuable and personalized.

The game Black and White had a great system where it would allow you to punish or reward your 'pet' to make him either good or evil depending on what he does. So if he picks up a human and eats him you can punish or reward him for doing this and he'll either do it more or less depending on how you 'teach' him.

27-09-2005, 06:40 AM
I think you may be thinking of Spore - http://spore.ea.com/, which looks quite awesome if they pull it off.

27-09-2005, 07:37 AM
Spore looks indeed impressive. Funny intro too :)

I think WILL's talking about creatures (http://www.gamewaredevelopment.co.uk/creatures_index.php).

Anyways, we're getting a bit off topic here.
Smotsholle, the thing I was wondering is why the screen is so small?
Your new demo works okay. Only bit annoying thing is the automatic jumping. Is that intentional?

28-09-2005, 09:02 AM
About the thinking up of the critters ;)
I want to create a simple demo version first.
Like I said I'm no graphics artist.
When The demo is finished I want to go to some random pokemon forums and ask for graphical help there, but that's in the future.

That also is a plan which might be added in the long run. It's not on my mind yet.

Small screen size
I want to give the game the gameboy feel. This explains the low res. Of course I will add a fullscreen option later.

The map in this demo is extremely uneven. The actual game map will be as uneven as the real pokemon game, which is mostly flat. This means you will hardly ever see the jump in action.
I've been thinking of making the jumping ability something you have to quest for, which means you can't jump at the start of the game, but in a certain part of the game, you have to go up some stairs to get further. You can't go up unless you have the jump ability for which you have to defeat a certain player or so.

The only days I work on this are monday, tuesday and wednesday (because I have a pc with internet then)
At the moment I've been able to add a NPC to the game. You can talk to him, that's all. I've also changed the map to non-random, so you can get a better view of what the game will look like.

Reiner's spriteset converter
Because the spriteengine of Jedi-SDL works with sprites from a single file, I've created a simple program which takes all of the walking sprites in certain directions and places it in a single BMP. This program adds the ability to make up to 2 colors pink. I use that to remove the shadow and create a transparent background. The source is not built up efficiently, but it works.
Should you be interested, I'll put the source online, but this program is merely functional, so not simple to handle or good looking ;)


I've added a new screenshot and the updated demo.


>>FIXED<< The zip file was damaged, attempt to re-upload tonight or monday.

I had an idea which I illustrated on my first post. It is hard to explain without a picture, so here we go.
Imagine the 2 characters being critters. They each have their own 3x3 platform. The 2 platforms are connected by a single plot of land.
I want to change the battle system. If one of the critters does a tackle attack, you can actually see the critter heading towards the other one.
The terrain allows a dodge ability too. A critter can jump into one of the 8 directions in an attempt to dodge the attack.

To be honest the pokemon gameplay is great, but the battle system looks kind of simple. This has been improved on later editions (the 3d ones).
I want to improve on the gameboy version. When a pokemon flies here, I really want it to fly. When a pokemon is poisoned, I actually want to add a little poison cloud as a transparent sprite.

The difference in battle system makes it hard to implement some attacks, so I won't implement them (constrict, wrap, or anything which results in a sprite merge).

(I gotta cut down on the post length)

30-09-2005, 07:28 AM
And here's the promised demo:

30-09-2005, 08:07 AM
Works pretty good!

I take it the muppet is just a placeholder image?

30-09-2005, 08:08 PM
Hi Smotsholle,
I don't understand why you can't/won't implement such things as constrict or wrap etc. They are usually performed by creatures who have tentacles or similar. If they don't it would be like a mental power type thing. So a sprite merge is not necessary just overlay the constrict animation over the normal one like they do in the GBA version, and lower certain stats.

Just a thought.

01-10-2005, 12:03 PM
About the chef bein a placeholder....
This goes for just about every image you see. If I get a working full demo, I hope to attract pokemon fans with some graphic skills. That way the game should just continue to get better.

About the wrap icon.... It works for most pokemon, but how will it work for a snake (reverse that word and you get ekans)?

In the real game ekans can perform a wrap and do a tackle at the same time. How would you show that in the game?

01-10-2005, 08:29 PM
I've never seen any pokemon on the GBA doing both Wrap and Tackle, can you explain how the move works or have any screenshot/movie links etc?

01-10-2005, 09:15 PM
Wrap is an attack which goes on for several turns.

The graphics in that game don't show any real animation, so that won't be of much help.

Example of the text in the game.

Ekans uses wrap.
Pikachu uses thunderbolt.
Pikachu is hurt by wrap.
Ekans uses tackle
Pikachu uses thunderbolt.
Pikachu is hurt by wrap.
Ekans uses tackle

In short. The pikachu pokemon is continuously hurt by the wrap placed by the enemy ekans. Eventhough the snake's body is wrapped around the helpless little mouse it seems to be able to do a tackle.
In this case the snake does the wrap, so if I have to see that in real life, I can hardly imagine it doing a tackle or something of the sort.
But the attack is hardly used in the game, so it won't be a problem to the poke-fans, I think.

02-10-2005, 11:53 AM
Ah I see what you mean. I never saw an Ekans in action.

I think in this version it should probably be a bit more realistic and does not have to be identical to Pokemon, also for legal reasons :). Maybe in this version of the game you could have exceptions. in the case of a snake it can do Wrap and Bite at the same time but not Wrap and Tackle. So the attacks will need some kind of rules. So certain attacks will work together while others cannot be used together. Also if a victim is wrapped ( or similar type move ) it should have it's attacked lowered as well while the wrap is applied. That sort of gameplay balancing will be necessary and I think these little tweaks will make the game much better, more strategic and more playable.

03-10-2005, 07:33 PM
The progress of the game depends on if I can get graphical artists or not.

If I can't I will just have to make up my own little critters. That shouldn't be a problem either.

03-10-2005, 08:33 PM
I think in order to hone the game play it may be best to use placeholder graphics for now. I think once you have the basic engine working you will not have any problems finding an artist to help out.

06-10-2005, 12:05 PM
I've been thinking about the whole idea.

I think I can make it so that I would have more work programming, but less work making graphics:

The idea is the following.

You get to make your own robot. You can buy a chassis about anywhere.
On that chassis you get to place up to 5 components:
- Left arm
- Right arm
- Head
- Feet
- Back item (booster pack, wings, spikes, you name it)

When battling each component levels.
As the chassis levels you can put more components on it.
You battle the same way as you would in pokemon.
When defeating a wild robot, you get a chance of getting one if it's components.

Each type of chassis is compatible with it's own set of parts. This gives you a great diversity in robots you can build.

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

06-10-2005, 01:26 PM
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?

06-10-2005, 06:57 PM
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.

07-10-2005, 06:14 AM
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.

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 :D
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)

25-10-2005, 07:14 AM
Any updates?

31-10-2005, 01:11 PM
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.

30-11-2005, 09:16 PM
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.

30-11-2005, 11:48 PM
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? :P

01-12-2005, 07:32 AM
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???

01-12-2005, 05:58 PM
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. :?

06-12-2005, 09:49 PM
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.

06-12-2005, 10:33 PM
I know this is a little late, but I think you missed an opportunity there in not finishing the Pokemon style game. There is no much like it on the PC platform.

Ah well.

Btw, the new game sound promising as well.

07-12-2005, 10:34 AM
I agree on that one, but the problem is that it's become a school project, I'm working with 3 others now and they all preferred this gamestyle.

I have been thinking of mixing the 2 genres when the project is finished.
Since I'm the head programmer I may change the rules a bit so it becomes a pokemon strategy game. Could be nice :)

But I'm focusing on the current project now :P

07-12-2005, 05:02 PM
It's a good strategy. If you can get a stable and flexible enough engine on this project, it should take you less time later to create the Pokemon style game.

08-12-2005, 07:34 AM
If the current project will be a success, I can ask players if they want to create some creature-spritesets and then I can always add them.

2 questions about SDL in general:
1. The screen consists of about 300 sprites of an average size of 64x64 pixels. In your experience... How much can the engine take on the average pc? (I'm using 20fps)
2. How do I prevent the spriteengine from drawing on the background directly? (Should I add a seperate layer? Can I make a layer invisible (As in... no background image?))

10-12-2005, 02:09 PM

This is version 0.1 of caimans quest as we decided to call it.

As you can see there are a lot of new graphics compared to the old version.
We're currently working on the battle engine.
We decided to make that as simple as possible. So no menus to add options we don't need yet.
A second reason the game should remain simple is the fact that we don't want to flood the AI.
According to the school assignment the AI has to think in as many depths as possible (recursively). It works with the alpha-beta algorithm which we still need to figure out.
Anyways, the more options each unit gets, the stupider the AI gets (not to mention calculating time the computer uses).

The game itself has high system requirements for such a simple game, probably due to lots of sprites.

Download here and let me know what you think:

12-12-2005, 09:03 PM
Works pretty good for me. Controls are a bit uneasy to work with, but I imagine that'll improve with the coming versions. Until then, a simple textfile explaining the keys might suffice.

About your questions in a earlier posts. I haven't used sdl before, but I doubt 300 images is going to be a problem for todays hardware.

06-01-2006, 01:04 PM
A whole lot of work has been done now.
I'm glad to say the battle engine is pretty much finished. I've put a demo online with the ultimates for each of the units (fighter can progress to knight, so knight is it''s ultimate).

The movement grid is perfect now, you can see where it can go and go there.
The attack grid is also perfect, but limited. You can't see the exact extent of the range, but by looking at a unit's stats, you can determine that for yourself.
I've limited the attack grid to make it easier on the AI later on.
Only the units with a red arrow over them can be attacked, notice that normal shooters (archer and ninja) cannot shoot through other units.

I've boosted the amount of recieved XP in this game, so you can see the recieved XP at the end of a match. Units can also level, but that's a next step.

A screenshot here:

The game here:

I've also managed to add a bit of the world map in the game, when you walk out of the screen, you get to the next.
The full map looks like this:

There is a problem when exiting a screen and that's the refresh.
I can explain all I want here, but just try it and try to walk through a couple of screens and you can see what I mean. You can move the rubbish by moving the mouse cursor over it... STRANGE!!

The battle phase is hidden in this game due to trees whose size a way too big, but this is how you get there.
From the start screen go bottom right, then bottom left, then bottom right 3 times and then you can see him lurking in between the 2 walls, talk to him and you can battle (It's one player now, but the AI will come at some later point).

After the battle the game just pauses, press escape at any time to quit.

BTW, any help on the refresh problem would be greatly appreciated, I've managed to fix any problem I encountered so far, but I can try as much as I want, but nothing seems to work.

13-03-2006, 06:04 PM
After a long while I'm back with some great news....

The project is nearly finished.

What we've got now:
- Refresh problem solved.
- Full world map implemented.
- about 20% of the quests implemented.
- Perfect leveling system.
- Autosave (manual save is next, piece of cake)
- Full battle system.
- Network play (will be combined with savegames on the next stage, should be easy too)
- Units join your party later on in the game.
- Change to different unit when reaching level 10

What to do next:
- Manual save
- Central server (you can look up other players there :D)
- Full game quest implementation.
- Proper game over screen.
- Proper victory screen (a little reward for the many hours of play).

When this game is finished, It should give the player at least 3 hours of gameplay.

But no more rattling on, some screenshots here:
The sheep sidequest, nicest screen in the game according to me.
Petting zoo, to show you all the critters in the game.
The world map ingame, looks a lot like the previous map screenshot.
Mushy village, a part you will reach early in the game.

I won't post the game just yet. We have decided to put the deadline for this project on this week, so by the upcoming weekend we should be finished.

13-03-2006, 10:04 PM
Good to see the project is still alive and well!
Looking forward to see the end product!

Is it going to be a freeware game?

13-03-2006, 11:30 PM
Lookin' good! ;)

I recommend shareware. If it doesn't pan out then you can always go freeware after without all the mess. Plus at a price like 5 - 10 bucks(USD) you can easily make a little bit of funding for your next project. ;)

14-03-2006, 08:13 AM
Sounds strange, but this will be freeware.

This is a school project, so shareware is not allowed.

14-03-2006, 09:46 AM
This is a school project, so shareware is not allowed.

Oh, thats interesting. University project?

I bet using licenced libraies is allowed. :) So licence the engine, give yourself a free licence for your freeware game, and make another game as shareware using the liced game engine that you created. ;)

:lol: Can't help it. I just come up with these ideas.

It does look to be shareware quality. I'd consider reusing the engine to make another game after this one is finished. Nice way to kick off an indie game company.

14-03-2006, 12:41 PM
yeah what WILL said. So then you can get back to creating that excellent Pokemon like game you started :).

14-03-2006, 02:13 PM
Just tried to download to no avail :(. It never pays to be slow in getting around to downloading something. Can you post another link?

Remember that MANY people have taken there final projects and used them to create profit after school or uni. So as Savage and Will said, this is still an option.

14-03-2006, 02:45 PM
I'm from the Netherlands so school levels work different there. I'm doing an HBO study, H stands for high, University is the top level we have here, H is probably the second highest (I'm no genius ;))

About the shareware bit....

There are some obstacles on that.
First off, the game still has some minor bugs and due to our deadline I don't know if we can fix all of them in time.

Afterwards I have to do my internship for school (I have to make an educational game for kiddies :D)

Besides this there is work and other stuff.

What I'll simply do when it is finished:
- Make a website
- Put the game online
- Add a simple forum (home made)
- Distribute the link amongst freeware sites (like gamehippo, maybe underdogs)
- See what happens.

If this turns out to be a big success, I'll continue doing bugfixing by myself whenever there is time. and.... I can always put a little donate button somewhere.

If I do want to go shareware, I can always expand the game with a map-editor which is not free. If people want more maps or if people want to make them, I can always charge them for that.

17-03-2006, 11:29 AM
I found out there's still one thing which is a terrible bug in the game..

When I create a class I create the class in memory and the object becomes a pointer to it.
If I make the object NIL the pointer is just removed (very good).
Problem is that sometimes I want to delete both the pointer and the class, but in the same event the class itself can be pointed to by another object.

If I do the following:
class := nil;
Memory can be flooded (with the AI it often will)

If I do this:
I may remove the entire class eventhough other instances still use it.

Is there a function in Delphi with which I can remove all classes which do not have pointers to it?

This can save me hundreds of lines of programming code if this is possible.

17-03-2006, 02:24 PM
When you no longer need a class, you should call the Free Method. ie MyObjectInstance.Free to free it's memory. If you don't you are bound to end up with a memory leak of sort. There is also a SysUtil function called FreeAndNil which you can use to Free and nullifiy your object.

17-03-2006, 09:29 PM
Sounds good, but sometimes I multilink to a class: example:
A unit has a class and I can call it from the main unitlist but also from a saved unitlist.

mainlist[i] := savedlist[i];

To name an example. Sometimes it comes from another list, then I don't want to free up the memory... Is there at least a way to check if a class still has a pointer to it?

18-03-2006, 09:14 AM
The only way to detect if a class is being used by something else would be to implement a reference counting system. Each time you get a pointer to the class you incrememt the reference count, each time you release the pointer you decrememt the reference, the class can only be free'd if the reference count if 0 or the app is shutting down.

I don't know if there are any automatic ways of doing this though, except using Interfaces. :?:

18-03-2006, 10:22 AM
Well, now I managed to free it up for the greater part.

I've tested the game for quite a while and no "low on virtual memory" messages from windows. I'll consider that problem fixed then ;)

Today the final bit... Entering the last chapter in the game and fusing it with the network part the other 2 people in the team are currently working on.

I hope to have a version online late in the afternoon.

18-03-2006, 02:48 PM
As Dean said, using Interfaces is the only *built in* way of reference counting.

I would suggest getting into the habit of knowing where your pointers and objects are. Even though your are not getting any "low virtual memory" messages that does not mean your are not losing memory. If you are nilling pointers and not keeping track of it, then you should maybe think of implementing things in a different way so that you are as close to 100% certain that you are not leaking memory through unfreed memory.

Gamer's won't like it if everytime your game is run, memory is lost.

27-03-2006, 10:40 AM
Finally, the school project is finished.

All that awaits is a final presentation and the approval of some of the teachers.

I've put the current version online:


One thing, don't bother doing the search game bit on the multiplayer game. We had a java server running registering anyone who joined on the server. Unfortunatelly the linux servers at school don't support internet access.

Well, Anyways, this is a raw version, so just go and test it :D. This game should be good for about 4 hours of gameplay.

It starts off a bit boring, but the game gets nicer and nicer as you porgress.

For those who want to, post any bugs here and "IF" I find the time, I'll fix some of them.
The guys doing the network part decided not to continue this project, I myself have programmed the single-player part so I can fix the bugs there.

Have fun.

27-03-2006, 10:56 AM
Upload fixed, should work now.

29-03-2006, 04:09 PM
Not to nag or anything, but I was wondering if anyone has tried the game yet, I'm curious about any bugs you may have found, so I can fix them.

29-03-2006, 04:43 PM
I actually went through it for a bit. Here is what I found before I got aggrivated and quit playing (sorry):

1) Movement of the combat cursor is cayotic at best. I was having to try extremely hard not to overshoot my target, usually mashing the keys as quickly as possiable to still have to hit the opposite direction until I got it where I wanted. This actually caused me to move at times when I wanted to attack :(.

2) Movement in the map environment was SLOW, very very SLOW compared to the attack movements. If they were both the same speed I wouldn't have noticed and I wouldn't have a problem with it :)

3) I couldn't understand what I could and couldn't walk into on the map. For example the buildings on the first screen couldn't be walked into even though they looked like they could.

4) The first "Guide" that tells you to fight his spider, it took a long period to load the combat screen (I actually thought that my PC had locked up) then it jumped into the combat screen.

On the up side:

1) The graphics are quite nice
2) Little to no flicker (only when I had alot of things running did I see a problem)
3) Lots of explinations, from what I saw just the right amount of information

Overall nice first effort, and I hope you continue on.

29-03-2006, 07:40 PM
1. Odd to see the cursor moved too fast and the battlescreen takes a lot of time to load. On the crappy pcs we developed it it was the other way around. I can fix the cursor so it only moves when you press, and not when you hold, would that be a better solution?

2. Do you mean the movement should take up half of the frames or should the scroll be disabled to increase speed?

3. What suggestion do you have with the buildings? I don't want to remove them because this would remove the town-effect. I could draw a closed door on them, but would that solve it in your opinion?

4. Don't know how to speed up the battle-load screen, though I'm still surprised it took your pc that long. Sorry, can't help on that.

BTW. We had to speed up the programming process at the end and this left a couple of things like the ones you just named. When I have time I'll see if I can fix em.

Thanks for the report.

29-03-2006, 07:47 PM
1. Odd to see the cursor moved too fast and the battlescreen takes a lot of time to load. On the crappy pcs we developed it it was the other way around. I can fix the cursor so it only moves when you press, and not when you hold, would that be a better solution?

yeah that would work better
i also found the cursor moving around too fast, when i just tapped it.
it might be the user's cursor speed rate, i know i always set it to the highest repeat possible.

29-03-2006, 08:04 PM
1. Odd to see the cursor moved too fast and the battlescreen takes a lot of time to load. On the crappy pcs we developed it it was the other way around. I can fix the cursor so it only moves when you press, and not when you hold, would that be a better solution?

2. Do you mean the movement should take up half of the frames or should the scroll be disabled to increase speed?

3. What suggestion do you have with the buildings? I don't want to remove them because this would remove the town-effect. I could draw a closed door on them, but would that solve it in your opinion?

4. Don't know how to speed up the battle-load screen, though I'm still surprised it took your pc that long. Sorry, can't help on that.

BTW. We had to speed up the programming process at the end and this left a couple of things like the ones you just named. When I have time I'll see if I can fix em.

Thanks for the report.

1) Yes, this would make much more sense and make it more controlable
2) Well fixing 1 would make 2 pretty much a mute point :)
3) Closed doors would at least make it look like you couldn't enter. When the user clicks on one you could also post a message that the door is locked.
4) Just an observation, maybe place a loading screen between them in case it takes time.

29-03-2006, 08:33 PM
Sorry,.. I had forgotten about this game after I read this post at work the other day. :oops:

Anyway I took it for a spin as well. I didn't have most of the problems aidave was running into, but I can't really say it was a smooth ride either.

Overall it worked pretty well. The graphics are alright, although the mixed 2d/3d style isn't really working for me. Could be a work in progress though.

As far as controls go, they're good too. Although I agree with aidave on this one. Selecting a square to move on to isn't always easy. I've had my share of misses too. Fortunately nothing too serious to loose the game or something (not even sure thats possible actually). An easy solution for this would be the use of the mouse.
The fact that you also need to confirm your melee action while there is no action possible gets a bit annoying after some time. Another issue is that's hard to see if you can move onto a square that's behind trees.

The combat worked okay for me. No slowdown in loading time or things like that. There were issues with AI though. Sometimes the enemy wouldn't move while it had good reason to (ie it stood only a square away to hit) The lizzard guy from the village was quite easy to kill too. I think he was able to hit me once, then he ran off. A turn later he realized there was no way to go to so he returned only to get shot to death by my archers.

Speaking of them, I would suspect they're not invincible either. I managed to get one killed, but after the battle he was back again. Seemed a bit odd.
At another point an archer got himself killed in just a single blow. He was infact the first one that got hit.
I also noticed that is impossible to shoot arrows at enemies that are on different levels. Archers next to enemies are unable to perform a melee action as well. I'd imagined they would be a ble to use a knife or something. Perhaps they'd do not as much damage as your main character, but still something.
At one time I managed to get an archers trapped in a corner by two enemies, and I really missed a skip turn option or at least a knife action.

The level with the wizzard (at least that is what I think it is) had the odd thing that one of my archers got hit by something unknown and dropped dead, while it was not the enemies turn.

The level with the red zombie ended the game for me as it kick me back to Windows. Nothing odd in the log btw
STATUS INFO : @ 21:46:51 MSG : move: IN : 4-6-6-7-213
STATUS INFO : @ 21:47:44 MSG : Terminating Application IN : Finalization

Some other minor things:
Your spelling is sometimes off (The lizzard's text for example).
I'm not entirely sure anymore but I though the mushroom guy said a needed to kill four of his kind, while I fact I had enough by killing just two.
The battles tend to get a bit repetitive and boring after a while. This is mainly due to the fact that your archers dont die so you can just use them as cannon fodder, while your main takes em out.
When after a battle the XP gets sorted out, archers and/or both your main character appears to float in mid air.

In all, it hink it could be a good game though. Keep it up!

31-03-2006, 10:22 AM
1. Movement, will be fixed asap. You just need to tap your way towards a square.
2. Mouse will not be implemented, the assignment was to give it a GBA style to it, GBA has no mouse ;)
3. Loading literally freezes the screen, so I cannot put in a loading screen or I need to load threaded, I'll see what I can do, but don't expect anything.
4. Archers have low HP on purpose. They are ranged and can easily be protected by caiman.
5. Lizard is supposed to stay there after you beat him, he just has a different text when you talk to him again.
6. The terrible AI is due to the AI-class we followed for this project, it insisted on us using the Alpha-Beta algorithm, and to be frank that's not the most suited for this kind of game.
7. Haven't noticed the pointless archer kill. Could you tell me by the map coordinates (press M ingame) where that happened?
8. Before the game quit in the zombie bit, did the game go slower?
9. I'll check the lizard spelling.
10. I'll check the triggers for the mushman bit.
11. Battles will be less repetitive later on. You will find more diversity in the battlemaps and the team of units. Everything up to the mushvillage is purely meant to be for learning.
12. The xp midair float is a known bug, the classes for them are recreated thus they get coordinates 1,1 which is the top of the screen...

Now that I know more of these bugs I'll fix them ASAP.

There is a bug #13, which gives you a joining archer twice. This bug has allready been fixed.