0.6.5 Info


Re: compression -

Hiya, i coded some huffman compression routines a while back - but its a bit of a trade off, as while it'd take up less space on an SMC it'd also take longer to load.

seeing as a complete game should be no larger than 5mb, compression isnt top priority just yet - i'll add an "author" function in the future so that once you've finished a game you can compile it into a compressed .gig file, but for editing compression slows everything down.

Re: Characters bigger - i could support characters of any size without much work, but it'd require each character having its own graphic file on the SMC which could clutter things up alot, bare in mind screen space is of the essence with the GP32, if all the sprites were bigger you'd have to adopt a more zoomed in view giving you less field of vision, not to mention performance would be hit.

what i'll probably end up doing is a bit of both, i'll keep all the 'normal' sized entitys in one sprite-sheet like it is currently, but allow for custom sized entitys be used by having them in there own file on the SMC, i'll look into it :)
 
well, I have to say that you are second on the list of coolest people
( matkeupon wins because he let me help him and my sounds were used in the game! )
anyways
this rocks
please add chatboard support soon to the editor on the 32
honestly, if you could export to gigas from mappy, need there be a pc editor?
I just think that if you concentrated on this it would be sweet
make a diablo game solley on the 32
but the chatboard would be needed if you were to go and do conversations and such
also, bout he charecter sizes
leave them all normal, and allow a larger one for some bosses ( like large bosses small people )
please release asap as always because i cant wait to play with this some more
got a new 8 pack of AA's for gigas
made a few custom tiles to look like diablo and I hope I can get a level to work so I could see it
and finally, anything we make with this will work with all future versions?
I know the .60ones wont, but wont these with the new editor work forever

~Octavious
 
0.6.0 will work if i convert it for you, but once 0.6.5 comes out, every thing it makes will be compatible with all future versions as the file format will be completed (added space for all the un-coded features)

talking about AA's, i've gotton thru 6 of them in the last week :)
 
this needed its own box
I would like to request something for when you release the ediotr
could you release a kit to convert whatever is needed from gigas into a non-editable .fxe?
this would be so awesome if you could do this, that would tie you as no 1 coolest guy in the world
I would love to put out a diablo game, but it wont go out till this happens
thx
this would also allow me and others to put out demo modes for people to tell us what they think about them
thx and you rock again

~Octavious
 
Lethe posted on May 6 2004 at 02:44 AM said:
talking about AA's, i've gotton thru 6 of them in the last week 

buy rechargables!!!!! the 15 minutes ones
Actually, from what I've read, the slow, trickle-type chargers are better for the life of the batteries. I have 8 AAs that I keep in constant rotation, so I'm never without a fresh set.
 
Last edited by a moderator:
Octavious posted on May 6 2004 at 12:44 AM said:
this needed its own box
I would like to request something for when you release the ediotr
could you release a kit to convert whatever is needed from gigas into a non-editable .fxe?
this would be so awesome if you could do this, that would tie you as no 1 coolest guy in the world
I would love to put out a diablo game, but it wont go out till this happens
thx
this would also allow me and others to put out demo modes for people to tell us what they think about them
thx and you rock again

~Octavious
Hiya - its not that easy im afraid, in order to compile the game into the .fxe you need the gigas source code, some sort of dev kit and to convert the binary into C array data.

so its not possible just to release a program which converts it, and to be honest i dont really see the point in compiling all the time, so id only do it if somebody sent me a completed game or had a good reason (like entering the game into a comp etc).
 
Last edited by a moderator:
How about a feature to password-lock a normal file, so it could be run from Gigas, and possibly looked at from within Gigas, but not changed? That'd, I suspect, have much the same effect...

Personally, I doubt I'd use it, but if the main purpose of compiling would be to remove the ability to edit the thing for the beta testers, then there are alternatives available, methinks...
 
oo
good idea
forget the compiler than, could there be a password mode inplemented in one of the next betas
dont think we would need it in this one , 'less you have free time
and thanks for the clear answer, I understand something a guru says, dosnt happen often on the compile subject

~Octavious
 
Wow, I worked for hours last night making tiles and whatnot. I love this thing. But.. I was wondering if you can add animations for when you get hit and when you die. This would greatly expand your engine past only rpgs. The reason I ask this is my goal is to make a river city ransom like game. I think it would be fun since there are rpg elements to it and beat em up elements to it. So far I have the tiles only for one scene in..but I can reuse them to make many scenes if I need.

a few more things that I would like but arent as needed right now.
1. Item drop on death of enemy (money)
2. alternate attacks, on diff buttons.
3. terrain altitude changes. eg. ramps, slopes, ladders etc.
4. a guided route for a npc. (forced cutscenes)

Im sure I could think of more. I dont know what you had planned for implimentation into your engine. I was just throwning out what I would like to see in it. Thanks for creating this beauty.
 
Hiya,

password locks will be implemented along with the ".gig" file format, basically it'll zip up the whole game data into a single .gig file, and as it'll be encrypted to some degree so it'll be hard to crack open and find the password.

that'll be done in the final release, as i'd want to write the huffman compression in ASM so it doesn't impact loading to much.

Now for the suggestions ;)

1.) item dropping is already on the to do list

2.) alternative attacks are coded, each weapon can have a unique attack animation and settings attached to it, so your attack would change depending on the weapon, i was however planning on improving the standard attack a bit more - with a charge attack and a running attack.

3.) you cannot do multi-level terrain on a tile based engine (well, isometric you can) - you just have to give the illusion of depth using layers, you can do 'pretend' ledges like in secret of mana and zelda just by making some terrain solid etc.

4.) guided routes and cutscenes are also on my todo list

thanks for the suggestions
 
hehe, im off to bed now - but oct, if i dont release it tomorrow i'll send u a private beta if you want, need to check the new SMC routines work etc.
 
hey pirotic, can I help you with testing? Im making a river city ransom clone and I dont have much else to do after tomorrow (today I have to learn the full c++ course 1 and do all the programs, I have a feeling ill be up all night). I have some good shit in the pipes already. I started yesterday but I alteady have all the tiles done for 4+ scenes. I would have soo much more but I did all my sprites before I realized black was transparent. I had to go back and do them all over again. I vote for item equiping before talking. will you be able to change your char speed with an item..I really hope so.
 
Hiya lads, was going to release 0.6.5 today but GP32X was down for a bit so instead i rewrote the AI system from scratch, no point other than its now a little faster and easier to debug.

new demo will be out tomorrow (saturday), the demo is almost the same as before - but the engine has a fair amount of new features for everybody to use plus the file format is finalized so you can start creating without worrying about it not being compatible with future editions

regards

piro
 
Heya; just thought of something I wouldn't mind having available in a future version if possible (though I doubt 0.65). Any chance of adding an (optional) ability for a character to jump? Mainly because it could be fairly useful in doing stealth sections (which I think I fully intend to in my first one; I've got a story ready for it already :D).

Basically, I imagine it'd mean making the character move in an arc, and setting them to not collide with hotspots for the duration or some such. It'd be annoying for extra anims, but great for avoiding traps and such. Note, I'm not talking about jumping where you could jump *onto* something, since I doubt that'd work with the engine...
 
Tobriand posted on May 8 2004 at 07:05 AM said:
Heya; just thought of something I wouldn't mind having available in a future version if possible (though I doubt 0.65). Any chance of adding an (optional) ability for a character to jump? Mainly because it could be fairly useful in doing stealth sections (which I think I fully intend to in my first one; I've got a story ready for it already :D).

Basically, I imagine it'd mean making the character move in an arc, and setting them to not collide with hotspots for the duration or some such. It'd be annoying for extra anims, but great for avoiding traps and such. Note, I'm not talking about jumping where you could jump *onto* something, since I doubt that'd work with the engine...
Jumping is a possiblity, but it'd mean a whole new animation set - unless you want a zelda jump where it just uses a frame from the walking animation where the legs are apart, lol.
 
Last edited by a moderator:
:p demo should be on its way today still hopefully, been coding all day so far :D

decided to rewrite the core AI code yet again so it works out the distance's using a distance approximation i coded in ASM which means i dont have to use the math librarys (i hate using librarys).

Enemys used to sorta just go for the enemy which was nearest on one axis, which sometimes ment if an enemy was 1 pixel higher, but 500 pixels to the right.. it'd run to attack them instead of somebody who was 2 pixels higher and 2 pixels to the right, which is pretty stupid.

now they always run for the nearest guy, which is what they should of done all along.

best get this demo wrapped up and released, cya in a bit
 
Back
Top