http://narmdo.com.au Software, Games + More Fri, 27 Nov 2015 08:13:09 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.23 http://narmdo.com.au/semblock-development/ http://narmdo.com.au/semblock-development/#comments Fri, 27 Nov 2015 08:13:09 +0000 http://narmdo.com.au/?p=521 facebook.com/Semblock).   Although there is no confirmed date for Semblocks release, it is approaching completion. Chances are I will do a beta release, for some final bug testing, before doing a final big release. So stay tuned! Like Semblock on Facebook, and be sure to give it a go when it comes out!]]> http://narmdo.com.au/semblock-development/feed/ 0 http://narmdo.com.au/learning-about-procedural-generation/ http://narmdo.com.au/learning-about-procedural-generation/#comments Tue, 05 May 2015 11:08:58 +0000 http://narmdo.com.au/?p=517   I've utilized the hash function in the generating of the caverns to ensure that the same structures form when revisiting chunks, and removing any need to save data about the terrain. It also provides me with the benefit of being able to take note of a seed in the case of an issue in generation, and being able to revisit that exact location to reevaluate the problem, and to see when it's fixed. If I had to search for a rare problem in the terrain every time I pressed play, there would be a lot of time wasted.   References Johansen, R. S. (2015, Jan 1) Primer on Repeatable Random Numbers. Retrieved May 5, 2015 from http://blog.runevision.com/2015/01/primer-on-repeatable-random-numbers.html PCGW (2015) Hash Function. Retrieved May 5, 2015 from http://pcg.wikidot.com/pcg-algorithm:hash-function PCGW (2015) Pseudorandom Number Generators. Retrieved May 5, 2015 from http://pcg.wikidot.com/pcg-algorithm:pseudorandom-number-generator]]> http://narmdo.com.au/learning-about-procedural-generation/feed/ 0 http://narmdo.com.au/travelling-the-generated-terrain/ http://narmdo.com.au/travelling-the-generated-terrain/#comments Sat, 25 Apr 2015 10:45:30 +0000 http://narmdo.com.au/?p=504 http://www.naturefootage.com/stock-video/ocean-underwater-video.htm I've spent some more time on bringing elements together for something playable, including the ship travelling through the generated terrains. I'm also continuing work tweaking the way the general environment looks and feels. There's been a few things which have needed to change with water, in an attempt to make it less 'boring' to put it simply. One of the techniques I've been trying out involves having randomly generated light clouds which gradually move to create a dynamic coloring in the water.   This has shown to add some more interesting features to the water, but has also brought to my attention the need for more than just creatures to have the potential to stay even after chunks have been removed. These elements will need to remove themselves, otherwise if they aren't completely within their chunk, they have a chance of disappearing while still on the players screen.   I've also been finding some chunk issues, despite having through I had cleared them all up. This is definitely within the generating of the polygons, not in the generation of the terrain data itself. I'm still looking into what the cause is, but this is quite an important issue and is currently what I am aiming to solve. (Note, I teleported the player in the image below, there's no way the player can actually spawn anywhereother than the main cavern system)       References Nature Footage (n.d.). Ocean Footage & Underwater Stock Video Clips. Retrieved April 29, 2015, from http://www.naturefootage.com/stock-video/ocean-underwater-video.htm]]> http://narmdo.com.au/travelling-the-generated-terrain/feed/ 0 http://narmdo.com.au/combat/ http://narmdo.com.au/combat/#comments Tue, 21 Apr 2015 07:19:40 +0000 http://narmdo.com.au/?p=496 Combat Units To start off with, I feel it's probably best to explain how combat units have been laid out. Each combat unit is composed of a few different components (I'll only really discuss the main ones here). Firstly, there's a core 'Combat Unit' component that all units have. This defines the 'weapons' that unit has, their health and energy stats, and a few other things. Its primary functionality is to act as an identifier for the unit and to manage its stats (other components can give it more stats to manage). Secondly, there's a 'Movement' component. The most common form of this component is the 'Biped' component. 'Movement' components control the movement and usage of skills of a unit. This component listens to the 'Controller' unit to work out what it should do. The third component which makes up a unit is an 'AnimationSet' component. These components translate the values of the 'Movement' component as to best visually represent the unit. The animation set could be swapped with any other 'AnimationSet' that supports that type of 'Movement'. For example, both Jamie and Ghouls are 'AnimationSet's  for a 'Biped'. This means we could instantly swap out Jamie to be depicted as a ghoul if we so wanted. The final component, which is provided at the start of combat and can be swapped throughout combat is the the 'Controller' this generally falls into two categories - Player input, and AI. These controllers tell the 'Movement' component what to do.   An example As an example, here's a diagram to help explain the ghoul unit: Ghouls basically follow the player around slowly and swing at them when they draw near. Upon going below 10 health however, they lose their head. To help add both humor and some element of realism to the situation, ghouls then will go into a blind state, where they wander mostly aimlessly, randomly attacking everywhere.   Jamies abilities. At the current moment, Jamie has the ability to run, sprint, dash and double jump. On the combat side of things, she has the ability to do a running stab, basic standing attacks, an upwards air swipe, and a falling ground slam.   Systems within combat Looking further into how combat works, I'll be looking at a few different parts of combat in the next couple posts. These include:

• Stats
• Input
• Skills
• Collision
• Plugins
• Backgrounds

 ]]> http://narmdo.com.au/combat/feed/ 0 http://narmdo.com.au/beginning-work-on-stats/ http://narmdo.com.au/beginning-work-on-stats/#comments Wed, 15 Apr 2015 23:46:31 +0000 http://narmdo.com.au/?p=491 This second screenshot is the first implementation of the modifier editor. It allows for formulas to be visualized in such a way  that they can also be easily modified. This is really subject to change depending on how the designers would like to visualize their modifier creation. The ability to give stats to an object and apply modifiers to them has been implemented. It's now a matter of using it more, to see where more work is necessary.     References Kaalim, L. (2015.). Submerged Pitch. Retrieved May 2, 2015, from http://submerged.submeower.info/#hazardsView]]> http://narmdo.com.au/beginning-work-on-stats/feed/ 0 http://narmdo.com.au/generating-the-map-part-2-basis/ http://narmdo.com.au/generating-the-map-part-2-basis/#comments Wed, 15 Apr 2015 23:18:30 +0000 http://narmdo.com.au/?p=484   Through the use of multiple layers and masking, quite a bit of flexibility  can be used. For example the red dots in the image below represent what could be a floor creature or plant. This was created through some random noise and masking.   Then there's a chunk renderer class. Each layer is connected to its own renderer (which would choose how to display that chunk, including what to potentially spawn in). Below is an example of the polygon renderer.     The next thing for this step was to then generate a collision mesh for that polygon data. You can see some generated collision below.   Unfortunately I'm having a lot less time to work on this as I would like, however from this point I'm continuing work on the generator, starting work on stats, and helping Matt with the movement system.]]> http://narmdo.com.au/generating-the-map-part-2-basis/feed/ 0 http://narmdo.com.au/generating-the-map-part-1-planning/ http://narmdo.com.au/generating-the-map-part-1-planning/#comments Wed, 15 Apr 2015 23:07:32 +0000 http://narmdo.com.au/?p=458 The requirements First of all the design has a set of requirements for the map generation. I'll split these into three main categories: - The cave system (The general shape of the caves) - Cave features (what makes up the caves? Static elements) - Entities (Creatures, minerals, shipwrecks)   Cave System Requirements The cave system requires a starting zone. This needs to be the highest point on the map, and essentially just be a cavern with a single exit going down. From that point, there needs to always be a wider cavern path that descends, wide enough for the carrier ship to be able to fit. This can either be one central cavern path, or it could branch off for multiple directions the player could take their carrier. Throughout the map, smaller caverns and paths are also required. Some areas of the map should be big open areas (for larger enemies). Cave Feature Requirements Caves will needs to have features such as underwater currents, air pockets and destructible terrain. These elements will need to be very carefully placed as they, if generated badly, could potentially put the player in a situation where the game is actually impossible for them to continue (and have it not be their fault) or make it too easy. For example, if all air pockets happened to be at the end of longish tunnels, the player would have to spend a huge amount of time going to each of them, thus making the game irrationally unfair for them. Entities Simply from taking note of the fact that entities (and those cave features) will be a part of the map generation makes it pretty clear that the map generation should be written in such a way that elements can be easily tweaked individually (commonness, enabled/disabled, size, etc.). This basically involves almost everything else that will be found in the game.   The current focus The current focus is actually creating a system that is easily expanded upon. While working on this, I will predominantly be focusing on the cave system category.  ]]> http://narmdo.com.au/generating-the-map-part-1-planning/feed/ 0 http://narmdo.com.au/blog-8-implementing-the-trigger-system-visuals/ http://narmdo.com.au/blog-8-implementing-the-trigger-system-visuals/#comments Fri, 27 Mar 2015 00:41:23 +0000 http://narmdo.com.au/?p=467 Making the process of creating triggers visual! To help the designers have less of an annoying process as they go about designing trigger sequences, I've implemented the visual system I talked about two blog posts ago.   The first step was to make it much easier to add in triggers Through a custom window, we can now easily search for and add in new triggers. Icons are searched for in an attempt to help easily identify triggers. The triggers are located by searching through the project assembly, so any newly written triggers will automatically be added to the window.   Next step - Easily connecting to characters, quests and items Characters, quests and items will now be connected through the concept of pointers, which allows us to easily refer to them regardless of location on the map.   Lots of gizmos for triggers Every trigger has been given its own gizmo, and in relevant situations, triggers will also have sub gizmos to the left and right. Here are some of the triggers: And lines Although colors changed a bit after this next screenshot (see the images after), you can see that lines have been used here to show which character pointers have been associated with each dialogue box. You can also see that given a dialogue is selected,  it's details have been shown in the pop up inspector. You can also see that 'Link' buttons have been provided (the functionality of which you'll see later). Linking! As seen in the previous image, there's link buttons to link objects together. Once one of these buttons are clicked, all objects in the scene that match that type are highlighted with a blue circle. Clicking on one of these objects will now link it. This allows designers to really easily link characters, items, quests, trigger links and more into the triggers.   Line Colors As mentioned the line colors did change, as you can see in the image below. As a final example, let me explain what's going on in the sequence below: - Jamie says something - Mum says something - Jamie says something - Mum says something - A random path is chosen Path 1: - Mum says something - (merging paths) Mum walks to a location Path 2: - Mum says something (else) - (merging paths) Mum walks to a location   Or in simple language, after a short conversation, mum finishes with one of two possible endings, and walks away.  ]]> http://narmdo.com.au/blog-8-implementing-the-trigger-system-visuals/feed/ 0 http://narmdo.com.au/blog-7-planned-improvements-part-3/ http://narmdo.com.au/blog-7-planned-improvements-part-3/#comments Thu, 26 Mar 2015 22:59:26 +0000 http://narmdo.com.au/?p=465 Combat The combat system was shown to need a fair few improvements. The gameplay and 'feel' was very rigid, and we still had no real example of either combat or AI, as the combat sequence in the demo was very scripted. With some reallocation and rethinking of how things will be done, hopefully we'll see an improvement here. Overworld character art It became noticeable that there was a clash in art styles between the overworld characters and the overworld tile assets. To solve this, we decided that new character art would be done.   Conclusion It was really good that we could smash out the demo so that these sorts of issues could be brought to the surface.]]> http://narmdo.com.au/blog-7-planned-improvements-part-3/feed/ 0 http://narmdo.com.au/blog-6-planned-improvement-part-2/ http://narmdo.com.au/blog-6-planned-improvement-part-2/#comments Thu, 26 Mar 2015 22:39:26 +0000 http://narmdo.com.au/?p=463 The trigger system The trigger system we had implemented was proving to be a glimpse of something nice. And by that I mean our list of (quite a few) triggers was quite well done, with complex cut scenes being able to be defined through each of these trigger modules. The problem wasn't in the concept, nor really the gameplay implementation. The problem lay on the editor side of things (which I'm hardly surprised at, given everything was running simply off Unity's default inspector). The triggers also became an absolute nightmare in the Hierarchy window, with each of us having our own opinion on how they should be laid out. Triggers were connected to triggers on the other side of the map, most things were just blue boxes to represent things, and even simply defining who says something in a dialogue trigger took longer than it should. The fix? Luke, J'Jay and I worked on establishing what J'Jay and I could do for the designers to make this system as neat and easy to use as we could. We wanted to stop it being a time sink, and make it as enjoyable a process as possible. Our conclusive system involved a fair few changes. Firstly, an implementation of the concept we called 'sequences'. Sequences are a set of triggers that define a  small area and situation in the game, for example there would be a sequence for Jamie's first interaction with mum, then a sequence for the first time she walks into the lounge room. These sequences could be added and removed from the game world, and could include trigger areas, character spawners, interactables, and of course other triggers. J'Jay has been allocated to putting together this system. Secondly, the entire trigger system needed to become a visual, intuitive and easy experience. With gizmos for triggers, lines connecting things and an easy way to connect various elements to other elements. Our decided system would look like the image below. When a trigger isn't selected,  the improved inspector box would be hidden. The main trigger gizmo would be determined by the trigger. The left gizmo would represent what is acting for the trigger (a character for example for dialogue), and the right gizmo is the target for the trigger (for example a destination for a walk to).    ]]> http://narmdo.com.au/blog-6-planned-improvement-part-2/feed/ 0