• Content count

  • Joined

  • Last visited

Community Reputation

363 Neutral

About Silvanis

  • Rank

Personal Information

  1. Maybe it'll help to explain it differently:   A Model is a collection of data and the structure of that data. A couple of examples: say you have a list of names in a text file. The names is the data, the fact that each name is on its own line in the text file is the structure. The more obvious example is a database: the entries are the data and how the tables are set up and connected is the structure.   A View is the UI and how the data is presented to the used. This is the buttons and rows and other visual elements that show up on the screen, along with the code to pass input on to the controller. Think dumb terminal; the View doesn't know what the data is, it only knows that it's  going to display 10 rows of something it recieves from the controller and if the user hits the next button, it should tell the controller about that.   A Controller is what parses the data from the Model and prepares it for the View. It's the middleman between the View and the Model. The Model doesn't care how it's data is presented or even if all the data is used, it's fairly passive. The View doesn't care what the data is, only what fonts or screen regions are going to be necessary to show it. The Controller is what takes the View's input, finds the appropriate data in the Model, and gives it back to the View. The Controller is like a waiter; you (the View) point to an item on the menu, and the waiter gets that item from the kitchen (the Model). You don't care how it was made in the kitchen or what sort of maze the waiter went through to get the dish; you only care that the correct item was given to you.   The Controller is seperated from the Model because you should be able to change the data without affecting how you retrieve/filter it. The View is seperate from the Controller because retrieving/filtering data has no affect on HOW it is presented, only WHAT is presented.   To use a more concrete example:     This is a screenshot from PokeIndex 5th Gen, an app I made for iPhone. The Model in this case is a literal database with the Pokemon's number, name, and filename of the image. The View is a table view: it doesn't know or care what Oshawott is, only that it has to display a 32x32 image, format a 3 digit number with the Marker Felt font at 20 point size, and do the same for a text string. It also has to be pass to the controller a message if any of the rows are tapped. The Controller handles loading the Pokemon info from the database, filtering it (by Pokemon number in this case), and preparing the info in a way the View can use.   I could change the Model to use Pokemon X and Y instead of Black and White and that won't affect the Controller. I can change the View to display a grid of Pokemon instead of a list and that won't affect the Controller. This is the encapsulation that the MVC pattern is designed for. But unless you have a certain degree of complexity in your Model (in this case, it's 650 Pokemon with all thier stats and locations), then the MVC pattern is over abstracting, as blewisjr said. If your View has constraints that keep it from changing, MVC may not be the best solution either.   That said, the iOS libraries push the MVC pattern pretty hard, so that would be one way of immersing yourself in it.
  2. Planning to fail... ?

    I'm having a lot of similiar issues with the game I'm working on. I'm releasing on the Apple App Store next month, how do I get enough interest for it to have a chance? I don't have a budget to advertise with, and most of the guerilla tactics boil down to "know a lot of people". So I'm rooting for you, for what that's worth
  3. Possible iPhone / iPad Development

    I started my iOS development on a Mac Mini. $600 for a pretty good dev platform. I'm using Cocos2d for the development library. It works wells with the native Cocoa Touch libraries, but doesn't do 3D. Not a problem for me with my sprite-based games, but it is something to consider. There is a Cocos2d-x fork for porting to Windows, but I haven't delved into it yet and I'm not sure it would work in the reverse direction.
  4. "Fair use doctrine" advice needed

    Using another game's artwork in your game is copyright infringement in the United States. Frankly, what it is in your country is irrelevant. Apple is a US company, so if you want to make your game for iPhone or iPad, that people you infringe can force Apple to block it. Valve (Steam) is a US company, so any PC games you sell through them will also get blocked. If your company's website is a .com, .net, or .org, that can also be considered a way for the infringed company to recoup their costs. Bottom line is that even in the best case scenario (living in a country that does not respect copyright laws and doesn't allow international attempts to collect debt), you will still get cut off at the knees when you try to distrube your game. In the worst case, as Dave Troyer mentions, you would be subject to garnished pay, frozen accounts, and reposession.
  5. True, False, FileNotFound

    It's worse than that. It's the equivilent of YES, NO, TRUE, FALSE. So now you have to test for multiple values (did it return YES or TRUE?). And given that you most likely wrote or are using documentation that existed before GRAPHICS_DISABLE and GRAPHICS_ENABLE were added, you won't check for those. Not only that, but who checks for "other" in what is supposed to be a boolean test?
  6. Books to review

    I'd be interested in hearing about the Cocos2d book. Been wondering about that library for a while now.
  7. Question about Diablo 2's sprites

    If I recall correctly, there's some clever optimizations in play. For example, they only had to animate 3 movesets per character: 1h weapon (with or without shield), dual wield, and 2h weapon. I think there's also only 3 armor sets; light, medium, and heavy. I do believe it's all pre-rendered sprites, though. There's also some pallete swapping going on (weapons that do cold damage look blue, for example), which makes it look like more variety than there really is. Also, they probably made separate textures of the weapons, shields and head models, then applied them on the fly; another advantage of limiting your animations. It's still a lot of work for their artists to make all the weapons, shields, and helms for each character, but considering it's a loot-centric game, that comes with the territory.
  8. Copyrights question

    Well, first of all, you're not looking for copyrights, but trademarks. I don't know about international or Greek trademark law, but here in the US, you don't NEED to register a trademark (trademarks that aren't registered have that TM symbol instead of an R in a circle), but registering helps to establish that you were there first. For your company, just filing the paperwork necessary to make it a legal business should be enough to establish a claim on the name. One important note: trademarks only apply to the field you register them in (in your case, electronic entertainment or software or something like that)...of course, large companies seem to like to toss that rule out the window whenever convenient... Note that I'm not a lawyer, blah, blah, blah. I'd suggest registering your business and getting a game or two under your belt before worrying too much about trademark issues, though.
  9. Getting things ready

    Just so you know, your email directions for downloading the games are still Windows-specific. Step 4 talks about running the game from the start menu, which obviously doesn't exist on a Mac. Not that big a deal, but thought you should know.
  10. I'm statisticalyzin' (almost)

    I'll assume the stat generator won't have 5 or 6 "defaultvalue" entries for the game list when it's hooked up to real data ;) Bit of a hijack, but how goes the work on porting your games to the Mac? My girlfriend is getting too addicted for just one puzzle a day on your dailies...
  11. The idea is to make the collision rectangle smaller than the rectangle for the sprite itself because the actual object usually doesn't fill the rectangle of the sprite (take Link from Legend of Zelda, for example: the sprite is a square/rectangle, but Link himself isn't, so there's areas of the sprite that are transparent). This helps to avoid situations where there's a near miss that counts as a hit. It also creates situations where a near hit (or graze hit) is counted as a miss, but that's the price you pay for using a quick collision detection system like this. You subtract left from right and top from bottom because you want to send negative numbers to the InflateRect funtion so it SHRINKS instead. Bit of a hack, really, and something that should have been spelled out in the book, but oh well. Not sure how 12 ends up getting you 1/6th of the sprite size, but that's the problem with "magic numbers" in general. CopyRect is pretty simple, it's copying the sprite's rectangle to the collision rectangle (altough the to/from order seems odd). InflateRect would normall make a rectangle larger, but since we're passing negative numbers to it, it shinks the rectangle. Hope that helps!
  12. Time Paradox

    And what's wrong with the loop, anyway? The easy way out is to say it doesn't matter if it's A or B, it leads to the same result: the scientist fixes a machine that's only capable of going back to its original (from the scientis's point of view) time and state. You could add more complexity in saying he made multiple jumps with it before something happened and it ended up in the past, broken, but then you start getting into issues of free will and the ability to affect anything and time travel is messy enough as it is. : )
  13. It's a little trickier than you would think from that paragraph. MICROSOFT'S implementation of OpenGL is software-based (and never made it past 1.0, I think), but most games will use the OpenGL driver that the video card manufacturer provides, which requires using the extension interface to access. Does that make things any clearer?
  14. Confusebox = easy?

    Considering Confusebox is one of your shorter games (going by times on the high score board), I don't see any problems with increasing the board size. As long as it doesn't get to ChessCards levels of commitment, you should be fine.
  15. Yet another journal update that doesn't warrant a title

    Main problem with getting the 12" iBook right now is that Apple is in the middle of changing their systems to Intel-based instead of PowerPC-based. So if you want to look at doing cross-platform development in the future, you might be better served with the MacBook Pro, assuming it isn't out of your price range.