Zelda Modern
Started by
Beefster
, Jun 03 2010 08:55 PM
411 replies to this topic
#376
Posted 30 November 2010 - 09:26 PM
I haven't read this all the way through yet, but I guarintee that I won't even consider using this if the "default" things that have been done before don't come with scripts included. There had better be a "ton" of default stuff to choose from, or I'll see this as a step back, as there's more work to do for the same effect.
That said, if there is a sizable "cache" of default scripts, this will just about be the best thing ever.
That said, if there is a sizable "cache" of default scripts, this will just about be the best thing ever.
#377
Posted 30 November 2010 - 10:14 PM
That's the idea, absolutely. Everything should be scripted, and scripts for all the standard enemies, items, etc. would be included and loaded by default.
#378
Posted 01 December 2010 - 05:26 AM
This sounds great
man let this idea live!
#379
Posted 01 December 2010 - 04:51 PM
If I had any programming knowledge, I'd offer everything I had. Alas my skills pretty much end with Visual Basic. And pretty basic VB too. :/
Here's hoping this actually goes somewhere. As I'm currently really losing hope in ZC's survival.
Here's hoping this actually goes somewhere. As I'm currently really losing hope in ZC's survival.
#381
Posted 30 July 2011 - 11:46 AM
so... no?
#382
Posted 30 July 2011 - 12:07 PM
trudatman, please don't revive topics unless you actually have something to contribute to it. I will leave this open though, since it does pertain to something that still has yet to happen, assuming that it eventually does.
#383
Posted 30 July 2011 - 01:16 PM
I don't know if Gleeok will want to kill me for telling you guys this, but this project is actually happening--somewhat (development has tapered off since Real Life™ has started to take over in the lives of contributors).
We have a base graphics setup for manipulating sprites (tiles/combos) working--not limited to color palettes--along with interfaces for input devices such as joysticks and keyboards, and (I think) basic sound functionality.
By no means is there an editor or 'quest player' in any working state, however, we have the bare bones for the engine itself prepared. (And for those interested, we aren't using Allegro.)
We have a base graphics setup for manipulating sprites (tiles/combos) working--not limited to color palettes--along with interfaces for input devices such as joysticks and keyboards, and (I think) basic sound functionality.
By no means is there an editor or 'quest player' in any working state, however, we have the bare bones for the engine itself prepared. (And for those interested, we aren't using Allegro.)
#386
Posted 30 July 2011 - 02:23 PM
Allegro really isn't that bad, it's just outdated. It was amazing... 12 years ago. It's gotten minor updates, but nothing big, in a long, long time. Obviously or else it would work better with Vista/7.
#387
Posted 31 July 2011 - 04:44 PM
Do i understand it right that in the finished version of this you will be able to put trees without using layers if somebody already set up the trees right for you? Or you would be able to choose layers in a open-office kind of fashion by deciding on order?
#388
Posted 01 August 2011 - 01:29 PM
Wow, this sounds great!
*Doesn't know about Allegro*
Anyway, so tilesets and tiles will be able to use any amount of colors?
*Doesn't know about Allegro*
Anyway, so tilesets and tiles will be able to use any amount of colors?
#389
Posted 01 August 2011 - 02:23 PM
--not limited to color palettes--
No No NO! My biggest peeve with any DIY game creation system is THE LACK of a color-set system. Why should I have to make several color-swapped copies of a graphic when the system can do it for me?
Give us the option to have one or the other, and define our own palette sizes and the like, how many color sets, and the like. I'd rather go through the tedius process of setting up a the palette system manually than make hundreds of copies of the same graphic with color swaps.
#390
Posted 01 August 2011 - 02:35 PM
if size and memory are not factors, I don't see the issue as exclamation worthy. there certainly are good reasons for the programmer and the user to want palettes to cycle through, but I think I would like the hands-on method of producing said alternates. how else would manual switching interfere with tile use...? I'm pretty sure I'd like seeing it all as a scanned my tiles, but I can see not wanting to change each copy after any alteration, too. how much would this affect processing and overall size of files?
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users


