• Advertisement

Jon Alma

  • Content count

  • Joined

  • Last visited

Community Reputation

413 Neutral

1 Follower

About Jon Alma

  • Rank

Personal Information

  • Interests
  1. COG - Map Streaming

    Update time again ... recent work has concentrated on polishing and debugging code linked to map or level streaming. As previously mentioned instead of discrete levels the world is one continuous entity which is loaded on the fly ... basically there is a 3x3 grid of map sections loaded at any one time. When the player moves from one section to another the game loads the sections needed and cleans up the map sections no longer in use. Simple in theory ... but a little more complex in practice. The first issue was linked to the player revisiting map sections. Here the concept of persistent game objects was needed. To give a simple example, imagine a player collecting a coin and then wandering off to explore a different part of the world. The map section is cleaned up and the coin is forgotten. Later the player comes back, the map section reloads and the coin is recreated - and the player gets even richer. Making the coin persistent (where it is never forgotten) means that once it is collected it cannot reappear. That's a low impact example - more complex examples include moving objects (if a lift moves to a certain floor and stops then it should be at the same floor when the player comes back), switches and doors (an unlocked door should remain unlocked) and finally monsters (if it's dead then it should stay dead!). Without keeping a track of these would result in certain parts of the map becoming blocked off and inaccessible to the player. Then to add another layer still, I needed to consider what would happen if a player does something (for example activates a lift) and then dies. When the player respawns should an object be persistent or not? This has involved changes to the respawn process (it now needs to be a full game reload rather than a simple move of the player back to the last respawn point). All of this was a fairly predictable aspect of the map streaming system. Something that was much harder to narrow down and deal with was the collision detection. To give a bit of background every game object (wall, coin, lift, platform) may have a series of collision polygons to identify where the player and monsters can move, where they can't, where they will be moved automatically (on conveyor belts for example) and where they will trigger some kind of event (collect an object, trigger a switch or another event). The result is as shown in the screenshot below (to the left is the normal game view, to the right the debug view with collision zones highlighted). The tricky bit ... objects are linked to map sections and the collision detection code iterates through the different map sections to check for collisions (there are probably better ways to do this but the collision code is the bedrock of the whole game, implemented early on and not easy to change). In general this works fine - the object is fully in a map section, the player or monster in the same map section and the collision detection works a dream. Unfortunately there are certain objects that slightly overlap the edges of a map section - bridges are a typical example of this where effectively the bridge links one map section to another. To deal with these cases I had the choice of always making sure objects didn't overlap ... which would lead to restrictive level design or update the code to handle overlaps. So I updated the code and it worked fine 99.9% of the time. Unfortunately occasionally it would break (anywhere on the map when objects overlapped in a certain way) and the collision detection would effectively switch off and the player would fall through the floor. Eventually after a lot of debugging the source of the problem was found – the overlap checking where, for some reason, I had got distracted and forgotten to add the last two lines of code. Two lines, probably 20 characters missing and as a result probably 2 weeks of on and off debugging … sometimes I need to be reminded why I enjoy developing games
  2. Time for an update. So what have I been working on in the last couple of weeks? Firstly the lighting and particle systems are activated. The particle system is pretty unintrusive with the most notable aspect being the chimney smoke rising from the different steampunk engines. Alongside this there is now a bit of splashing water and a few sparks flying around. Much more noticeable is the lighting system as demonstrated in the new screenshots. Here there is now a day / night cycle - I spent quite a long time making sure that the night was not too dark and I already have a game setting allowing this to be turned off (while this will lose a lot of the atmosphere just having day light slightly improves performance ... no other lights need to be active ... and maximises visibility). Introducing other lights was a bit more problematic than expected. Firstly, it took a while to get the light fall off fine-tuned correctly and secondly I upgraded the code quite a bit. Originally, the light manager would always choose the lights nearest to the player, meaning that a maximum of 7 lights (beyond the sunlight) could be active in any scene. Okay, but it did mean that more distant lights would suddenly flick on. The new logic activates lights nearest to each game object or map tile currently being drawn, allowing a much greater number of lights to be shown in any scene. In general the list of lights to activate are pre-calculated as each map section is loaded, with only lighting for moving objects being calculated on the fly. So far seems to be working nicely - if I overloaded a particular area with lights there could still be light pop-up, but with sensible level design this can be avoided. I did consider pre-baking the lighting but with the day/night cycle and the desire to alter light intensity and even colour on the fly this was going to be too complex and the performance of the current solution seems to be very good. The other task I've been working on is the introduction of two new map zones. The objective was to introduce something distinct from what had been done so far and to this end I have been working on a wilderness and an industrial zone. And the wilderness zone completely failed to work. It's a beginner zone so there wasn't any intention to overload it with complex gameplay, but even so it's just empty and uninteresting - back to the drawing board on that one. As for the industrial zone this one is going better. There are a number of new models being used and a few more to add with a couple of objectives in mind. First off the aim is to create a little bit the confusion of a steampunk factory - pipes, big machines, smoke and steam. Secondly, to hint at the down side of (steampunk) industrialisation with the texturing more grimy and even the addition of waste stacks (handily blocking off the player's progression requiring them to navigate their way round more carefully). An early draft is shown in the screenshot below - the ground texturing needs to be changed with green grass needing to be replaced by rock and sand and I will also be working on the lighting and fog - to draw in the view and create a darker scene even in the middle of the day. The scene may be a bit too busy at the moment, but I will see how I feel once these changes are made. Hope the update was interesting - as before any feedback most welcome.
  3. First Dev Update - Introducing COG

    Glad you like the art style - I'm trying to avoid being too cartoony while still having something colourful and sharp. And as the whole project has been an exercise in 'comfort food' development with a lot of elements pulled out of games I've enjoyed playing in the past I'm not surprised there is a sense of nostalgia. With the drawing distance this was initially driven by performance assumptions with short drawing distances helps keep the frame rate up in an amateur game engine. However, the game is still managing a very healthy frame rate even in the most packed areas so I could increase the drawing distance a bit. However, the limited visibility gives a bit the feel of foggy/smoggy Victorian England and the smoke of the industrial revolution - quite appropriate for the game. As such, I'm planning to leave it pretty much as it is, possibly only pushing out the draw distance a bit when the player is in open countryside (where the scene density is lower in any case so performance would allow this). I may even experiment with bringing in the fog a bit in certain factory zones where monsters could pop out of the thick smog to attack the player. The game engine is actually the same one so there is a lot of potential in this direction. Indeed the ability to steam a seamless and in theory endless map rather than discrete levels comes directly from the RPG game. I am also already using the scripting code to handle more complex puzzles and I plan to use elements of the dialogue system for a bit of interaction between the player and other characters in the game. However, I would make a distinction between creating an adventure game (where there is a story that unfolds) and a RPG game with a bundle of quests, loads of stats and a lot of very diverse game content - being a team of one, working on a RPG game was eventually overwhelming. It wasn't from creating the game engine, but from populating the world ... spending a weekend writing the contents of books that the player may possibly read or debugging a quest that keeps breaking limits the speed of any progress. Even with a 'lighter' game it still takes a couple of days to create about 5 minutes of gameplay (what with the initial level creation, tweaking and then the testing). I'm very wary of falling into the same trap of over ambition. There are a couple of games that have been sources of inspiration for this project, these being Oceanhorn and particularly Hob - both have the platformer / puzzle elements combined quite nicely with adventure / RPG elements and both worth a look if you like this mix. Another mad person It's something I enjoy doing and a nice way of relaxing after the day job. A couple of years ago I had a go using the Unreal Engine and while the engine was clearly much more powerful (no big surprise there) it didn't give me what I wanted and I found myself fighting with the engine rather than enjoying the development process. And there was a real loss of the sense of achievement for me (yeah that worked ... because I'm using UE). So it was back to the home grown engine and the process of reinventing the wheel It started with the idea that I wanted a short name for the main character. With the steampunk theme and lots of machinery I eventually settled on Cog (the player being one cog in a bigger machine). And then after thinking about an eventual title screen I quite like the idea of each letter in the name itself being a cog ... which would be easier to do with capital letters Thanks for the feedback - much appreciated.
  4. In hopefully the first blog of a (fairly!) regular series I would like to introduce the game I've been working on for a while now. With a working title of COG, the game is a 3D action adventure game with a Steampunk theme and strong platformer elements. This is very much an indie project ... the coding of the home grown engine is done by me, the 3D modeling is (largely) done by me, the level design is done by me and ... well you get the idea! About the only support I'm getting is from my kids who are doing the 'QA' (and who are super critical when something doesn't work!). So where am I with this project? The game engine itself is pretty much 'feature complete' and the game playable even if there is still a lot to do in optimising and polishing the different components. Most of the standard platformer elements (conveyor belts, lifts, moving platforms, spike traps, switches, etc, etc) are already working and available through the level editor with the 'levels' (more accurately map sections) loading on the fly to create a continuous, seamless world. Basic monster code is already in place with it being pretty easy to add new monster types as needed for the game. The lighting and particle systems are currently being reintegrated into the game (the code is complete, but was deactivated while creating the first builds) so hopefully the landscape will soon be full of splashing water and rising steam and smoke (pretty important to have rising steam in a steampunk game!). The camera system is nearing completion - it allows the player to have full control of the angle of the camera with objects close to the camera position fading out to improve player visibility (this is the last bit being worked on here with the drawing order of semi-transparent buildings being tightened up and optimised). Looking at the content there is currently some placeholder content being used with the worst offender being the player's character which is currently a (not very steampunk) Kiwi rather than what will eventually be a small robot. In addition, while the 3D models are almost all self created, the textures used are a mix of those I've created myself, that I've purchased and a handful of temporary placeholder textures. These placeholders have allowed for rapid prototyping (especially as creating textures is a slow and painful process for me), but will obviously need to be replaced in the near future. Fortunately this shouldn't be a huge task as I'm using texture atlases that allow for easy swapping in and out of new textures ... there should be relatively few cases where it may be necessary to tweak the texture mapping. For information the screenshots and video contain this placeholder content. As a result of all this there is now quite a nice library of 'Lego bricks' available including a range of basic building blocks (platforms, towers, walls, pipes, etc), more exotic props (the already mentioned spike traps, barriers, lifts and switches as wells as the mandatory barrels and movable crates), plants, rocks and other landscape elements. Finally, there is a series of animated models including waterwheels, steam engine, pistons and so on whose clanking and whirring will helpful give the impression of a living world around the player. So things are going pretty well at the moment (especially given the limits on the time I can devote to this) and COG seems to be getting to a stage where it is moving from a process of writing code to one where the current task is to complete the game - a pretty rare thing for me! Please let me know you think of the screenshots and video - one of the main reasons for starting this blog is to start getting some feedback to help shape the remainder of the game ... all constructive comments would be very much appreciated. Also if there is interest in a particular aspect of the game development process I would be happy to share more details in a later blog entry. Thank you for your time!
  5. 3D Billboarding between two points

    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?
  6. 3D Billboarding between two points

    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.
  7. 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.
  8. Where can I get this type of models?

    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).
  9. Radio Chatter and Computer Voices

    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!
  10. 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.
  11. map borders in an open world game

    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.
  12.     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.
  13. Coffee Table Game Design / Game Art Books?

      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
  14. 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.
  15. Fighter control system

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