This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ACagliano
Pages: 1 ... 33 34 [35] 36 37 ... 62
511
« on: December 03, 2010, 09:30:38 am »
So this is your secret project? Will it be a remake of a previous Zelda game or a fan game? Which language are you gonna use? I am curious about how this will turn out. Good luck!
It will be entirely AXE. It will be very similar to an already made game, but unique in some ways. Yes, this was the secret project.
512
« on: December 02, 2010, 09:31:25 pm »
Here is where I post progress on the Zelda RPG:
Current Progress
Complete:
-block list complete.
-assigned hex values to block types for easy referencing in program.
Next on the roster:
-redraw the Light World and Dark World maps.
-redraw the dungeon maps
513
« on: December 02, 2010, 05:45:05 pm »
The tiles are actually 8x8.
Each screen has 9 tiles across by 7 tiles down
I'm not sure how many screens will be in the map, but I'll decide soon.
The L1 freeram area is reserved for player save data. Can we use the next best thing for this (L3)?
Here are the list of blocks. I will specify which can be walked over and which cannot.
00= tree (impassable)
01= ground (passable)
02= water (impassable)
03= solid block (impassable)
04= enemy
05= ice (ground) (passable)
06= ice (block) (impassable)
07= lava (impassable) enemies cannot cross. player can, but takes constant damage.
08= 1 heart refill (impassable)
09= 1 heart container (impassable)
0A= magic refill (impassable)
0B= forest temple entrance (don't bother with these next 13, up to boss)
0C= water temple entrance
0D= fire temple entrance
0E= death mountain entrance
0F= light world dungeon exit
10= ganon castle entrance
11= ganon castle exit to dark world
12= warp to boss
13= standard sword
14= master sword
15= wand
16= sorcerer's ring
17= mirror
18= boss (you will never encounter a boss on the same map as a 0x04h enemy, so don't bother)
19= dark world portal (impassable)
1A= zelda talk (from here on down are characters you can talk to or building entrances---impassable)
1B= sage talk
1C= old woman talk
1D= young man talk
1E= guardian talk
1F= prophet talk
20= forest guardian talk
21= water guardian talk
22= fire guardian talk
23= death mountain guard talk
24= death mountain magic warning
25= death mountain lava warning
26= dark world "toggle" hint
27= dark world magic warning
28= dark world "head to ganon's castle"
29= ganon's castle hint 1
2A= ganon's castle hint 2
2B= ganon's castle hint 3
2C= ganon's castle magic warning
2D= healing site
2E= sage house entrance
2F= family house entrance
30= zelda house entrance
31= guardian house entrance
32= prophet house entrance
33= temple of time entrance
Impassable means that the enemy cannot move through this block. Passable means it can. hope this helps.
Thanks alot for your help.
514
« on: December 02, 2010, 04:53:13 pm »
The map data hold the type of map "block" at that position. A value of 0x04h for a tile indicates that there is an enemy at that location, as opposed to some other block. The map data comes from appvar "ZMapData".
There is also a tile value of 0x18h for an endboss, but don't bother with that-I'll code the endboss differently.
515
« on: December 02, 2010, 04:40:26 pm »
No. Once you move to a screen boundary, the LCD clears and updates with the next screen.
516
« on: December 02, 2010, 12:08:12 pm »
Can anyone who is proficient with Axe lend me some help with Artificial Intelligence for a Legend of Zelda RPG. I am looking to make the enemies on screen head toward your character, unless invisibility is active, and try to collide. The routine needs to:
1. Get the number of enemies on the screen (up to 5 enemies) and return it.
2. Get the positions of each of those enemies.
3. Process movement of each enemy toward the player (either all move once per loop, or one moves at a time).
4. Update sprite display for the enemies on screen.
I can likely handle the collision detect.
Thank you in advance, and anyone who helps will be credited appropriately.
517
« on: November 25, 2010, 08:13:52 pm »
On my game:
How much would I slow down the game, if I had some Zelda music running throughout?
Or if not throughout, at least in the title screen.
518
« on: November 25, 2010, 10:53:32 am »
In an ideal world, you should be using DCS 7 anyway. It is only one of the best calculator shells ever made, if not the best.
519
« on: November 25, 2010, 09:06:16 am »
Thanks for that DJ.
PS: @ DJ; At some point, you recommended I start small. However, I seem to actually know how to code this project in its entirety, and make it a large one. I think that I will actually finish this (*checks to see if apocalypse is coming*).
However, I am bumping something from earlier: I think I will need some help with AI programming. I need enemies to move toward the player (unless invisible spell is active), while not moving through solid objects.
520
« on: November 24, 2010, 07:19:37 pm »
Can you send me an image of a world? I may be able to help you with the map.
521
« on: November 24, 2010, 06:52:45 pm »
I would go hardcore and start doing it on the floor and make it in pure asm.
I don't know asm either. That's why I'm using Axe. @ DJ. Is there any thing i should know about special ways to code things, like text or sprites, if i compile to an app?
522
« on: November 24, 2010, 06:05:06 pm »
Hints? For me or for you? Cuz, I'd need to know the title.
And as for you, what language?
523
« on: November 24, 2010, 05:58:45 pm »
And, turiq, if you keep this program in Archive and just use a shell like CalcUtil, or DSC7, then it can stay in Archive and not be an issue. srry can't read all that from my ps3 on my crappy tv, BUT to copy that data to the appvar you must have it in the app itself 1st
Yes. It will be held after the executable and copied to the appvar.
524
« on: November 24, 2010, 05:56:07 pm »
Yes. The data held in a program does not change the executable size. I'm allowed to have an assembly program being 16000 kb, just as long as the executable part is less than 8000 bytes. The data part of my program will feed data to the appvar holding map data. So, when playing in the world, the appvar holds a 6300 byte chunk of data that has the map in it. Then, I enter a dungeon. This calls a subroutine that gets the map data for that dungeon, then deletes the old appvar for map data and writes the dungeon map into it. Then, the subroutine returns to the main program. Except, now, the map being read is the dungeon, not the world. Once you clear the dungeon, a subroutine runs, and the world map is written back to the appvar and then we return to the game again.
There are two world maps held within the main program as data:
The light world- 6300 bytes (90x70 tiles)
The dark world- 6300 bytes (90x70 tiles)
There are six dungeon maps:
each will be 1575 bytes (45x35 tiles)
all of this will be saved as data within the main program, and used to dynamically change the "map data" appvar. The executable itself will be actually pretty small, if my thoughts are correct, and still work great.
What my question is is, will the size of the executable + data be too large for the calc? Should I make it an app?
A small request: Can someone out there who programs with Axe help me out with programming AI subroutines. I need enemies on the map to move toward the player and attempt to bump into him, unless the invisibility spell is active (in which case, the enemies movements are random). Once I get all the data written, I will send out what variables hold active spells, as well as what marks an enemy on the map.
525
« on: November 24, 2010, 05:34:46 pm »
The main world map is currently under development. It will be 90x70 tiles (10 screens x 10 screens, each screen 9x7 tiles) . That makes the map size 6300 kb. There will another map of equal size. Both maps, as well as the dungeon maps, will be held as data in the main program, which makes the main program:
executable size+6300 for light world+6300 for dark world+1575 per dungeon for 6 dungeons(9450)
executable+22050 data bytes.
During runtime, an external "map" appvar will be used. It will never become more than 6300 bytes large.
Will this much data be a problem? Any ideas?
Pages: 1 ... 33 34 [35] 36 37 ... 62
|
Show Posts