Jump to content
  • Advertisement

Jon Alma

Member
  • Content count

    116
  • Joined

  • Last visited

Community Reputation

415 Neutral

1 Follower

About Jon Alma

  • Rank
    Member

Personal Information

  • Industry Role
    Game Designer
  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's been a while since the last update so time for a bit of news. Looking first at the game engine changes have been made to improve player movement with it now being possible to run or walk - when dodging traps running usually helps, but the player can reduce movement down to a crawl when trying to avoid falling off narrow walkways. Next up was the introduction of more content into the game. The map is constantly expanding in size with the general approach being to have one 'story path' across the map with frequent branches allowing the player to discover additional puzzles and rewards. In addition I've been creating additional building components to add a bit of variety to the different zones around the map. Of most note is the creation of a set of modular components that can be combined to create 'Donkey Kong' towers (several towers linked together by walkways, lifts and so on). Finally, I've reintroduced creatures into the game - with the final game map taking shape it's been possible to add creatures to each zone and really test them as part of the proper game (rather than in a sandbox environment). As a result of this I'm currently fine-tuning the AI to improve navigation and ensure that creatures do not chase the player endlessly across the map (this either ends up with long streams of creatures all chasing the player or Lemming like behaviour where the AI can't cope with certain areas and the creatures take suicidal jumps off bits of scenery) However, most attention has been placed on creating the character models. First step was creating the models themselves and for a while whatever I did just didn't seem right for the game. Eventually I came to the conclusion that the models were all too thin and tall - it was difficult to see the models clearly without zooming in too much and zooming in changed the feel of playing the game. Consequently I tried removing the knees/lower legs and wrists from models while bulking out the rest of the mesh a bit. Result is that the models are much more visible and to scale with the rest the game world. Next step was the texturing ... as mentioned in a previous post this is not a strong point for me, but I've finally (and painfully) managed to get to a point where the textures are good enough and I can move onto other stuff ... for the moment. Finally I've been working on the character animation. As the overall objective is to have a light and fun atmosphere to the game I'm over exaggerating the animation a bit with movement being slightly 'bouncy' ... at least compared to the more 'serious' games I've worked on in the past. To give a couple of examples the screenshots above are of the main character (COG) and a Gardener (a low level creature the player will encounter in the early part of the game). The idea isn't to create Steampunk robots but slightly worn out robots that have built the Steampunk world around them. Both images are taken from in game - an additional problem I had when working on the texturing is that what looked okay in a 3D modelling app (typically something with 'busy' texturing) wouldn't look at all the same in game (where simpler texturing as shown here actually works better). Feedback obviously welcome.
  2. Jon Alma

    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
  3. 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.
  4. Jon Alma

    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.
  5. 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!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!