• 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

463 Neutral

About Guimo

  • Rank
    Advanced Member
  1. Not sure about the answer by VMan. My experience is with DX9. I stopped using low level APIs after that so take this very lightly. a. Loading will fail. It is possible you find the driver return an error code related to an out of memory error. Keep in mind that not only textures will fill our memory, vertices may also take video memory. In this case the best approach is creating a texture/mesh manager. In my old engine I had a base common class with a timer. Whenever I needed a texture loaded I requested my manager to load the resource. The manager was able to identify the type of resource and return an appropriate pointer to the loaded resource. Every resource loaded this way was timestamped. Also, any resource used by any process (rendering or whatever) updated this timestamp. This timestamp allows the manager to make some usage decisions like i.e. when you load a new texture and there is no more space in vram then the manager was able to search the least used resources (the ones not used for a while) and unloaded them to system ram keeping them dormant until required. Then it got enough memory to load your requested texture. The texture manager is a nice way to control your video ram. 2. There is, but you really shouldn't use it. The reason is that your game should be able to run in any configuration and your target may have less memory than you. Also drivers work in different way so even when another card has the same amount of ram doesn't mean it will behave the same. Finally, having some available memory doesn't mean it is contiguous memory so the texture loading may fail anyway even when the driver reports enough free memory. Luck! Guimo
  2. vf = v0 + at if you want to reach smoothly and stop in a point, vf = 0 then -v0 = at or a = -v0 / t Now if you use d = v0t + 0.5 a t^2 You should know your starting position (say 300 units) and the time you want to use to arrive to your destination (say 3 secs). Replace them in 2 and then with the two equations you may easilly compute the acceleration and initial speed you will use for all the exercise. I don't know if this is what you need. Luck! Guimo
  3. http://www.jmonkeyengine.com/
  4. Its easy but you need some texturing tricks. The problem here is the pixel shading pipeline not the vertex pipeline. So if you still dont know how to do texture alpha blend then find a good tutorial about that. First, build your vertices as usual, transformed or not. The trick is having a uv coordinate on each vertex. Build a texture with the alpha information. A 1x256 texture is okay. Paint the texture red and the alpha in a degrade from black to white. Save it as your preferred format (if DX then pick a DXT format with alpha). You should have a red texture which vanishes. Assign the uv coords of your triangle to a point within the texture. If using a fixed pipeline, setup the cascade so that in the first stage you pick the texture color like In the first texturing stage (0) setup your texture 0 to the one above (load it first of course) setup color arg0 to diffuse (the vertex color) setup color arg1 to texture (the texture diffuse color) setup color operation to modulate (the vertex color by the diffuse color) setup alpha arg0 to diffuse setup alpha arg1 to texture setup alpha operation to selectarg1 (select the alpha from the texture) In the second texturing stage (1) setup color operation to null (meaning that it ends here) Enable the alpha blend Setup your alpha blend to src alpha, 1 minus src alpha Enable the ztests Disable the zwrites Render your triangles This means the triangles will be transformed (if they are untransformed) and lit (if they are unlit) and then passsed to the pixel pipeline. In the pixel pipe the triangle gets rasterized and each pixel takes the color of the vertex modulated by the texture color, and the alpha is the color of the texture alpha. As the texture is transparent the triangle will get transparent. Dont forget to render opaque triangles first and transparent triangles second or you will get rendering artifacts. Also, enable the alpha blending functions, test z to avoid over rendering and disable the zwrited so that translucent tris wint fill the zbuffer. Luck! Guimo
  5. Hi, Yes of course you need to have this file also in the server and load it at startup time. My reason to write a script file with all the card data vs having it on a DB was: a. Torque already understood my script right out of the box. No XML required. b. Avoid transferring information from client to server saving bandwidth in the process. c. The game updater is able to update the script file if any change or update takes place and will do so on game startup. Having this information on the DB is just overkill. On the end, you dont want to query the DB every time you want to compute the result of an attack as it will become a bottleneck. The data size is too small in the server side to worry about it as you will have at most 3 or 4 MB of data loaded in memory which is trivial by current standards. So, if you are going to have it in memory, the script file can be loaded in client and server side during startup and used as long as your server is up (days and days at a time). So, if you are loading all in memory and not touching the DB for days at a time... why do you need to save it on a DB? Of course nothing prevents you from doing so but you will find saving it as a text (XML, Script, etc) its easier to edit this data and make adjustments by hand if neccessary. Client information os just another thing. Players will buy and sell cards, change their collections and armies, add and remove buddies, change servers, and all our players will do that frequently. This information needs to be stored safely so you need a good DB for this. Personal SQL, Personal Oracle, Postgres, MySQL, all of them can be trusted with this data. But for the card info... you really dont need it. Anyway its your design so you have to take your decision. Luck! Guimo
  6. Just add a Requirement table that links the Skills table with itself. So the requirement #1000 needs the requirement 900, 800 and 700. You should have the following rows in the requirement table: 1000 900 1000 800 1000 700 Now the question. Why do you need this inside the table? usually the requirement definition is something you need to distribute in your package (applet, Flash, C++) and if you publish new cards then you will create a new package. Thats all. In my game I was worried about that and even created importers/exportes for my units. On the end I decided to drop all that from the DB and make it into script files (using TorqueScript, I'm using Torque). I left in the database all the things which really needs to be serialized like the user collection, the user equipment (thats particular to my game), the user armies (their decks) the user buddies and blocked players. Gold, experience... all the transitive stuff. Of course I created an application to manage the script file so I can edit the creatures, equipment, artifacts, etc easilly. Luck! Guimo Some shots if interested... http://www.garagegames.com/community/blogs/view/15651 http://www.garagegames.com/community/blogs/view/16329
  7. There are some PC games which have an interesting setup and gameplay... take the Fallout series for example but of course what you say its true. I love playing board games more than video games because of the human interaction. Some people may say a game of (e.g.) Risk is the same in a PC or in a board game. Or playing Magic The Gathering against Magic The Gathering Online. For me its a completely different experience. I like people to be there to talk, chat, complain about rules, have a beer and... if there is enough time... play. In fact playing the game for me is just an excuse for the former. You just cant do that in a video game. In the computer game world, millions are spent in creating a game and the large developers try to keep on the most profitable franchises to guarantee their money return. That limits a lot of variety. I.E. I gave a friend of mine a PS3 as a gift (I owed him a lot) and the first thing he did was going to the store and bought a control and Pro Evolution Soccer 98. Some time later we were talking and he told me... hey I bought a new game for the PS3!!!!... Pro Evolution Soccer 99!!!... Soooooooo... companies already have niches and try to profit from them but people is guilty for not requesting more from them. Indie games are interesting exactly for the opposite. They cant compete against the monster studios but can risk in different approaches. So you get a lot of interesting games at very low prices. Some of them get famous and the big companies will buy them (and probably ruin the franchise) but thats how it goes... if you want innovation... go for the indies. Unfortunatel you cannot innovate much. A lot of people just likes an easy game and not an overtly complex one. There are a lot of excellent games which simply werent understood and were forgotten (does anybody remember Master of Orion or Master of Magic?) For me, I found my objective as an indie is to build a muliplayer gaming platform for turna based games (cards, board, etc). Im in the process of that trying to build a game which combines Magic The Gathering and Warcraft 3. My objective is to build a platform strong enough to be the base of future games I have in mind. So I plan to develop board games on the web but where the units are alive and can move and will fight, spit fire, fire a missile, that is a live board game with a lot of communication options to chat and video conference. The only thing missing will be the beer and the pizza. Luck! Guimo
  8. OpenGL

    Maybe you are trying to load the model on each frame? You should load your model only once during the app startup, just after you create the OGL device. Load the model into a VB. Then, during your rendering step, use that VB to render your object. Guimo
  9. I remember some time ago someone posted a program which was able to open binary files and explore its contents. The program used a XML file to describe the fields of the file so that you were able to define your own data format. It used the same XML file to create a simple interface. If anybody knows the name of the program I'm talking about please tell me how to get it. I just cant find it anywhere. Luck! Guimo
  10. I guess that your internal data structure will be a network of nodes where each node has a connection with other nodes. Each node will store information like who is currently the node owner and how many troops you have and maybe which resources that node provide. The second step is to turn that into a game board. If you want to simplify things you may consider using planets (just spheres or circles) and create your basic layout with lines connecting the planets. Using that basic laour you could flesh out your game mechanics and when everything is working fine including game titles, main menu, game interface, etc, you may just switch your board to your final version and that would be all. Luck! Guimo
  11. You dont want a language, you need an engine. Search here what you need depending on your budget: http://www.devmaster.net/engines/ Luck! Guimo
  12. Yes, you still need a scene object. The scene is a representation of the things in your game. Usually the scene handles a camera, the lights, the characters and the map. Think your engine in terms of functions, something like this. a. Bitmap management - Load lots of bitmap frames. (i.e. A man facing standing and facing left). - Allow your engine to handle bitmaps in memory, releasing the less used bitmaps. - Advanced. Allow for bitmap declaration only. That way the bitmap is declared but not loaded until it is required. b. Sequence system - Group bitmaps in order to make sequences. (i.e. A man standing facing left buit breathing heavilly). - To standarize, even an object with a single frame should be considered an animation. - Make it easy for your engine to retrieve the appropiate bitmaps on the appropiate keyframes. - Build an appropiate playback system in order to allow faster or slower reproduction. c. Animation system Allow to group sequences in animations. i.e. A walking animation may be defined as all the sequences of the man walking north, south, east, west. The attack animation may be composed of the man attacking on each direction. One sequence for each animation. c. Character definition - Group sequences in order to define a character. A soldier is defines as a man standing, walking, running, attacking, dying. - Build your character library in order to allow you script the loading of all your characters. e. Time tracking mechanism. - Create an object to make you easier to play and pause the time f. Map - Build your terrain system. Probably you will use sequences from your animation system to handle the tiling. - Add blocking objects to your tiles so you know where a character can walk though. - Implement path finding. i. Camera system - Create a camera so you can pan across the map. g. Lights - Implement lights, add lights to the scene. h. Particle system - Create your appropiate particle system. You will probably use your sequence system to handle the images. i. Scene definition - Add the map. - Add lights. - Build your Quad trees or similar scene management structure allowing to add lots of soldiers to the scene. Recommended, manage everything in world units, not in pixels. - Add layers to your scene so you can handle treasure, flying units, main characters, special effects. - Add the appropiate animation mechanisms so you can move the objects. - Dont forget to add the time tracker so you can pause the game at any time. - Add the appropiate collision detection. - Advanced. Build a script library so you can handle events between objects. j. AI Handle AI in your game so characters know how to move and interact. k. Input Mouse, etc l. GUI Create or integrate a GUI system. You will probably use your animation system to handle animation in buttons, images, etc. m. Networking A complete issue in itself. Should integrate into the scene. As you see, lots of things to do. Start coding! Luck! Guimo
  13. Hi prux, ps1.x specification clamps the pixel color values to the -1/1 range only. In fact the color values should be clamped to the 0/1 range only. That is more than enough because it doesnt matter how many strange computations you are doing in the PS, the output is jut a RGBA color, that is, 4 floats in the 0/1 range. This RGBA color will be applied to a single pixel, the pixel which is processed by the shader in that moment. Also remember that PS1.x is instruction limited so you may quickly hit the PS limits. In ps2.0 and higher you can get higher values than 1 but unless you are using a floating point color buffer or High Color Range buffer (I guess they are available since p.s.3 only) they will just get lost and clamped to 1 anyway. You will only want to exceed the 0/1 range in other applications like computing vectors. May I ask what exactly are you trying to do? Maybe a book like ShaderX or ShaderX2 may help to clear this subject. I think its free to download now. Anyway I would suggest you to use PS2 and DX9. PS2 video cards have been around for more than 4 years now so its simple to assume that you will get a nice base to run your game. Luck! Guimo
  14. This may happend due to many reasons, most probably your card is an ATI card and you are trying to run a PS1.2. Due to lack of standarization on the first PS cards, nVidia video cards are able to handle PS 1.1, 1.2, 1.3 and 2.0 or higher. ATI video cards are able to handle PS 1.4 and 2.0 or higher. So if you try to run a 1.2 shader in an ATI card it may fail In the other hand, there is no support for PS1.0 in any card. 1.0 was something like the first PS concept by nVidia and was never released in any video card so trying to make a 1.0 shader will probably fail. That said, I agree with EmptyVoid (a really empty name I must say) and suggest you to move to PS2.0 or higher unless you have a really compelling reason to stay with 1.x shaders. Luck! Guimo
  15. Hi, Have you tried disabling the last alpha operation? Like: m_Direct3DDevice->SetTextureStageState( 0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE ); m_Direct3DDevice->SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1 ); m_Direct3DDevice->SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_DISABLE ); m_Direct3DDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE); m_Direct3DDevice->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); m_Direct3DDevice->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); This way you make sure you are not moving to a third operation in the cascade. It may also help if you send all the code for your setup. Like how you send the polys to render or how you setup your lights. Luck! Guimo