Jump to content

  • Log In with Google      Sign In   
  • Create Account


Jon Alma

Member Since 24 Sep 2002
Offline Last Active Yesterday, 08:44 AM

Posts I've Made

In Topic: map borders in an open world game

08 August 2014 - 05:58 AM

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.


In Topic: 3rd person camera versus Diablo III style camera

10 June 2014 - 09:30 AM

 

We are 6 people and 3 want 3rd person and 3 want diablo style. 

 

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.


In Topic: Coffee Table Game Design / Game Art Books?

02 May 2014 - 07:23 AM

Um, I'm fairly sure a "coffee table book" is one that's intended to look nice, generally having a fancy cover and lots of color pictures; that's rather different from your description of what you're looking for.

 

That said, most of the good written works about game design are only available in digital formats; few of them are available as paper books.  I have like 2 paper books on game design topics, and neither of them would I particularly recommend.  I've got lots of art books I'd recommend, but none of them are specifically about games.  "Game Art" as a topic is too broad to effectively write a book about; at the least you'd probably want to narrow down to 2D or 3D.

 

True ... lots of colour pictures would not be a problem smile.png , 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

 

 

I've found The Art of Game Design:  A Book of Lenses to be immensely helpful, and possibly within the scope of what you're looking for.  

 

Thanks for the suggestion.  Will have a look at that one on Amazon and see what I think


In Topic: Fighter control system

06 November 2013 - 07:24 AM

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.


In Topic: 2D vs 3D for a solo programmer

28 May 2013 - 05:15 AM

I find that when it comes making art, 3D has a steeper learning curve. MS paint is much easier than any 3D art package, but once you learn 3D, it becomes much easier. As to the poster's original question, to make a game quickly, I feel that 2D is easier. There's just a lot to learn when it comes to 3D.

 

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.


PARTNERS