• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

177 Neutral

About yats55

  • Rank
  1. I know a bit of C++ and know about modern engines and libraries and am interested but don't know much of it.   I've noticed that back in the day when assembly was almost the standard for developing games (Nes, Genesis, Snes) that there were barley any shared engines. The only thing I've heard of is that Batman Forever on SNES and Genisis used Mortal Kombat's (Genesis port's) engine, and Super Noah's Ark 3d using Wolf 3d's (Snes port's) engine, but I imagine those games were programmed in C.   It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.
  2. My biggest hobby are retro consoles, and I've always wanted to make something on one of them especially the SNES. I know a tiny bit of C++, and am interested in programming in assembly, and for hobby's sake I want to asm code on consoles. But I don't know if I should learn 86x assembly first, learn the SNES asm first, or some other console or processor (Maybe the Motorola 68000) It seems like it would be more important to learn 86x first. The thing is I'm not sure how the whole thing of asm works of course. I don't know if learning any one of the asm's means I'll know how to asm code everything else, or if each assembly are completely different. I will say that I do have the Art of Assembly book.   So is it extremely important that I master 86x first before learning to do asm on another console and be able to understand it, or does it not matter which one? If mastering 86x will make it very much easier to understand other console's or processor's assemblies, then I'll definitly do 86x first. Other wise, is there any console that is best to learn for a first Assembly? 
  3. I'm speaking mostly of maps made with tiles.   Is it ever done in map editors or such programs, then the image file of the map is loaded into the code just like how bitmaps and sprite bitmaps are?   If so, what format/file types is it usually done in? (I'm aware sdl by itself uses only bmp) (Mappy has MAP. and FMP. files is that used?)
  4. It's been a very long time since I've done anything in programming, but am about to get back but have forgotten a little bit about it.   I admit this is a No-duh question, but I just wanted to make sure   (Referring to C++)   As you could create your own functions for reuse and call later, will it work if you make functions with functions inside from other libraries or API (SDL)? And if theres anything that needs to be done to do that, and be able to reuse it, I'd like to know. Like maybe when or where do I have to include the original library, in the file with my functions, or in the main code of a project where I use my functions?   Example: **Not an actual c++ code, just trying to show the idea int mydraw (a,b,c,d,e) {   SDLdraw (a) SDLX(b) SDLY(c) SDLbpp(d) SDLtime(e)   }     My plan was to make a little SDL (C++) based Engine/library to shorten the process of developing some games I have in mind, to suit my own needs.      
  5. (sigh) Now I'm hitting some more problems, things may be a little mixxed up. Now it won't move at all! It shows but doesn't respond in movement. Heres the code I wrote if you or anyone can see what I'm doing wrong [sharedmedia=core:attachments:12623][CODE] #include "SDL.h" int main(int argc, char *argv[]) { bool bRun = true; SDL_Surface *screen , *ship; SDL_Rect shipRect; shipRect.x = 100 ; shipRect.y = 100 ; SDL_WM_SetCaption("Fryday", NULL); screen = SDL_SetVideoMode( 256 , 224 , 32 , SDL_DOUBLEBUF|SDL_HWSURFACE|SDL_ANYFORMAT); SDL_FillRect(screen , NULL , 0x221122); ship = SDL_LoadBMP("./ship.bmp"); SDL_SetColorKey( ship, SDL_SRCCOLORKEY, SDL_MapRGB(ship->format, 255, 0, 255) ); SDL_BlitSurface( ship , NULL , screen , &shipRect ); SDL_Flip(screen); SDL_Event event; while(bRun) { bool keysHeld[323] = {false}; // everything will be initialized to false if (SDL_PollEvent(&event)) { if (event.type == SDL_QUIT) { bRun = false; } if (event.type == SDL_KEYDOWN) { keysHeld[event.key.keysym.sym] = true; } if (event.type == SDL_KEYUP) { keysHeld[event.key.keysym.sym] = false; } if ( keysHeld[SDLK_ESCAPE] ) { bRun = false; } if ( keysHeld[SDLK_LEFT] ) { shipRect.x -= 1; } if ( keysHeld[SDLK_RIGHT] ) { shipRect.x += 1; } if ( keysHeld[SDLK_UP] ) { shipRect.y -= 1; } if (keysHeld[SDLK_DOWN]) { shipRect.y += 1; } } }; // while(bRun) { END return 0; } [/CODE]
  6. I've already tried looking this up but I can't find anything to help. I just learned how to move an object which was successful. You press a button once to move it, but you can't hold it down to keep the object moving, you have to keep tapping the button to make move more. Is there a certain way or certain code to make it so that you can just hold the button to keep moving and let go whenever you want to stop?
  7. I'm in the middle of learning sdl, and I'm right now i'm trying out the Transparent part, but the code on the tutorial wont work. I'm using a 32x32 bmp of a little ship with a the background color 255, 0 ,255 or thats atleast what the graphics program says #include "SDL.h" int main(int argc, char *argv[]) { SDL_Surface *screen , *ship; SDL_Rect shipRect; shipRect.x = 0 ; shipRect.y = 0 ; atexit(SDL_Quit); if( SDL_Init(SDL_INIT_VIDEO) < 0 ) exit(1); SDL_WM_SetCaption("Fryday", NULL); screen = SDL_SetVideoMode( 256 , 224 , 32 , SDL_DOUBLEBUF|SDL_HWSURFACE|SDL_ANYFORMAT); SDL_FillRect(screen , NULL , 0x221122); ship = SDL_LoadBMP("./ship.bmp"); SDL_BlitSurface( ship , NULL , screen , &shipRect ); SDL_SetColorKey( ship, SDL_SRCCOLORKEY, SDL_MapRGB(ship->format, 255, 0, 255) ); SDL_Flip(screen); SDL_Delay( 8000 ); return 0; }
  8. I mean just like how you can just start the C64 without anything, and just write basic code and compile it without any compiling software, could you do the same exact thing with assembly, just go write some assembly code without anything and assemble same, same exact thing or did you have to Have some assembling software?
  9. Can the C64 assemble by itself? And so those Paint programs you listed could be used for the game graphics and sprites on the C64?
  10. I've heard the Amiga and Sharp x68000 was used with their graphic programs (like Dpaint) to make 16 bit games for Snes and Genesis etc So I wondered if that was the same thing for the Commodore 64 and NES, was the c64 used for NES development. By the way, when companys would go this route, how did the programming part go? Did they just have to type the code into one of those computers and then send them to the company to put on a cartridge, or was there processor specific assemblers on those kind of computers, or was there emulators for them? You get what I'm trying to say, I'd just like to know, how exactly game dev on those old consoles on those kind of Computers worked.
  11. So I guess that the Commodore 64 was used to make games for itself What language did they use for them(And by the way, I'm talking those actual commercial games and software for the C64) because I know you can program in basic straight from the the thing, but did commercial games use assembly? Speaking of that, could Assembly code be assembled on just the C64, just like basic? Not having to go and buy something One more thing is, could the Painting softwares for the C64 be used to make the graphics for the C64 games, or did to all be done in the programming?
  12. A get the process of making a game meant to for single player, no online interaction at all. But I have no idea at all how it works to make games with Online multiplayer. Is it a completely different subject? If I made a game, and I wanted it to be able to be played online with other people, what exactly would I have to do? or if I wanted to hire someone to take care of that, what would be the name of the kind of person I'd want to hire for that. Is there anything I'd have to be responsible for, such as changing the code of the Game and adding the online multiplayer environment? Alot of times I've seen these expensive devices called Servers, but I don't understand what they do, but I feel like its got something to do with this. Is it something I would have to have to do this? Sorry for so many questions, but I just wanted to understand it as much as possible.
  13. Mainly Castlevania 4 and Conra 3. The human sprites were kind of realistic. I don't know if anyone would know, but did Konami use any techique to doing sprites, or was the whole thing hand drawn on a paint program? (Speaking of that, what graphic programs did Japanese developers such as Konami, Capcom use for those games back then? Same as ours, DPaint, etc?)
  14. As a begginer I ask: I understand that Arcade board "systems" like the capcom boards etc have a bios chip just like consoles, does every single jamma board (ones that are just one game) have a bios chip? If so, 1.Are you suppose to write the Firmware/Bios code in the assembly language of the main proccessor (In this case, the m68000) then just put that assembly code on the chip? 2. For boards that are just 1 game, should the firmware be inside the same code/rom chip as the game, or are they still seperate?
  15. I dream of developing an arcade game and arcade board. I imagine doing it with a Motorola 68000 and etc. Basicly do the process 80's/90's style Would I be able to make a jamma board to put in a jamma cabinite and program a game for it? Can any one explain the summarise how to do it, if willing to? As a begginer I also ask: I understand that Arcade board "systems" like the capcom boards etc have a bios chip just like consoles, does every single jamma board (ones that are just one game) have a bios chip? If so, 1.Are you suppose to write the Firmware/Bios code in the assembly language of the main proccessor (In this case, the m68000)? 2. For boards that are just 1 game, should the firmware be inside the same code/rom chip as the game, or are they seperate? I'd appreciate some links that will help me understand the process, if anyone has done something like this and posted it online I'd like those as well.