Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Show Posts

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 - Martijn dh

Pages: 1 ... 61 62 [63] 64 65 ... 77
1241
Project of the Month: June 2010
The Midnaphone


Forum Topic | Site Page

Developer:
Goodnight

Language: Game Maker 7.0 pro
First Posted: June 2nd, 2010
Last Update: June 16th, 2010


Interview:

1. What made you start this project?

Just being me, I guess. The Midnaphone is a combination of lots of things I enjoy. Silly game-toys, sound production, making little apps with no real purpose other than a programming exercise to impress people with... that's about all it is. I think the idea came to me when I was recording Midna's voices for my .wav collection and wondering what people might use them for.



2. Who do you see using this program and how?

Honestly I don't expect it to be very popular. Even if I had made it 3 years earlier when Twilight Princess was still fairly new, it's kind of a useless application. I posted it on a forum dedicated to all things Midna and everyone seemed to love it, but still, there weren't many responses and people mostly used it as an annoyance tool, or just because it "sounds cute".

The Midnaphone could easily be converted into an engine that others could use in their own fan-games, just for the speech aspect. I might even be able to support custom sounds. If there's enough interest in that idea then I'd gladly make it happen.



3. How long did the project take for you, with the graphics, sounds and coding?

It's hard to say exactly, because there were things going on in my life that caused some major delays in the project. I can tell you the coding took the least time, probably only a couple days to learn the basics of the .wav format and get my loops working to read/write files, then a few more days to program the interface. That's right, the interface took longer than the file-creation code. There was a long break in between writing those two portions but I'm guessing it would have taken about 10 casual days from start to finish.

The sounds don't really count toward the total time because I already had all of them before starting, and the graphics were developed hand-in-hand with the interface. Paint a little, code a little, it's tireless fun.



4. The visuals look stunning. How did you decide on those and did it require you any special skills to create them?

The idea was to have a small, simple application, so I knew I wanted Midna somewhere on there as well as some menu buttons. Replicating the Wii-Remote HUD from Twilight Princess came to mind very early on, and then I figured, why not make it into a little scene straight from the game? Nearly all of the graphics were ripped from one place or another so I can't take much credit for them, besides making the necessary edits. In the end I think I may have gone a bit overboard in recreating that T.P. look for such a simple little project. In any case, it took me a while to decide whether to redraw the HUD from scratch or try to "rip" the graphics, and I tried a bit of each before coming to the conclusion that my graphical skills weren't quite good enough.

Those graphics came from playing T.P. on an emulator set to dump textures, so they were easy to grab. The problem was, all of the pieces were in different sizes. Even the transparency masks were sized differently than their corresponding buttons. I had to carefully resize and re-align everything, sometimes zooming in and touching them up by the pixel.

The game's font was dumped to 4 nice image sheets that just needed to be cut up, but I also had to measure the width of each character (and how much space should follow before the next character) and feed all those numbers into the text engine. Originally I planned to use two fonts, but doing just one took more than enough time.

I wanted a nice, foresty, bloom-lit scene for the background. That was also in mind from early on - just an idea that never got replaced with anything better. Taking screenshots from Twilight Princess was proving difficult, so I remembered the Hyrule Field overlook from the official Twilight Princess website. Just used a Flash decompiler, realigned and cropped it a bit, and voilà.

Midna's animations also came from that Flash site. Unfortunately she was a motion-JPEG that dumped as individual frames, so I ended up with a very compressed look with none of the actual filesize reduction. Just for her floating, I used a only a third of her original animation (a portion that looped as perfectly as possible - you can still see a slight jump in her hair and hands at one point) and then thinned out the number of frames to another third. Then a bit of smoothing and dithering to help clear up the compression artifacts, topped off with some moving/stretching/vanishing effects done in realtime by Game Maker. So she's only got a ninth of her original animation and it still looks pretty good. That's the kind of size/quality trade-off I think you need to experiment with as an amateur developer.



5. Was it a lot of work to collect all the needed sound effects?

Yes and no. The recording was easy because I connected my Wii's audio cables right into my PC, so it was quick and nearly perfect-sounding. And I found a couple places in Twilight Princess where Midna speaks without any music or background noise, so I just talked to her over and over, recording everything. Cutting and splicing sounds, I'm experienced with. The difficult part was having to make LOTS of recordings to make sure I got every voice sample, especially since the text-box sound effects overlapped with some of the voices.



5. If people like the sounds and wish to use them themselves, where could they find them?

You know the answer to this. I know you know it. So thanks for the cheap plug! My alter ago HelpTheWretched has a collection at http://noproblo.dayjo.org/ZeldaSounds/ with over 4,500 sounds and growing. Go nuts with 'em.



6. Seeing as how you are one of few creators to finish a project completely, is there any advise you can give people just starting?

One thing I can never stress enough: be realistic about your own abilities. If you've got an itch to start a game project, do you really know how to do the things you want to do? If not, do you at least have knowledge of your design tools to be able to figure it out? I don't mean that to be discouraging, but the history of aborted Legend of Zelda projects speaks for its self.

If you're a relative beginner at programming, I think you'll be much more likely to complete something - and improve your skills in the process - by thinking up a simpler mini-game or spin-off project. It may not be grandiose in the end but I think that if you have a solid idea that seems fun and feasible, you'll even get more people interested and appreciating what you're doing.



7. Are there any new projects you are working on currently?

Nope, only old projects that I'm not working on. But knowing me, the next thing I design will probably be something like a pinball layout, or an AMV, or a board game. Who knows? Not I.

Anyone who's been around ZFGC a long time knows I've dropped a lot of examples and engines on the old forums, but I haven't been very involved since the latest move and haven't re-submitted them to the new database. Some of them have become really popular, like the Link Movement script - It's embedded in so many game engines that it wouldn't be fair to redesign it now - and a bunch of the others barely got used by anyone. Maybe I should get my stuff together and repackage those things, what do you think?

I also had a Zelda fan-game demo that I released about 4 years ago and haven't work on ever since. Go to http://noproblo.dayjo.org/ZTS/ if you want to give it a try. I don't feel bad about "giving up" on that project because what's there is a fully-playable game (minus some of the levels and characters I had planned), and also something out of the ordinary and pretty fun to play with a friend. To be honest that's more than most demos ever accomplish, so I was content to put it away until there was a push of interest to get me working on it again, but that never really happened. Even though the response was great, I guess there wasn't much "market" for a 2-player-only game. But if people still try it out and enjoy it for what it is, I'll be happy with that!

1242
Recruitment / Re: A mentor?
« on: July 21, 2010, 12:31:06 pm »
Ooh, then I misunderstood. It's common for people to just ask others to do everything for them so it was easy to read your earlier comment as such.

Sure, since you asked nicely. Feel free to send me a question here and there. There are better programmers on here though, so I still suggest a topic for the really complex stuff.

1243
Discussion / Re: What makes a good Zelda game?
« on: July 21, 2010, 07:34:11 am »
Humans are curious with a craving for collecting and achiement.
What makes the Zelda concept so great is the exploration, the many rewards (with items to collect, story advancement and even more exploration opened up) and overcoming all odds (with rescueing the princess, destroying evil and saving the world).

Solid concept.

1244
Recruitment / Re: A mentor?
« on: July 21, 2010, 07:19:12 am »
Just post many many threads as opposed to many many PM's. Everybody is willing to help a little but nobody will help you do it all. You'll be hardpressed to find one single person to fix every problem you come across. Why should someone else spend time on it if you yourself are not going to? (since you mentioned you're actually trying to avoid learning how to code).

I'm not trying to be mean here. Just trying to expain how to get people to help you.

1245
Coding / Re: Feature List
« on: July 21, 2010, 06:48:37 am »
Wow, that's going to be a lot of work. It's probably best to cut this one up in subsections. I've already build this twice in my game. Once to just get it working and I'm now redoing it to use less objects and make it more uniform with other actions, but I'll spare you all of that. It's not hard to build, but it is a lot of things to consider which is why I'm posting.


Original method.
Once you press the action button next to an object you can pick up you create an new object which I'll call obj_Container for now.

Copy all the needed variables over to it: sprite, weight (to determine damage dealt), items held, sound when destroyed, sprite when destroyed, key_index (for if you want a pot to hold a key since they should always be a one time event) and creator_id. I'll explain that last one a little further. You'll want pots/bushes/rocks/etc to respawn after 3 or so rooms so I place creator objects in my rooms instead of actual pots. If you are about to enter a room the game removes all currently present pots and uses all the creation objects to create some new ones. Now then. You want your carried object to hold the id of the creation object (or something similar) so that you can give feedback to the creation point once an object is created. If a pot containers a key or red rupee then you don't want that to repeat (while in the area) for people to come back to a pot for infinite keys/money.

Next you create an object for the objects shadow. It's instance_id can be stored in obj_Container. If Link picks up large objects then you'll expect a larger shadow. Place it at the same depth as Link's shadow. While picking up and throwing the positioning of the shadow needs to be placed manually. In all other events you can just place it at the same position as Link's shadow. Assuming both shadows have an centered offset or are images within the same sprite. The shadow needs to be repositioned at each step to follow the movements of obj_Container.

The position of the carried object needs to be manually placed above link during all of the actions it is involved. That would be: Pick up, throwing, walking, running, ledge jumping and crashing against walls. That needs to be done frame by frame for most of those. You can either make copies of the scripts for those actions and redo them with a carried object or (and this is what I did) have the scripts handle both normal actions and the actions with the carried object. Also keep in mind that you want to change the shadows a little in size during ledge jumping and wall crashing. So that means the container shadows as well.

If Link gets hurt while carrying an object the object breaks. I'm not sure if this also happens in MC, but I'll just mention it all the same. Once this happens you probably don't want there to be items. That would be a depth nightmare. In alttp a large rock also used multiple sprites when destroyed. I'm not sure about MC but that is also something to consider.

Once you throw the obj_Container that object should be separated from Link entirely. Which is why I already mentioned saving variables to obj_Container instead of Link's master control tile. It is possible to pick up an container and stand in front of another. Throw you're first objects and immediately pick up the second. You could potentially get a wrong item/sound/sprite/damage dealt for the one you just threw away. If you really do want to store the used variables in an master control object then I suggest using two sets of variables. Once obj_Container is destroyed it clears it's used variables which was either the first or second set. If an object is picked up then it uses the first set if no other obj_Container exists and the set's variables are cleared. And otherwise the second set.

Once throwing your obj_Container you'll want to destroy it at four moments. 1. obj_Container hits the ground by making it to the end of the script. 2. obj_Container hit's an solid object you can not throw over. 3. You hit an solid object you can throw over but you're obj_Container is almost near the ground so it's expected to be destroyed. 4. You hit an enemy. Again, you'll probably want to consider throwing over an enemy. Do not do this based solely on the height above ground for your obj_Container. Consider throwing to a rat and a large enemy/boss. It's clear that you'd get weird situations. Unlike with solids you can throw over since you've already established you can throw over them giving them a somewhat similar height. The way I'm solving this issue right now is to also use the attached shadow. If abs(enemy.y - shadow.y) is equal or less then [insert you're own preference here] then the enemy collides with obj_Container.


I hope some of this helps, though I'm probably forgetting stuff.
You might also want to handicap walking and running etc based on the weight of the carried but I'm not sure if that was done in MC or if you want that in.

1246
(Bi?)weekly update:
+ The character will sweat if he tries to run around with a heavy container above his head.
+ Grouped most earlier container related objects into one creation object and one container.
+ Both walking and running with a heavy container above your head results in a (slight) decrease in speed.
+ Replaced the character’s shadow object.
+ Redid getting hurt while carrying a container
+ Fixed glitch while stabbing walls
+ Fixed glitch for grabbing a round container while moving
+ The pick up sequence has been fully redone.
+ If shadows (character / item / container / enemy) are in contact with water and on the same depth_scale then the shadow turns from black to blue

Sorry about missing out last weekend. I've been really busy. The same goes for this week aswell actually, but at least I got some more work done.

1247
Audio / Re: [Request] Sound for breaking a crate (alttp style)
« on: July 12, 2010, 06:11:57 pm »
Right, why didn't I think of that? "Box". I guess I too miss some translations sometimes.  :-\
Thanks Niek. The OoT en MM sounds didn't fit, but there was a TP sound effect under the same name that did, so I can continue.

Darklight also thanks of course.

1248
Audio / [Request] Sound for breaking a crate (alttp style)
« on: July 11, 2010, 09:00:03 am »
Hello all,

It's been a while since I made any requests but I've got another one. This time I'm looking for a soundeffect I can use for breaking crates/barrels. HelpTheWretched does not seem to have those effects up on his site, so I'd like to ask you guys if you know of any other places where I might find it.

1249
Graphics / Re: MC Mice/Rats
« on: July 11, 2010, 08:19:10 am »
Here you go.

1250
Entertainment / Re: Blizzard's RealID
« on: July 07, 2010, 09:24:48 pm »
Let's just hope you're not too well known and/or ashamed of your account. If you cannot hide your name from your wife/husband/etc, boss, pedophiles, strangers, scamartists or anyone then that is a loss. Period. You are losing anonymity and choice so it's no wonder people are not pleased.

1251
Graphics / Re: MC Mice/Rats
« on: July 05, 2010, 05:43:44 pm »
You know, there are also sprites off that rat standing on it's highnlegs.
Want me to see if I can find them for you.

1252
Weekly update:
+ You can now jump off a ledge while facing a direction other then your jumping direction. (I know, nostalgia beat logic)
+ Walking on stairs now has a slightly different animation speed then walking normally.
+ Ledge jumping has now been fully recoded for the new character set-up
+ Landing in water after a ledge jump now results in splashing water.
+ Ledgejumping is now possible over extended distances.
+ Getting rupees / arrows / bombs from chests no longer generates a pop-up text.
+ When getting something from a small chest the player no longer raises his hands. And the item's location is based on the chest instead of the player. This should make things more like the original and should make the action more streamlined.
+ Getting an item from a chest has now been fully redone / moved too the character control object.
+ Grouped together the chest objects into a single new object.
+ The text you see when you enter a new area has been improved (I had been working on it
before for glitches on specific computers but the complexity is no longer needed anymore).

1253
Coding / Re: [June 2010] Stable Releases: Minish Cap Style engine
« on: June 29, 2010, 04:56:08 pm »
Never played MC so I wouldn't know. XD

1254
Updates / Re: Nominations - June 2010
« on: June 29, 2010, 04:53:18 pm »
Yeah, I know. 4Sword, if you read this. I volunteer to help out in this section.

Just seems like it'll die away if nobody does anything. I still think this is a nice incentive for people to work hard on there projects. And if there are just crap projects out during a month with very little progress then that's okay too. Doesn't mean it should be skipped. I'll optimistic here and say such a project should also be able to become PotM. To motivate the creator and to get other people to make sure the next month will be beter XD.

1255
Coding / Re: [June 2010] Stable Releases: Minish Cap Style engine
« on: June 29, 2010, 02:27:20 pm »
Tried out the demo and it looks really solid.

The things I noticed:
- Moving from land to ice (by a single tap of the movement button) already has Link sliding over the ice the maximum distance. When I move from ice to land I come to a deadstop, but I'm believe that was per design. The first one doesn't feel quite finished yet.
- When I fall into a hole I'm respawned at the last known location I was walking on normal ground. Rolling and ice don't count. It's not a real problem or anything, but it you could potentially get some ugly situations in an icelevel. Let's say you want to make an icebridge over a large hole. One fall and you'd start at the beginning (assuming the room either had solid ground to create that respawn position or such a point is always created the instance you enter the room). I could think of other combinations where ice and rolling could potentially have the player respawn a good screen away. It's like I said no real fault or anything, but the rooms design is somewhat dependant on the engine here where you might not want it to be.

1256
Updates / Nominations - June 2010
« on: June 29, 2010, 10:47:01 am »
The month is almost over and I see no topic yet (:-\) so I'll start one.

I nominate Goodnight's MidnaPhone.
It's finished! The background shows an eye for detail. Beyond that it just generally looks really polished and professional. That, in my oppinion is something everybody should strife for.

-----------

I hope this PotM doesn't die a slow death. Making a topic once a month and moving it around to another board should only take mere minutes. Creating the summary and posting an interview can be reserved for when there was sufficient activity during the voting (like at least 5+ votes).

1257
Weekly update:
Wasn't really planning on posting anything this week cause of an exam in two days. After plenty of studying I'm unfortunately have come to the conclusion that I'm lacking the willpower to study for hours on end and I must confess I should have spend more time on it here and there in the last couple of months :-\ So I've decided to stop studying, not go to the exam and try again on the next occasion.

Anyway, since I had free time again I worked on this project again. Here are the results:
- walking animations has been done both with and without the containers above your head. Just needs some little tweaks based on container weight some other time.
- jumping of a ledge now has the character facing the direction he is about to jump in. I know this is unlike the original or my previous demo but with the new character setup this is easier.And I feel it makes more sense.
- I decided to skip working on trees, enemies, chests and swords to pick up and throw for the reason of progress. (I really want to bring a demo out, but it's just seems to take longer and longer so I'm looking for things to scratch of my list). I'll work on these things at a later date.

1258
Discussion / Re: Should I drop the Retro idea and go Modern/Next-Gen?
« on: June 19, 2010, 05:16:04 pm »
Why not talk about improved graphics once you have a game to improve? And you have to remember, the graphics we use will always be outdated. By the time we finish a fangame there will already be something new on the horizon from nintendo etc. There is one thing more importent than graphics anyway and that is the combination of everything else.

1259
I won't be working on the game this coming weekend. So, instead, I thought I'd try to explain a little why it is that I am taking all this time to work on the engine rather then add all kinds of new things. I also felt like writing my mind for a change XD

There are three mayor changes I'm trying to realise.

1. Implement a new damage system.

Previously all enemies did a fixed amount of damage to Link (which would diminish based on Link's tunic), a hp value and variables per possible hit against it (like a damage multiplier for fire or to turn arrows ineffective etc). This was the earlier situation.

Now the enemies are build of three prime components: Creator, Control, Sprite (with death sprite and shadow as support). These main objects are uniform for all enemies. When the enemy sprite and hero sprite connect the hero gets hurt, but no longer by a set amount of damage. Damage from the enemy to the hero is set in classes. A class holds a value of damage per tunic and a distance the hero gets pushed back. The enemy only stores the index to the damageclass for this. Special damage features (like fire/ice/stone/lightning/stun) will be dealt with through an additional variable. All of this has been been programmed a while back, except for the special damage. There are now enemies/sources to deal special damage yet, so there is no need to build already.

The character structure also needed to be redone. I'm in the middle of that right now. There is a control tile and there is the sprite. Sprites work with a parent tree. There is an object for sprites "attached" to the control tile and sprites with unattached locations. Under these is an object for the body and shield because they have unique features. The way the character hurts an enemy is if a character sprite collides with an enemy's. If the character has character sprites has it's variable turn on to interact with enemy sprites then that takes precedence over the enemy hurting the hero.

All of Link's attack types are also grouped into classes. The icerod is a class with only one weapon, because an iceattack is unique. Using the first sword in a default swing and throwing a bush share a class because there damage has the same nature and the damage value is comparable. Each enemy possesses a damage variable per class. So if you hit an enemy with a boomerang then that would be damage class 1. The enemy's damage value in that class is 1 so he takes 1 damage (and is thrown back a distance also in relation to the class). And if I want the enemy stunned then, instead of a damage value like 1, I could have the enemy variable hold a value like 101. 101 could be stunning, 102 getting frozen etc.

The damage mechanic is finished. There are 20 classes in total. 9 classes are being worked on or (almost) finished. The character structure is about halfway done, but it's still a lot of work. Special status attacks are not yet in effect, but will be added sometime after the character structure is finished. All enemy stats are default, meaning all weapons deal equal damage and all enemies have equal health. Tweaking the stats will be done at a later date, but if anybody is interested in stuff like that feel free to send me a message.


2. Restructure the enemy / hero build up

As stated in point 1 and especially 3, the enemy and character structures needed to be changed. The enemies needed to become more uniform to make it more manageable to add new enemies with more ease. Enemies can now share AI segments slightly easier (like movement scripts), and can be part of an class (projectile / non-projectile). All enemies now use one single sprite which is immensely valuable because you can now manipulate those with one piece of coding. I'm talking about the flickering colorschemes you see when an enemy gets hurt. That is now for all enemies the same. Finally (almost) all enemy sprites are broken down into layers (one per color in there original sprite). In other words, I've implemented the use of colorpallets for the enemy sprites. This makes the just mentioned  possible, but also frozen or stone enemies. The before mentioned has all be finished. Who knows. I might one day even use all of this to implement my crazy idea of making the tint of the enemy dependant on the shading he is standing in etc.

The character structure needed to be changes for roughly the same reasons as the enemies. It elimated a whole lot of objects, adds more uniform coding and makes damage and sprite manipulation a whole lot easier. Not to mention adding new items/actions. The hero sprite will also be using a colorpallet. The advantage of this is obviously an easier way of changing Link's tunic, but also to let Link be frozen or turned to stone. And I can do small details like color the gloves based on the gloves you've actually collected. Finally I separated the head sprites from the body sprites to help clear overlap. Most of what is mentioned here is still being implemented. To give you an idea of the work: I've just added my 40th head and 155th body sprite, and still counting. That comes done to about 300-400 subimages of previous sprites replaced by this new method not mentioning swords and shield.


3. Restructure depth system

And finally the change I won't be finishing before the next demo, but which I'm preparing for all the same. Namely a new visual depth system. I encourage programmers to read this bit as advise, because it'll save you time in the long run if you haven't come to a similar conclusion already.

In my game currently all enemies have depth x1 or x2 (based on lower floor or upper floor). This is the simple version. So if you create two bats then one will always be drawn in front of another. I could have handled that pretty easily, but there is another problem. In my game there are statues. They have a base of 16x16 pixels and you can walk either in front or around back. Naturally you expect to stand behind it when behind and in front when you are standing in front right. Doing so in normal circumstances is also easy. However, when you give the character the ability to pick stuff up his height increases. Now comes the question of depth for the container above his head. Simple trickery won't cut it anymore. When you are standing in front you really to do need to give the container/character a depth that is lower then that of the statue. Otherwise you will get ugly depth issues. (BTW: the original also has these problems. If you hold a container below and next to some specific pillars the top of the container will be draw under the top of the pillar).

So what I plan on doing is have the depth be variable based on the y coordinate of an object's sprite's lowest border. It's simple really. Just took me a long to realise it XD There are some small issues left, like what if you objects (enemy/character/statue/etc) share an y value. In that case you first need to add priority like Character > Statue. Secondly you can use creation order.

This last point has not been programmed yet, nor will it be before the next demo. It's too much work and I really do want to show some result for a while now. I'm also afraid that means you'll see some depth issues in the next demo :-\  What I am doing however is a bridging. Each character and enemy can have sprite components that already have a depth relation to one another. Like a sword being in front of a shield. Previously these depths where constant, now I'm basing all depths on the control object's depth. So each control tile gets a personal range of +5 and -5 to manipulate it's personal sprites in. When I want to implement this new depth system I can manipulate all the character sprites as well as every single enemy with just a single piece of code.

-------------------

Sorry for the spelling and possible ranting. It's really late right now. I hope someone amongst you has found it interesting enough to read it till to the end. XD Even better would be if someone found it usefull.

1260
Weekly update:
- Redid walking on stairs. Both with and without a container either running or walking.
- Added the rod of medu (= yellow rod) to the item menu, shuffling the existing item order somewhat to do so and implemented it's swing animation.
- I'm about 70% into redoing the walking animations (both with and without a container).
- Worked a little on the area outside of dungeon 1 (= did some concept work). Currently I'm waiting on a mountain tileset to use

Work is progressing nicely. About half of the character's actions are now redone.

Pages: 1 ... 61 62 [63] 64 65 ... 77

Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.23 seconds with 36 queries.

anything