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.

21

Coding / Re: Small PHP bug with big error.

« on: February 27, 2014, 03:38:47 pm »

First of all, why are you using ...? That should be .., if you're trying to go one directory above your current one.

Second, look at the top of your first block of code, vs. the third block. In one, you're doing "../includes/connect.php", and in the other you're just doing "../connect.php" - so in the case of the last code block, your PHP file would have to be includes/somesubdirectory/file.php in order to work.

Finally, I really suggest restructuring your code in your first block (namely, your if statements). You keep checking some of the same variables in each else if.

22

Code / Re: Just an FYI for any coders (Git issue)

« on: February 04, 2014, 06:44:42 am »

As a note, you'll have to have SSH keys set up in order to do this.

Instructions: https://help.github.com/articles/generating-ssh-keys

23

Other Projects / Re: Alundra: Record of Torla

« on: January 27, 2014, 07:06:57 pm »

His (her?) account is no longer around, as evidenced by the fact that it's a bold, black name with no information on it. Plus, the post was made in 2011.

24

Coding / Re: C++ Help

« on: January 21, 2014, 05:22:59 pm »

Ignoring all of the structural issues for a minute (we all have to start out somewhere, I suppose)...

Firstly, if you're still at the stage when programming that you have everything inside of the main() function, do not use any modifiers to the variable type on top of ints - you don't understand well enough what the purpose is, and you're gaining no benefits at all for doing so.

Second, you should be using >=, not > for your health checks -- right now, if your health is reduced to zero, you're still alive according to your program (until you go below).

Third, you can replace your "variable = variable - number" and "variable = variable + number" with "variable -= number" and "variable += number," respectively.

Fourth, if you've got values that are either 1 or 0 (and never anything else), use booleans. Type is 'bool', and the values can be either true or false.

Fifth, your health doesn't go down half the time because you've programmed it such that the AI shields half the time. If you want to see the results of this directly, add an output when the enemy uses a shield. If you don't want the enemy shielding half the time, change the code responsible for determining the AI's action -- maybe generate a random number between 1 and 5, and if it's 1 or 2 it'll shield.

Edit
------
Also, what Diminish said (I didn't catch that the first time around) about the assignment random_number -- you need to assign to it every iteration of your while loop.

25

Discussion / Re: Making Dungeons

« on: November 30, 2013, 05:12:41 pm »

The primary component of any good dungeon, not just for a Zelda game, is having engaging, interesting, fun and appropriately challenging puzzles. At its heart, Zelda is more of a puzzle game than anything else -- sure, there's monsters to fight and bosses to defeat and fish to... fish, but the primary mechanic is solving puzzles in various themed dungeons in order to get more items so you can solve more puzzles as you progress. Effective dungeon design is a practiced skill and takes a long while to master, but you can start by researching the types of puzzles used in Zelda games, paying particular attention to their strengths and weaknesses for the player's viewpoint.

The most important thing though is to keep the difficulty curve consistent - don't have some dungeons be incredibly hard, while others are pathetically simple, and definitely don't have them in that order -- players feel progression through overcoming increasingly more challenging and thoughtful puzzles in a Zelda game.

26

Coding / Re: [Java] Syntax errors?

« on: November 10, 2013, 04:42:07 pm »

Just as a note, this isn't the best way to handle movement of an entity. Separating movement commands into functions such as moveRight() and moveLeft() is a start (as it allows you to abstract between AI and the player), but directly modifying the velocity of an object (which should honestly be stored as a vector value, but I understand that the tutorial is probably trying to keep things simple) is a pretty big no-no. In this case, what if you were to attempt to add some form of a speed boost to your character? You'd ultimately end up just setting your speed back to the base value, or worse -- writing special-case code for each modification you want to implement to speed.

The simplest way is to store boolean values for different types of input (many ways to do this, let me know if you want any suggestions) and instead modify those based on your move*() methods, jumps, etc and then react to them in some form of update() method.

Also, some of your variable names don't make any sense at all -- when choosing names for variables, try to select something that tells you what the purpose of that variable is. Also, it is best to keep them scoped as close to where they're needed as possible. An example for both of these is the variable second -- it is only ever used in your update() method, so there is no reason to declare it as a member variable, and the name "second" doesn't give any indication of what it's used for. Based on what the code is doing with it, might I suggest naming it "imageBuffer," "imageGraphics" or something thereabouts? I see that you're only capturing this when you construct the image being used as a buffer (I suggest doing this in some for of initialization method, by the way), but there's no reason not to grab it each frame instead. When doing this, you aren't actually constructing a new Graphics instance, you're just capturing a reference to one that already exists, so you aren't incurring any (unreasonable) overhead.

27

Feedback / Ruby (Furigana) Support

« on: August 23, 2012, 02:08:05 pm »

Something that could help with hawthorneluke's Japanese lessons could be the addition of a BBCode for the HTML Ruby tag. While the Ruby tag isn't supported in the default installation of most browsers, it's available as extensions to most (I'm using it in Firefox right now).

This page best describes the benefits of this, if you're not sure what Furigana is: http://thejapanesepage.com/w/index.php?title=Furigana

Edit: It looks like the link to the Firefox plugin on that website is broken, but the addon can be found by going to Firefox's "Get Addons" section and searching for "Furigana" - I'm using the bottom of the three results, HTML Ruby 6.22.3

The HTML code to achieve the Furigana is:

Code: HTML

1. <ruby><rb>漢字</rb><rp>(</rp><rt>かんじ</rt><rp>)</rp></ruby>

So something akin to the following may be an appropriate BBC tag:
[ruby=わたし]私[/ruby]

[bold text]

28

Coding / Re: Some questions about HTML

« on: April 26, 2012, 03:47:18 am »

To clarify... I wasn't saying I was going to use frames, what I meant was what would happen if I wrote perfect XHTML (with no frames) but gave it the HTML4.01 Frameset DTD? (which I'm guessing would be the least strict one besides no DTD at all)  Would it display properly, since a perfect XHTML page with no frames fits all the criteria for that DTD... or do the XHTML DTDs do something different?  Do the DTDs make the page function worse as you become less strict (so XHTML Strict would always work properly, whereas HTML4 Frameset might not (assuming that the code follows all the XHTML Strict criteria))?

Doctypes only define the standard you wish to use, and (to my knowledge) have no effect on the actual rendering of the page.

Oh, and another question... what exactly is bad about using the <table> tags to do layout?  I keep seeing all these websites / people saying "Never use tables for layout!" but no one ever explains why... the few things that I've heard were:

Tables used to be the standard layout tool, but are frowned upon in modern web design because it is more efficient to use a combination of Div tags with CSS styling. The introduction of CSS has generally caused Tables to return to their originally-intended use: sorting data in a table format.

- It's only done out of laziness (which I don't see why it matters... if the page runs fine I could care less if a web page designer was lazy or not)

Like doctypes, it's more of a Standards issue, rather than function. It's become standard practice to use Divs rather than tables - most sites that currently use tables are doing so because they were designed as such for years. The current theme on this forum, for example, is still heavily table-based, as are most web forums at the moment.

- The code is harder to read / write (which I disagree with... and it doesn't need to be easy to read / write anyway.  Saying bold textitalic textunderline text is a lot easier to read and write than <span style="font-weight:bold;">bold text</span><span style="font-style:italic;">italic text</span><span style="text-decoration:underline;">underline text</span>, yet the one with the CSS is the one to use).

Actually, and have been deprecated and replaced with <strong> and (emphasis), but I do see your point. Most browsers still support the older tags, however.

>

- The table has to load in an extra element or something so it loads more slowly (this makes absolutely no sense... a single table isn't going to noticeably slow the page at all...)

Not quite sure where they were going with this. Even if that were true, it's nowhere near enough of a performance issue to have any impact.

- It's bad for accessibility (like if someone has the browser read the page to him... however, this doesn't really matter for the purposes of my page (which isn't meant to have the contents spoken) and additionally I can get the brower's speech option to work fine in a table)

There are some issues with accessibility features, such as web readers and magnification. This is mostly a User Experience issue, when you have disabled users attempting to use your website. Which, at this level, you really don't have to worry all that much about.

Does anyone have an actual reason other than personal opinion / preference as to why tables should never be used for layout?  Just wondering... my layout actually doesn't use tables but I don't understand why people say to avoid it like it's the plague.

Just about everything dealt with here is a Standards issue, rather than functional issues. People avoid it like the plague because less experienced users tend to exaggerate what they are told by more experienced users, and experienced users tend to exaggerate what they tell less-experienced users. It will be years before any of the now-deprecated functionality no longer functions, so you don't have much to worry about.

Still, if you're considering doing web development in any serious capacity, you're going to want to drop the use of tables and learn to do Div-based interfaces. Ultimately, DIVs with CSS are more capable than tables.

29

Coding / Re: Some questions about HTML

« on: April 25, 2012, 04:01:56 pm »

So anyway, I'm kind of new to HTML... well, not exactly new... I learned HTML back when it was very different... back when all tags were done in caps and closing tags on single-tag elements weren't needed and there was no CSS (example:
I learned:

Code: Text

1. <CENTER><IMG SRC="http://www.google.com/images/srpr/logo3w.png"></CENTER>

Instead of:

Code: Text

1. <img style="display:block;margin-left:auto;margin-right:auto;" src="http://www.google.com/images/srpr/logo3w.png" />

However, I've learned just about all the differences so it doesn't really matter.
I am confused about a few things though...

Actually, you were never required to use all-caps for HTML tags in the past - it was kind of a (poor) convention to help in noticing the differences between tags and content. HTML itself is actually case-insensitive.

First, what is the difference between XHTML and well marked-up HTML besides the DOCTYPE and the fact that instead of writing <html> you write <html xmlns="http://www.w3.org/1999/xhtml"> and the fact that a few HTML attributes are not included in XHTML?  Are the two compatible... I mean could I literally take my web page and change the DOCTYPE and the <html> tag and have it work as XHTML (as long as I haven't used any attributes that aren't valid in XHTML)?

XHTML is an effort to bring HTML into a more XML-like strictness to ease document parsing because properly-formatted XHTML documents can be parsed by XML parsers, whereas traditional HTML requires a unique processing engine. The xmlns attribute included in the HTML tag defines the XML namespace for the document. Simply changing the DOCTYPE wouldn't break the function of your page, but it would not necessarily parse well with an XML parser -- which is what the W3C Validator exists to show. Selecting your DOCTYPE is only a matter of opting to go with a specific standard.

Also, what really is the point of HTML when XHTML exists?  It sounds as if XHTML is better, so why should I ever use HTML?

Just varying standards. The web is kind of a mess right now, really, and it's easier to teach proper HTML before covering XHTML.

Second, I'm confused about DOCTYPEs as they didn't exist when I learned the language.  I see that there's strict, transitional, and frameset... I don't understand the purpose.  If I write code that follows the strict standards and I give it the frameset DOCTYPE then will it still run fine?  If so, what's the point in even using strict if frameset allows for strict along with other stuff?

See my above response regarding XHTML. You should never, ever use frames anymore, they're disgusting little practices that are worse (in my opinion) than scrolling marquees.

Third, there's this "validator" program at http://validator.w3.org/ ... I assume that what that does is checks the code for errors.  However it always finds a ton of errors in my code that I know are not errors at all.  In fact, giving it Google as the page to check gives 32 errors and there's no way that there could be that many as it runs fine for everyone who uses it.  It also tends to find tons of errors in my javascript scripts saying that they aren't valid HTML (but of course they aren't valid since they aren't HTML).  Should I ignore those errors... more importantly should I ignore this validator altogether?

The errors it finds (as I mentioned earlier) are related to how well your document follows your selected standard. They may not cause rendering issues (though they might across various browsers), but it's still a matter of improper formatting. Basically, the biggest thing to look for is making sure that you aren't using deprecated tags (such as <center>), leaving formatting such as that to CSS documents (in that specific case, align: center), and making sure that you're closing standalone tags (such as
 and <img />).

Lastly, I'm curious... what would an older browser do when it comes across a tag that didn't exist at the time?  Will it ignore the tag or will it print the tag to the page as if it was text?

Depends on the browser. Usually, it'll simply ignore them. Still, most of what you'll use will be recognized by any semi-modern browser -- I think the oldest you'll ever have to deal with is Internet Explorer 6, and even the U.S. military has moved on to IE7 and newer. (Take it from my experience, that is a huge deal. <_<)

30

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 10, 2012, 08:47:25 pm »

Guess it looks a little awkward (and a bit stiff) as an animation. I'm gonna stick with Mitsu's art throughout the experiment - but if you're interested and the project plays well enough to turn into a full project, I'd love to work with you on some Wind Waker-esque storyboard portions.

31

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 10, 2012, 05:59:39 pm »

Dude, Sinkin, that's ridiculously awesome.

32

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 10, 2012, 01:52:15 pm »

Yea, I should've realized the problem before I put so much time into it (an hour, oh no!).

Anyway, this might work better.


And...  I'm so sorry, I had to make a few more changes.  I'm sorry, I'll get to work on those attack animations now.

That Octorok is adorable, and I think it's the perfect angle - even projectiles flying straight at the player will look appropriate.

Changes are no problem - all I've been doing is optimizing the texture size (so that the textures are power-of-two), and that takes all of five seconds.

33

Zelda Projects / Paper Zelda Gameplay Experiment

« on: April 10, 2012, 01:43:17 pm »

As anybody poking around the Recruitment board may know, I'm working on an experimental gameplay project pulling the 3D gameplay style from Super Paper Mario to a Legend of Zelda setting - to see how it feels, and to potentially develop it into a full project.

Current Build: http://minalien.com/experimental-gameplay-paper-zelda/
Current Controls:
Arrow Keys / WASD - Move Link

A special thanks to Mitsu for the pixel art currently being used in the project.

From my blog page:

Project Description

This project is intended to experiment with the “sprites-in-three-dimensions” gameplay style that is seen in Nintendo’s Super Paper Mario game for the Nintendo Wii. The focus of the experiment is to test the entertainment value of the Super Paper Mario gameplay style (with regards to the 3D portion of the gameplay) in an adventure game setting, rather than the platform setting from which I got the idea.

For the first implementation of this system, I am using Unity 3D, rendering the player as a two-dimensional animated texture mapped to a that has been rotated to face the camera (similar to a billboard, but without the billboard implementation – the plane just happens to be rotated for the camera). While I search for an artist willing and able to provide graphics in the Super Paper Mario style, I am working on the project with sprite rips from other Legend of Zelda games to experiment with a control scheme and rendering.

Right now, I'm developing the experiment using Unity3D 3.5 and deploying it to the Unity Web Player on my blog.

34

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 10, 2012, 01:13:36 pm »

Cool beans.



I didn't take into account the 3d nature of the project so it might need a redesign.


Made some modifications to make his head look less awkward from the back.  Also fixed the belt and some black lines I apparently forgot about.

I'll update Link in a second. One thing I am a little curious about is what might be done with the orientation of the enemy. In Mario, the orientation didn't really matter all that much because they all follow the "Mario jumps on their head and they die" routine, while a number of enemies in Zelda tend to shoot projectiles. Do you think it would look right with some more direct angles for enemies? I'll play around with the Octorok sprite you've already whipped up in a second and see how it handles in its current state.

35

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 10, 2012, 12:27:13 am »

It's cool bro. ;P

Anyway, I updated the Experiment page with the new sheet. I still haven't had time to do as much work as I'd like, but after tomorrow things should calm down a bit (until Sunday, at least).

36

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 09, 2012, 11:47:22 pm »

I mentioned I was bad at this, right?  Progress is going really really slowly so I'll just post it here as I reach *milestones*

You artists and your humility. ;P

Seriously, those are brilliant.
I'll implement the updated Link sprites right now, and sneak in the Octorok.

Oh, by the way - you can all poke around with the current state of the experiment in the Unity Web Player at http://minalien.com/files/GameplayExperiment/.

37

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 09, 2012, 04:42:28 am »

Back from spending time with family and such (apparently things get emotional for the rest of the family when you're about to move away again), I've finished the animation script. Thoughts?

http://minalien.com/files/Test.avi - 2.7 Mb, 3 sec. long.

38

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 08, 2012, 03:18:53 pm »

This is the perspective you're wanting, right?



And also from the front of course.

Holy !@#$% Mitsu, that's amazing. And yeah, that's exactly the perspective I was looking for. o.o

Spirit: I'm not too concerned with the size - my system's more than capable of handling high-resolution textures, and texture optimization isn't very difficult. That looks pretty great, I love the vector-like feel of it.

39

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 08, 2012, 02:34:24 pm »

Around what size do you want Link to be?

I'll give this a try, but I can't guarantee much.

With the sprites I've been playing with, I've been scaling them up to 64x64 per frame so that they look nice in Unity, but I haven't really done much to make them use the smaller sprites (which won't be hard, I should theoretically just have to scale everything in the editor down - depends on whether Unity's willing to play nicely or not). Thanks for taking a look into things.

You could start by using these, they look pretty close to the Paper Mario style : http://spriters-resource.com/custom_edited/zelda/sheet/17558

Those are pretty great, but they don't have the forward/back anims I'm looking for. I hadn't even thought of looking in the Custom/Edits section on TSR - I'll poke around in there, and if nobody else can come up with anything I'll try to get hold of Badassbill. Thanks, bro. :3

40

Recruitment / Re: Looking for artist for experimental Zelda gameplay project

« on: April 08, 2012, 01:26:18 pm »

This sounds interesting.  I'll try to make something for you, but I'm not very good at this sort of thing.

Something's always better than nothing - I'd be happy to see what you can come up with. :p