• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Homers Pal

  • Content count

  • Joined

  • Last visited

Community Reputation

164 Neutral

About Homers Pal

  • Rank
  1. I think frob is being overly helpful here because it seems clear to me you want someone to hold your hand through what is actually a very simple process for anyone with even a minimum amount of ability. It's one thing to help noobs get started its quite another to help noobs who seem incapable or willing to do even the most basic research. rtfm means Read the Fu%&#ng Manual...please take a moment to do that before throwing your hands up in despair and asking for help you are currently unable to understand. Even if you have no ability, Google will take you to 100's of how to write your 1st project on a phone. You have no real reasons to keep asking for help here when there is a wealth of resources available. Given you want to write on phones, java is "probably" the best solution for you, its not too hard, and again there are many many step by step instructions on how to do this on the web. The Sun Wireless toolkit (on which all phone SDK's are based) is available online for free, and has a tutorial mode and the sun docs are full of examples. Finally I suggest you walk before you can run...you have to learn to program before you can start to write games for any platform. You need to make that your main priority. Part of learning to program is understanding how to set up a system for development.
  2. Quote:Original post by waterborne Thanks for the replies everyone. @Hommers Pal I need a function that is similar to the printf(" "); of C. Can you suggest a part in the demos that displays this function? Also, can you suggest where on the demos is it good to start? Thanks in advance! Its all in the demos, honestly, just go through the gx files and you'll see some of them do put text on screen, review those and you'll be able to produce your own output routines.
  3. Quote:Original post by waterborne Hi all, I'm new to this forum. I'm having a problem programming with Codewarrior using Nitro SDK. I've been trying to figure it out using the demos of Nitro System and SDK, but still haven't been able to output a simple "Hello World" in the DS emulator (im using ensata). Can anybody send me a simple code that outputs a "Hello World" in the DS emulator? Or does anyone know a good site with a good tutorial for programming in DS using CodeWarrior? I'd really appreciate it. Thanks in advance! If you have the SDK you also have access to all the demo's that come with it, in build\demos it can be a bit daunting to start off with, especially as there are no project files for any of the demos, as they are all makefile built, but they mostly consist of a main.c file and any supporting header files...so are easy enough to work out. Check out the gx\UnitTours demos for examples on how to set up various aspects of the screen and use of fonts for text display. There's no specific hello world program, and writing to the screen is dependent on understanding how to set up screens 1st, so your better off using OS_Printf to print messages to your codewarrior debug output screen until you get the hang of things. Avoid getting confused with homebrew stuff, it does things very differently and you will need to master the SDK. Also use your warioworld access to get onto the Nintendo forums for help and tips on getting things started
  4. Quote:Original post by UnshavenBastard Quote:Original post by Homers Pal I agree the price is expensive for what it is... Right now I'm a bit irritated by how the 3d output looks on that thing compared to ensata... I just tried to display a low poly model (no textures, but normals & light, just took some code sample and changed the model from cube to.. something more interesting) In ensata it looks fine, in no$gba it looks weird. The lighting is totally broken (no matter if "nocash" or "opengl" is enabled). Hrrrmmmmm. yup as I say, its not 100% but I would have though simple models would be ok...I've used it on a projedt with some very complex models and they've all been fine, the only real issue I've had is some polygon priority problems
  5. Quote:Original post by UnshavenBastard Quote:Original post by Homers Pal Personally I've always thought his pricing policy for his pro version of his no$ debugger was high, especially as it's not 100% compatible (yet). But still, I have to wonder just how cheap you want to put together a system capable of producing commercial apps....is $750 still too much? The $15 version is more than usable and relies on your honesty. You could buy that and produce commercial games but really that's rather mean. I didn't advocate using the $15 version for commercial games, were are you reading that from? I said "for you homebrew folks" since there certainly are some of theam reading this thread. As for being too expensive, well the price looks quite expensive for a not fully compatible thing, but we'll weigh it (1 nitro + rest no$gba) against obtaining several official hardware kits. the quotes around home brew....if I read that wrong I unreservedly apologise. I agree the price is expensive for what it is...but he's always had a bit of a high valuation when it comes to his full featured versions...back in the GBA days he was charging as much as an official dev kit for his GBA version...yes it was good, very good, and in some respects allowed better debugging than hardware...but the hardware was easier to use despite a few shortcomings...and still is.
  6. Quote:Original post by UnshavenBastard wow, I just tried some emulators, and am amazed by the screen shot section of the debugger for the no$gba emulator (which is for gba and NDS)... but the thing costs $750 for a single licence heh. (no-debug emulator free, debugger not) for you homebrew guys, it costs only $15 for "home use". click o_O Personally I've always thought his pricing policy for his pro version of his no$ debugger was high, especially as it's not 100% compatible (yet). But still, I have to wonder just how cheap you want to put together a system capable of producing commercial apps....is $750 still too much? The $15 version is more than usable and relies on your honesty. You could buy that and produce commercial games but really that's rather mean. If you're going to produce commercial software using that you really should put some cash his way for providing a tool that lets you do that, after all once it's sold your going to make that $750 back many time. Also if you're a proper business, tools you purchase are tax deductible, so why skimp? If you don't have the funding available to buy the basic tools for commercial development, it might be best to avoid the market, it can get very very expensive trying to pay for all the unexpected costs of getting a project up to lot check standard. Kiwi, refactoring homebrew software might work, but tbh the way homebrew and SDK do things is quite different in many areas, and it might be a lot of work removing all the homebrew stuff so that you comply with Nintendo standards and use of the SDK... That work takes time, time == money so it may be a horrible false economy What might work though is to use free homebrew to produce quick prototypes to pitch to publishers to secure funding to restart the project with proper tools and SDK I wouldn't really advise refactoring...use homebrew for learning and the homebrew market..Use the official SDK for anything that is likely to be commercial, when you have that official kit and SDK, you're understand how much simpler the process is.
  7. Quote:Original post by kiwibonga Ways I would save money if I were your company: - Have *one* "official devbox" with the official devkit software, official cartridge burner, video demo thingy, etc... - Have many "unofficial devboxes" with the unofficial devkit. Explore the option of using linux boxes instead of windows ones, so you don't have to pay for Windows licenses. - Have your developers write portable code -- that means keep all the lib-specific stuff (sound/video output, file I/O) in modules that can be easily refactored. - Have just one guy work on "porting" to the official hardware once it's ready. A pirate cartridge with a SD card should cost about $50... It's the only thing you need to pay for if you want to be able to run software made with the unofficial devkit. Oh, and if you're cool dudes, I recommend making a paypal donation to the devkitpro developers when your game goes gold :P Woah there, he mentioned "official" development, so I assume he's talking about a game that he wants to send to market. The homebrew kits are great and practically free, but please remember nothing you write on a homebrew kit can be released on an official cart. Only games written with the current approved SDK which have gone through Nintendo's official lot check, are allowed to be sold on the commercial market. That basically means, you have to register as a developer (assuming you qualify and are approved by Nintendo) and then download the IDE and SDK from WarioWorld and off you go. It is technically possible, but very difficult, to write projects using just the supplied free Nintendo Ensata emulator (or others such as no$) meaning you can save a few k$ and not buy the hardware, but frankly the chances of that being 100% compatible with hardware are slim and you'll face endless bugs when presented to lot check. The Codewarrior IDE is free and is a frustrating system at times but perfectly usable, it does not work on linux though so you'll need to have Windows XP (it can work in Vista but its a bit flakey). The DS is probably one of the cheapests consoles to work on from a commercial point of view, a total outlay of less than $3K will get you everything you need to work on a professional level. To repeat...you cannot write commercial games using the homebrew kits, they simply won't get past Nintendo's approval system, which all publishers have to pass to get their games produced. Homebrew kits are soley for the homebrew and learning markets. IronWarrior.. its not a hard machine to write for, in fact it's pretty cool when you get into it, but like every console out there, if you want to go for full commercial quality, you really need to make use of the full commercial tools.
  8. No, you can use C or C++ but the main bootstrap progs are all done in Objective C, once you fire it up you're free to call routines written in "normal" C just as long as you follow the inital Objective C patterns and handle the message systems. In otherwords write a shell/wrapper to start it up, which is already supplied in the SDK, and then branch off to your own programs written any way you want. [Edited by - Homers Pal on April 6, 2008 4:45:33 PM]
  9. Quote:Original post by PsychoPumpkin Well, I was hoping for at least a few iPhone developers on this forum so I didn't have to rely on some of those Anti-AnythingButMacintosh sites to bounce issues/ideas off. [smile] Well I'm with you, but really aside from playing with the samples I'm going to find t very limited until they get the OpenGL sorted. For the moment it's a decent way to get my head around Objective C, but its a few months off being any use as a genuine games dev platform...shame as I have a really cool idea to design an FPS around the tilt controls.. Of all the docs supplied what do you think I should start with to learn Obj C?
  10. Sadly there are several issues with the SDK as it stands, 1) it runs on a Mac...ok well you can buy a mini for a few hundred so that's a reasonable investment. 2) The Emulator is currently unable to run any graphical programs (no OpenGL ES support) so you are limited to the onboard graphic types...buttons, lists, png's, etc...not very useful for games. It can't even rotate on screen!!! Despite the options being listed in the menu, it won't rotate. 3) The certificates needed to run your apps on hardware are being rationed.. Currently only "SOME" US, applications are being supplied, most are getting a standard, we're sending them out shortly email. Outside of the US nothing at all. So basically, you can fire up the IDE, play with the hello world progs and thats about it for now.... I'm more than a little upset about it, but at the moment, its not a viable games dev platform. I'm sure it'll improve, but if anyone from Apple is reading this...seriously guys what were you thinking? A dev system that can't actually run graphics...poor show...get it fixed ...soon! [Edited by - Homers Pal on March 16, 2008 9:48:02 AM]
  11. Quote:Original post by Adam Novagen superpig: Technically, I am not registered, since I am only 16, and therefore I will not yet be approaching companies for official production & distribution. As far as computer games go, however, my game[s] are licensed & copyrighted, as is Ghz and its attatched concepts, so I see no problem in calling myself CEO. As a final note, I will definitely be making Ghz an "official" corporation once I come of age. Anyway, I appreciate your concern & advice; thanks! a 16yo CEO...dude...it takes time, money, guts and experience to be a CEO, to not see why it is so absurd that you use that title, when it#s pointed out is childish in the extreme. When you have a genuine company, and people look to you for a living, call yourself a CEO, until then, please don't..it just makes you sound like a silly kid.
  12. Quote:Original post by Evil Steve Quote:Original post by frob CodeWarrior is the official set of tools, so that's what you get. [1]And oh how I wish it wasn't. It's the worst compiler/IDE I've ever used, it crashes all the time, it's full of quirky UI bugs, it's linker was crashing when compiling our game previously, it likes to completely ignore breakpoints and just go horribly wrong with memory watchpoints. </rant> arrrghhh Its also the least intuituve system ever..it's as if they worked out all the most intuitive ways of doing something..then did the opposite...even adding a file is a chore, the "intellilnk" stuff is more hionderence than you can imagine, and the auto dock "feature" is the most irritating thing I've evern knowne when trying to move a window out of the way. nasty nasty But..it is free an once you learn to keep the blood pressure down it does it's job, poorly at times, but it does it's job, but I wish to god Sony had not bought SNSystems, and therefore killed development of the Wi and DS ProDg dev system....
  13. Quote:Original post by blood sport Hello, I have a ps2.I'am wondering if I have to mod my ps2 in order to program it? I have been told if I program in C I won't need to mod it cause C is a high level program. This statement shows a basic lack of understanding of what code actually is, you have to understand that all programming languages compile into native code of some kind, or into code that native code interperates and as such are all essentially machine code, but written in high level languages to make it easier for humans to program and read. It does not matter what you program in, so long as your compiler produces native code which will then run on a target machine. In the PS/2's case it is code that is then stored on a CD/dvd and booted up when the machine scan's the disc. The PS/2 requires certain bootstrap codes and other copy protection sytems to be present on the CD and in the code, before it will load and run code, modding helps bypass some of that but you still have to understand how the PS2 actually expects the code to be formatted. This kind of coding is way beyond a beginners ability, learn to code on a PC 1st in C or C++ and once you are comfortable with the concepts of coding and understand the differences between high and low level languages, you can learn how the PC loads its code into memory to run, you will be able to fathom the basics of how a PS/2 loads its code and understand the way homebrew code works. I think what I'm trying to say in a roundabout way, is don't even attempt to mess with PS/2 coding until you understand a bit more about general coding.
  14. Quote:Original post by yasirraza_110 Homers, Thanks for repelling first. But actually i was try it alot of times but i can't done please give me solution if you can. Quote:Original post by Homers Pal We don't do homework for people on here. But truth is the solution is right there in the question, write a triple loop to test all possible solutions upt to a value of 500. It's not that hard, think about it. yes it can be done, and as I said its very easy...if you are struggling with this you are going to have problems later when you need to do much harder code. You've already been told how in the question, and by others here, write 3 next or while loops, one for the hyp, one for the opp and one for the adj, and in the middle of these 3 loops test if the resulting triple meets your rules, and if it does either count it, or keep it in an array somewhere... then let the loops continue until done. there are indeed a few tricks to speed up this process but just do the test for all possible combinations 1st (brute force) and best of luck.