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

Jon Alma

  • Content count

  • Joined

  • Last visited

Community Reputation

406 Neutral

About Jon Alma

  • Rank
  1. 3D

    I think this is the sort of thing I'm after - I'll work on integrating something along these lines into my code and let you know how I get on. Thanks. I probably wasn't very clear - I 'm already billboarding with 4 verts and using the viewing matrix to work out the 4 points (as in you example). The problem I'm now facing is that I am moving from a billboard drawn around one 3D point (a particle) to a situation where I am moving up from a line drawn between two points (the start and end point of the laser bolt for example) to ideally drawing a textured quad that is (as much as possible) rotated to face the viewer. Having to maintain the start and end points mean I cannot simply use the viewing matrix to position the quad - I need to retain the two points as the centre line of the quad and rotate as much as possible around these. Hope that makes a bit more sense?
  2. 3D

    Until now I have been using GL_LINES with a thicker line width and a one dimensional texture. Works well, but I want to move to a 2D texture so I can have glow along the edges of the laser bolts for example. Not sure I can achieve this with GL_LINES and as a result have headed down the direction of using billboards.
  3. Some time ago I implemented a particle system using billboarding techniques to ensure that the particles are always facing the viewer. These billboards are always centered on one 3d coordinate. I would like to build on this and use billboarding as the basis for things like laser bolts and gunshots. Here the difference is that instead of a single point particle I now have to draw a billboard between two points - the start and end of the laser bolt for example. I appreciate that having two end points places limits on how much the billboard can be rotated to face the viewer, but I'm looking to code a best effort solution. For the moment I am struggling to work out how to do this or find any tutorials / code examples that explain how to draw a billboard between two points ... can anyone help? Thanks.
  4. I would recommend looking at gametextures.com - there are pricing models attached (clearly explained on the site) and the textures are material textures in general (metal textures, wood etc) that I then tend to extract sections for when skinning models - so not ready made isometric object textures, but something easily adapted.  From personal experience, where I am okay with the coding and modelling but rubbish with the texturing, the textures on offer has helped me turn programmer art into something will a professional feel - excellent texture and very good support (with even the option to request specific textures).
  5. Many thanks for all the detailed advice ... absolutely exactly what I was after so very much appreciated. I'll start experimenting based on your advice and see what comes out of the process!
  6. I'm currently working on a space combat and trading game ... think Star Citizen with $68 million less funding ;) All is going very well for the moment and I've reached the stage where I want to add two new sound elements to the game. The first is radio chatter - the idea is not to reproduce the full chatter but more a brief phrase that will draw the player's attention to a longer message displayed on the screen (for example phrases such as 'under attack' or 'hostile ships detected'). What I'd like to do is take voice recordings of these basic phrases and rework them to give the impression they are being transmitted by radio (so potentially clipping of the sound and addition of static, etc) Secondly I want to add a ship's computer voice for phrases such as 'shields down', 'engines activated', etc. Here again I would like to distort a normal voice recording to add a more 'metallic' sound while avoiding it sounding like a speech synth voice. Could anyone give advice on a good way of achieving one or other of these, ideally with a tool that will not cost a fortune (this is an indie hobby project with very limited budget ... time but no money!)? For info I have been using Audacity for other sound effect editing, but am willing to consider other options. Many thanks.
  7. It would also depend on the style of game you are aiming at.  I remember playing a text adventure game years ago that played to fantasy cliches and wasn't afraid to make fun of them.  The edge of the world in this game was a barrier of fog with signs saying "This part of the world has not been created yet" - it worked nicely here but clearly wouldn't work in a more serious game.  In these cases think what the player cannot do ... if it isn't possible to swim then islands work, if the player is flying a plane then what is the effective range before fuel runs out - these create logical barriers that don't break the player's immersion in the game.     And whatever you do don't create something interesting the other side of the 'wall' as the player will probably want to pay it a visit.  Fallout 3 failed for me on this point as there simply was an invisible wall beyond which there was often something more to discover (if the radiation kept increasing until it was impossible to keep moving forwards then this would have worked and made sense to me), while I had a similar bad experience with one of the Fable games. The worst example I've seen is an impressive locked door impossible to open - I wasted hours trying to find the key, break down the door and so on before discovering (by surfing the net) that the door was just there to give the impression of a larger world.
  8.     From my experience both playing games and developing my own, this is fairly typical response.  For example I always prefer first person perspective as it is both more immersive for me and easier to control.  However, some else playing the same game might (as indicated by DavitosanX above) find a third person or isometric view better.  Could be because of experience with cameras in other games, whatever.   As a result my advice is to be flexible and probably give the player the choice.  With the ability to switch from first to third person perspective this adds a bit of work, but with care usually not too much - the camera classes I've implemented in the past are pretty compact with the only difficulties coming when I wanted to implement six degree of freedom.   Looking at your specific case the difference between third person perspective and diablo style might be very small (as small as having a third person perspective camera fixed to a predefined angle and distance from the character or scene).  Even switching from full 3D to an isometric display can be pretty simple (switching from a dedicated isometric engine to 3D can be trickier!)   As suggested try all options and see what works for the team - it may be that the prototyping may highlight one option that really gives the game the right feel - it just feels right and everyone agrees on the approach going forwards.  And if not then you have several options up and running with no need to select one or the other - this becomes the player's choice.
  9.   True ... lots of colour pictures would not be a problem  , but in describing what I am looking for as a "coffee table book" I was trying to make a distinction from the normal programming / game design books that I have scattered around my PC and that I refer to when I am working out how to code a particular element in a game.  Coffee table as in I'm not developing anything, but something I can dip into when relaxing and wanting to have a stimulating read.  I find a lot of Dev blogs and Gamasutra features interesting and I'm looking for something similar ... but with real paper involved...   For the game art I did find a general 2D and 3D book in the past (in French but called "Game Art") that had a good mix.  However, if anything I am much more interested in the 3D side of things       Thanks for the suggestion.  Will have a look at that one on Amazon and see what I think
  10. Can anyone recommend goo 'coffee table' books on game design or game art?  To explain what I mean not necessarily books digging into specific elements of a game (along the lines of how to develop pathfinding AI for an RTS game), but books looking at the higher level thought processes, philosophy or inspiration behind the overall design of a game or the art that gives a game its distinct look.  I've seen a few books that come close, but they tend to concentrate on one specific game (for instance the Art of Titanfall) and ideally I would like to find a book that case studies several different games or gets the feedback from several different 'leading light' designers and artists.
  11. This will possibly repeat some of the feedback already given but a lot of this will depend on what type of game you are creating.  If you are aiming at a flight simulator (or something close) then there a variety of maneuvers (such as the  Immelmann turn) that could be implemented (and which flight simmers would probably hope to see).  If on the other hand you are developing a real time strategy game then you can probably get away with simpler movement AI that gives the impression of real flight without overloading the processor with AI management (critical as the number of units for the AI to control in a RTS game is likely to be higher than in a flight sim).     Personally (for a RTS) I started with simple flocking / collision avoidance code (which quickly gave me something good to look at and work from) before then adding unit targeting (flight to a waypoint or target another aircraft).  From there I added formation flying (flight towards a constantly updated waypoint which is actually a position in a formation).     What really helped was having a two layer AI, the first dealing with the tactical situation (movement in the next few loops of the game logic concentrating on avoiding other aircraft and the ground, working out what is the best way to orientate towards the waypoint / target, rotating turrets and firing weapons ... oh and crashing which is fairly simple AI occasionally involving parachutes) and a higher level AI dealing with the 'strategic' situation (choosing a target or the next waypoint, responding to being attacked, deciding whether to run for it if damaged, checking if there is any fuel left, etc).  Despite taking a while to get right (and it still needs some final polishing) this two layer approach (coupled with a third, squadron level logic) really made the organisation of the AI pretty easy to conceptualise and break down.  While the AI is the big overhead in my code I can now effectively handle dogfights between anything up to (and beyond) 80 aircraft without the lights starting to flicker and brown-out.    If performance is poor there are two things that can be done,   Simplify the AI for out of sight objects (simplify collision detection or even ignore it,  don't actually fire weapons and track projectiles but just apply damage to the target, etc) - if the player cannot see the AI being more stupid then it isn't really a problem (although initially I did have problems with quick switches from one unit to another distant unit resulting in the player admiring aircraft happily flying upside down in formation ... tweaks to the simple AI and the application of a few loops worth of complex AI during the switch helped there). Only process each unit's AI every few game loops (I actually have a game setting where the AI can be applied for every unit during each and every game loop ... which is fine for higher end machines, or every second, third, fourth, etc loop ... meaning that I can effectively cut the processor overhead by half, etc ... at the cost of an increasing number of poor collision detection decisions, etc as the frequency of the AI being applied for each unit drops).  Having something playable, but not as elegant on a lower end machine is in my view better than having the Rolls Royce solution that is unplayable due to the game effectively freezing up. ?
  12. I have implemented a 3D map display for the game I am currently working on.  The map can be scrolled and zoomed as required so the player can either have a zoomed out view of the whole game world or zoom right in to get close to the action.     For the landmarks (buildings) on the map I have played around with using fully 3D models, but have eventually gone with a billboarding system.  This works great when zoomed right in with the texturing on the billboards nice and crisp with each building being surrounded with a border (worked into the texture) to maximise visibility.  However, when zooming right out the billboards obviously get smaller and the buildings more indistinct.  This is okay up to a point but one thing that annoys me is that the border around the buildings gets finer and finer until it looses its clarity.  To give an example the image below shows one building at maximum zoom and minimum zoom.     I would like to improve on this and as a minimum ensure that a clear border is visible around each building.  As an idea I am thinking about creating additional textures for use when zoomed further out, the basic texture being unchanged but a progressively thicker and thicker border being applied to ensure this.  However, before I start down this road I wanted to check if there is any alternative out there (one point to note is that certain buildings have 'cutouts' meaning that a border may be needed inside the outline of the building).   Any help appreciated ... thanks.
  13.   I have always found it easier to create 3D art than 2D art ... to the extent that when I was developing 2D games I would create models in 3D, ray trace them and then use these images as the basis for creating the sprites.  And now that I am coding 3D games the hardest bit for me in creating the art assets is the texturing of the models.     From my own experience the question is more what type of artwork do you want.  Personally I find 'industrial' art (buildings, vehicles, robots, whatever) relatively straight forward, but 'organic' art (humans, monsters, animals) more difficult (even before getting onto the not at all trivial task of animating these models).     In the end the art work and the 2D vs 3D question comes down to your own objectives and strengths and weaknesses - to start play to your strengths but also aim for something that you would find rewarding.  In my case the relative ease I found in creating 3D models (when compared to 2D sprites) plus the desire to move on from 2D to 3D led me to developing isometric games - can take out some of the pain of handling things in three dimensions while still visually ticking a lot of the boxes for me.
  14. Finally, after many days of testing I have made the migration to VS2012 .. phew!!  I won't go into all the details, but to highlight a few things that helped a lot in the process,   I actually updated the code in VC++ 6 rather than in VS2012.  To explain I went back to the original code base and tried to compile it in VS2012, recorded all the compilation errors and corrected them in VC++ 6.  This allowed me to make small step changes and check that each change worked before moving on to the next.  Meant a lot of swapping between compilers but avoided blindly correcting loads of errors and only being able to test when all errors had been corrected (basically if the code stopped working in VC++ 6 I would only have a few changes to debug). A lot of the effort was involved in tidying up the istream and ofstream handling - the standard really has changed from what I could get away with in VC++ 6 (even if, as it turned out, I could bring my code up to the standards in VC++ 6) NULL is no longer my friend ... there were a lot of instances where NULL checking had to be updated to make proper use of defined boundary checking functions. The static code analysis has been useful for cleaning up some untidy code and making things even safer, but it (obviously) doesn't spot everything and I had one memory overflow that somehow worked in VC++ 6 but choked VS2012 (as mentioned by jwezorek) In the end it was chasing down the broken class, isolating it from the rest of the code and testing and testing again until the bugs were found.   Many thanks for all the feedback - it really helped.
  15. Thanks for all the feedback so far ... much appreciated.     This is what I'm worried about!  Ideally I would like to avoid several weeks/months of debugging or recoding to bring this up to date (especially with Visual C++ 6.0 looking over my shoulder and saying "I still work!").  Anyway the process has started and I am unit testing and analysing each class ... good thing I'm not running to a deadline.     I'm already using the VS2012 static code analysis (it is available in the Express version) and this is actually one of the main attractions of moving up as it is very useful in tracking down the stupid errors that usually take ages to find.     Not any more ... or at least not worth sharing at this point.  I have a list of changes to check through in all my code and I have unit tested one of each of my std::list and std::map using classes and they seem to be clean and consistent with the current standards ... and they compile and run without any problems on their own.  Still looking for the source of the crashes but am now doing this systematically by cleaning up the whole code base rather than just trying to fix the immediate problem.  Will provide an update or examples when the current clean up is completed.