Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

695 Good


About JEJoll

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

5495 profile views
  1. Hey. Just tried the game briefly. Unfortunately, I have a pretty low end device (it's an LG4K), so the game was pretty much unplayable. I was seeing framerates under 10 fps consistently. Given what I did see, the game looks really cool visually. I'd love to hear about how you accomplished the warping of the grid. I really liked that. I might give the game another shot on an emulator on my pc or something later. Best of luck!
  2. Originally posted on FidelumGames.WordPress.com Version Control Commit Comments In my last post, I said that I hoped my blog posts would start getting more frequent. That was over a month ago 😐 But that doesn’t mean I haven’t been working on things, I just don’t have anything new that’s super interesting and warrants a blog post. However, I really want to make these posts frequent and keep everyone who’s interested up to date on what’s going on with the game’s development. Because of this, I’ve decided that between meaty, interesting posts, I’ll simply post each of my version control commit comments as I make them. I figure this will keep the posts coming, give you all a sense of what I’m working on and what I’ll be working on next, and provide some insights into the minutia that come along with game development. I set the current repository up fairly recently, so there aren’t a ton of commits as of yet, but here is a dump of all of the currently existing comments: 8/29/2017 4:06 PM – Initial Wayfarer project commit 10/23/2017 5:08 PM – Milestone #1 Commit – Stable, first feature set complete. 11/4/2017 9:29 PM – Updated GDD with Overview and Implementation algo for player combat (attacking and spellcasting). 11/9/2017 11:24 PM – Added basic player attacking functionality, as well as initial defense and dodge calculations. Player’s EndTurn, when striking an enemy, is now called by the enemy being hit after its animation is done playing. The next step is to do the same for when the enemy strikes the player. Noticed two bugs: Player gets his turn back too often, and the enemy calls TakeDamage on itself when casting a spell on itself which inflicts damage (Blood Magick). Need to figure out why the player is able to act so frequently, and change how self-injuring spells subtract health from the caster (another function, or maybe a flag to the existing function). These two issues are probably related. 11/11/2017 11:38 PM – Fixed bug where player could attack too frequently. Also modified Stats.TakeDamage to have an optional paramter shouldPlayTakeDamageAnimation (or something like that) in order to prevent self-damaging spells (blood magick) from triggering the take damage animation. 11/14/2017 1:29 PM – Basic functionality for both player attacking and spellcasting is complete. Still have to add some tweaks for reactive animations and turn ending when an actor is hit by a spell. 11/15/2017 12:13 AM – Added target effects for spells which have an immediate effect. Added additional EndTurn triggers to handle these. From what I’ve tested so far, all cases where the player attacks or casts a spell on an enemy work as expected. Next thing that needs to happen is enemy death. The dissolve assets have been brought back into the project, and just need to be called when the enemy dies. After that, adding reactive animations for the player when a spell is cast on him, or when he is attacked (dodge, get hit, etc.), and ensuring those reactive animations trigger EndTurn in the correct Enemy. This will probably be in TakeDamage(since it has a reference to the Stats of the attacker anyway). 11/16/2017 11:20 PM – Death animation now triggers dissolving. Found a bug where an enemy gets an extra turn when taking damage. Dying doesn’t occur as expected. Fix this. 11/20/2017 10:08 PM – Fixed some problems with turns ending at the incorrect times/too many times caused by some poor logic in SpellManager. How spells work and the exact point at when they have their effects applied, as well as when turns are ended has been more tightly defined. All callbacks from animation events triggered by spells or attacks targetting the enemy are working as expected, with the exception of Healing spells. This is because of the current AnyState->AnyState transitions used in the animation controllers and the close proximity of the Heal Casting animation and the Get Healed animations being triggered. The state instead transitions right from Heal Casting back to Idle. Because of this, the animation state machine will have to be more properly arranged. Once this is done, callbacks for when the player is the target of spells need to be added (none are done). Also, these animations will have to be set up for the player (mostly utilizing iTween). Even though all of the spell stuff is mostly working well, it just doesn’t feel right, and is a likely candidate for redesign later. 11/21/2017 10:15 PM – It seems that all callbacks for both the enemy and player are complete for all permutations of both self inflicted and opponent inflicted effects (Damage, healing, status effects, etc). This also takes into account and plays the appropriate animation for affinity to magick types (having greater than 100% fire defense will heal instead of hurt the attackee when a fire spell is cast against them). Of course, all graphics, vfx, and animations are currently placeholder, but it seems that the code is solid and complete. In order to accomplish this, the enemy animator has been totally revamped. Still have to test more thoroughly (with multiple enemies, additional spells, active combat mode, etc.) Have to perform clean up on some unused animation boolean sets in code. 11/22/2017 10:01 PM – Milestone#2 complete! Player actions are working perfectly and complete combat cycles are able to be completed with either the player or enemy being defeated. Player is able to attack and cast all spells, although no mechanism to change equipped spells or weapons currently exists (except for through the editor [weapons cannot be changed at all]). One small bug still exists where the Enemy is able to cast some ranged spells when not in line of sight of the player. It seems only range is being taken into account. This should be an easy fix, and not something I’m currently worried about. One small fix was made to a bug where the player would become misaligned with the grid if attempting to move while a player animation was being played (dodge, damage, taunt). Tests with multiple enemies were successful as well. Need to decide what Milestone#3 will be: UI Design seems like the most reasonable candidate, as this will lay the style and determine the framework for most of the systems to come (inventory and player management, including weapon/equipment management and equipping, spell selection, and levelling up as well as all other core gameplay areas including dialog, quests and pretty much everything else to come). Paralysis by Analysis Things have been moving slowly lately. The game is at the point in its development where things really can’t progress until some UI has been put into place. The player is able to both attack and use spells, but there is no in-game mechanism by which to switch spells or weapons (the spell system, as I’ve mentioned before is done, but the placeholder weapon is purely superficial; it doesn’t affect stats or combat at all.). Because the AI and base player combat mechanics are complete, it seems the best thing to start next is looting and inventory management. This will range everywhere from the player looting enemy bodies (or bags dropped–not sure how I’ll handle it yet), to changing equipment, spells, etc. I could write the back-end for this stuff, and just switch things out in the editor for testing, but it seems the best way to progress is to at least have some idea of what my UI will look like and how it will function so that I can best design the code. This is where I’ve been having difficulty. The only other game I’ve completed to date was a single screen 2D shooter called ‘Pixel Zombie Shooter’ (you can play it on Newgrounds), and it had a pretty minimal/simple UI. Needless to say, I have little experience when it comes to UI design, and I’ve been struggling to figure out what would best suit The Wayfarer. So far, I’ve completed a ‘mock up’ of the main game’s UI (the one the player sees during combat and exploration). Have a look: Before I get into my major complaints and problems with this mock up, I’ll explain what you’re looking at first. The items along the bottom (red and blue orb, bottom-most panel buttons and two circular buttons to the right) are always present. The panel containing the potions slides up from the bottom when the red portion of the orb is clicked and held, or when it’s right clicked. It’s intended to be a quick access menu showing only items that will heal the player. A similar panel would appear containing mana-restoring items, equippable weapons, and spells when the blue portion of the orb, the sword or the fireball looking button are clicked and held or right-clicked, respectively. Basically, I wanted to give the player automatically filled quick-access buttons for commonly used items (health and mana items in particular), as well as a quick way to change spells and weapons. I think this is a pretty good design functionally, and would help alleviate some of the pain of navigating through tons of menus that is so commonly associated with RPGs, but I’m not sure if I’ll stick with it or not–simply because I think it’s a bit of an unconventional and nontraditional design that might not be intuitive enough for players. (Psst: I’d love to hear some feedback.) On top of having the ability to display these quick-access menus, left-clicking on the red orb would automatically use the healing item best suited to the player’s current health (healing as much as possible without wasting the item’s healing potential). The same thing would occur with the blue orb, but for mana. The sword and spell icon would simply attack with the current weapon, or cast the most recent spell, accordingly. The icons along the bottom, from left to right, would allow the player to: Access their inventory Access their character Screen Access the map Access spells Access quests Rest Access the settings/pause menu Of course, each of these functionalities will also be able to be performed with shortcut keys (‘I’ for Inventory, ‘R’ for Rest, etc.). In the end, nine of these eleven buttons (all but the health and mana buttons) are ultimately redundant because their functionality will be duplicated with key presses. However, I think the benefit of intuitively letting the player know the functionality exists by showing it up front and center probably warrants their presence. Again–we’ll see. Now for the problems I have with this so-called ‘mock-up’ (perhaps a mockery of a mock-up is a better description). First of all–just look at it. While it’s not perfect in its appearance, it looks pretty damn close to a polished UI. The problem with that is that it’s a mock up. It’s not supposed to look polished. While I did do some pencil and paper experiments first, I think I spent too much time making it look good, and I think that’s a bad thing–at least for this stage of development. I should be focusing on layout and functionality, not final appearance (although that’s probably a good thing to keep in mind while designing). While the mock up you see above only took me a couple of hours total to put together, it caused complete paralysis when it came time to design my next UI (specifically my character equipment screen). I started drawing stuff on paper, then went on to photoshopping, but ultimately wound up with nothing. My mind was too all over the place. Something like this went through my mind: Diablo II Equipment/Inventory/Character Menu The Quest Inventory/Equipment Menu Although I have a pretty solid overall vision for the game’s theme, look and feel, there are still a ton of unknowns. It was at this point that I fully realized that really, I’m still prototyping. Rather than trying to make all of these decisions during design, I need to be doing some bare bones experimentation to see what works and what doesn’t in order to make my decision making part of the design process. So, rather than developing further semi-polished mock ups like the one I’ve already made, I need to have some super basic black and white boxes with text instead of images for buttons, etc. I need to be rapidly prototyping, testing, scrapping and refining these UI menus directly in the game (maybe some quick pencil and paper first). I think I need to make a UI for each of the questions I’ve been asking myself and actually trying it out, instead of just trying to imagine the pros and cons of each. I need to test each one (and hopefully, get some others to test them too). Ultimately, even if I’m not able to make some final UI decisions right now, I don’t think it’s a big deal. I just need to get something relatively close to what will work best so I can move forward with developing future mechanics. There will be lots of time to revamp the UI later if I need to. That’s it for now, and please, if you have any feedback or critiques, share them!
  3. NEW MUSIC (OBSCURITY) Originally posted on FidelumGames.WordPress.com on October 1st, 2017 Here comes Obscurity! This was the first song I made for The Wayfarer. I actually did intend to do something a bit (a lot) brighter, but at times you really can’t really control what comes out. And since I liked how it sounded and felt, I kept doing it until it was ready. And I’m glad I did. If all goes as planned, during the next week I should be getting a new pair of stands for my Behringer Truth B2030A monitors. After that I can direct these studio monitors correcly, which should have a positive impact to mix quality. For now they have been positioned strongly asymmentrically, so they are next to useless during mixing, and 99% of the work has been done with headphones. That 1% is the last rouch check if there are any frequencies that come through in piercingly strong way. Can’t wait to have them. BR Mika Pilke HURRAH! MILESTONE #1 REACHED Originally posted on FidelumGames.WordPress.com on October 13th, 2017 First off: YAY! I’ve reached my first major milestone in the development of The Wayfarer. My enemies (as far as behavior goes) are complete! They still need to be replaced with proper models and given the ability to die (along with dropping loot, etc.), but all of the AI and related systems are complete and, as far as I can tell, mostly bug free. I think that, in order to stay motivated, it’s important to celebrate these small successes, so last night I had a few drinks, and today I’m writing this post and giving myself a pat on the back (good job, me). So why did I decide that this was my first major milestone? In my development experience thus far, one of the hardest and most frustrating things I’ve found is the difficult and delicate act of creating and maintaining complex interconnected systems. All of the individual items I’ve completed so far for my enemies (attacking, spellcasting, navigation, stats, decision making, editor tools, etc.) have not been overly difficult to implement individually. Sure, there were some challenges, but nothing too major. The real challenge is making all of these things fit together in a way that they all still work, and doing so in a way that makes sense and doesn’t cause terror when thinking about having to change something. The reason I’m considering this to be my first major milestone is because all of the features mentioned above, even though they’re all individual systems, are now combined into a larger closed system. This means that I know each individual system works, and I know they all work together, and the stress of having to make that a reality is gone! Moving forward, I can start working on smaller systems again (like player actions, looting, inventory management, levelling, etc.), which is a quicker, simpler and more carefree process than integrating said systems. Of course, once those individual systems are done, I’ll have to integrate them into another closed system, thus reaching another milestone. But, to keep myself realistic, and to prepare myself for the difficulties to come, I do realize that once ‘closed’ system number two is complete, I’ll have to connect it to closed system number one. I have no experience working with systems on this scale, so this is a huge learning experience for me, and I don’t know what to expect. Part of me is expecting the worst, another part is optimistic and hopeful that I’ve paid my dues in terms of keeping the code clean and sensible, and should reap the benefits when the time to integrate comes. Anyhow, I’m super pleased and happy at the moment, and can’t wait to start working on new features again. Hopefully things go smoothly for the next little while and these posts will start getting a little more frequent. This was a huge hill to climb, and I’m glad to be at the top of it (even though I can see the top of the much larger hill in the distance). SQUISHING MAGICAL BUGS During most of my last five or so development sessions, I felt I was making very little progress. I had my spell system pretty much complete, but the process for creating new spells had become too in depth and complicated, so I had to redesign some things and make some pretty major changes. Originally, I had been using ScriptableObjects for my spells, and while it was cool, and made me feel like a ‘real game developer’ to be able to create a spell by clicking Asset>Create>New Spell in the Unity editor, it just wasn’t practical for my purposes. I wound up sticking with trusty ol’ prefabs in the end. While the new system isn’t as generic as the old one (visual effects are now part of the actual spell prefab), it’s much more friendly and maintainable, and I’m able to create new spells in a matter of just a minute or two (not counting VFX creating time). Reworking this system was fairly straightforward. What really sapped my motivation and frustrated me was a bug that I just couldn’t squash. Many of the spells in the game will apply buffs to the caster, or to the caster’s enemy. These buffs have the ability to fortify or weaken any stat that exists in the game, and, when being used by an enemy, who the buff is being cast on (self or enemy), is important. I’ve designed my AI in such a way that, after it has decided to cast a spell, it chooses one at random, filtering out any spells that aren’t available to be cast. I’ve defined a spell that’s unavailable as one which: Has a range less than the distance between the caster and the target Costs more mana than the caster has available Added a buff to the caster which is still active The most important item on this list, in terms of the bug I’m about to describe, is number 3. I don’t want my enemies ‘wasting’ a turn by casting a buff on themselves which they’re already benefitting from. However, enemies are fully ably to cast the same buff on the player multiple times. The caveat with this, however, is that I don’t want multiple buff casts on the player from the enemy to stack. Instead, I want a re-casted buff to reset the remaining turn duration of the buff on the player. The exact opposite was happening–the buff was stacking leading to a spell which should cause a -2 to strength to be able to cause a -10 (or whatever other number) instead. Additionally, this was causing the player’s stat to increase when the buff wore off. This was a relatively small bug, but it drove me absolutely bonkers. Like I said, I spent somewhere around five sessions trying to fix it, getting little else done. Here’s the original method which caused the problem: public void AddActiveBuff(Spell spell) { foreach (StatusEffect buff in spell.StatusEffects) { if (!IsBuffActive(buff)) { activeBuffs.Add(buff, spell.Duration); stats.AddStatModifier(buff.stat, buff.amount); } else { activeBuffs[buff] = spell.Duration; } } } Can you spot the error? I’ll give you a hint: I use a Dictionary to store my activeBuffs, where they key is a StatusEffect object (the contents are unimportant), and the value is an integer representing the number of turns remaining for the buff. I fiddled with this friggin’ thing forever. I changed how I stored my activeBuffs, considered adding some polymorphism to my Spell class, creating multiple arrays to store the data–all kinds of things. In the end, I commented out a single line on a whim, and found the problem: public void AddActiveBuff(Spell spell) { foreach (StatusEffect buff in spell.StatusEffects) { if (!IsBuffActive(buff)) { activeBuffs.Add(buff, spell.Duration); stats.AddStatModifier(buff.stat, buff.amount); } else { //activeBuffs[buff] = spell.Duration; } } } Yep. One line of code. Seems to always be the cause of these tricky bugs. Because my spells are prefabs, the StatusEffect objects attached to them are instances belonging to the instance of the Spell when cast. Therefore, because the key in my activeBuffs Dictionary is an instance of a StatusEffect (something I overlooked, foolishly thinking that two separate but identical StatusEffect instances would be equal), I was adding a new entry to the activeBuffs Dictionary with the above commented line, rather than just resetting the duration of the existing entry. Of course, when I discovered this, I shook my head, and solved the problem in about thirty seconds by comparing buff names rather than objects: public void AddActiveBuff(Spell spell) { foreach (StatusEffect buff in spell.StatusEffects) { if (!IsBuffActive(buff)) { activeBuffs.Add(buff, spell.Duration); stats.AddStatModifier(buff.stat, buff.amount); } else { foreach (StatusEffect activeBuff in activeBuffs.Keys) { if (activeBuff.name == buff.name) { activeBuffs[activeBuff] = spell.Duration; } } } } } Once that was done, I was able to move on to fixing another small bug with my custom Stat inspectors, decide not to make another change regarding how buffs decay (a concern caused by the bug) and add a small piece of code that ignores the turn system when the player is not in combat (allowing for quicker exploration). Once those items were done, I suddenly realized that I had actually reached my first milestone and the frustration and lack of motivation I had been experiencing transformed into excitement and vigor. One more time: YAY! WHAT’S NEXT With that cumbersome set of tasks out of the way, what’s next? Well here’s what my task list has to say: 1.3. Milestone 1 Wrap Up – Complete Basic Turn Based System In Progress 1.3.1. Refactor and clean-up existing code 1.3.2. Document all existing features – UML, GDD, Code Comments 1.3.3. Celebrate! In progress Have a few drinks (YAY!) Complete Celebratory blog post In Progress Yes, this is actually on my task list. These things are important! But, more technically, here’s what the rest of my task list looks like at the moment. 1.4. Player Combat Actions 1.4.1. Attacking Melee Create Placeholder Weapon Attack Animations Damage Enemy Ranged (Spear, etc.) Ranged Create Placeholder Weapon Define how moving projectiles affect turns On Hold/Tentative Projectile Animation Magic Casting Animation Implement Dual Wield? On Hold/Tentative Define how the player will use dual wield (Attack both at once, choose which hand, etc.) On Hold/Tentative 1.5. Define item types (Consumable, Weapon, Armor, Quest, etc.) 1.5.1.Define item script heirarchy 1.5.2.Determine item commonalities and differences Create item hierarchy Weapons Create Weapon Scriptable Object Make Weapons equippable (through editor) Share common animation based on type Practice with Infinity Weapons Practice with Mesh Effects Integrate Infinity Weapons and Mesh Effects Procedural Weapons Experiment with Infinity Weapons texture generation and Blend Shapes at Runtime I made these items quite a while ago now, so the list will change before I actually start working, but this will give you a general idea of what I’ll be working on. The On Hold/Tentative items are ones that might not be needed, or that I have yet to fully decide to include in the game. POSSIBLE NAME CHANGE The last thing I’ll mention is that I’m considering changing the name of the game. I really like the title The Wayfarer; I think it sums up what the experience is essentially about. However, performing a search for the title, it seems too common a name. The first page of Google alone is filled with restaurant pages, and there are even a couple of games already existing with names similar to The Wayfarer. On the other hand, performing a search for my last game Pixel Zombie Shooter brings it back as the top result, and The Wayfarer has a much larger online presence than Pixel Zombie Shooter as far as all of the blog posts, Youtube videos, etc. So, I think that if I’m going to change it, I should do it sooner rather than later. What are your thoughts? Anyone with marketing experience want to chime in?
  4. TASK LIST, UPCOMING MILESTONE Originally posted by Jake Jollimore on FidelumGames.WordPress.com on September 11, 2017 I’ve been pretty busy over the last week with life stuff, so not a whole lot to report on at the moment. However, I watched an Extra Credits video last night that talked about some tips for making your first game. This isn’t my first, but there were still some good tips in there. The biggest takeaway from this video for me was to make sure that, even if you don’t have the time to work on your game, spend at least 30 minutes a week looking at and reviewing it. The point of this is to keep it all fresh in your mind, and not to let the mental model you’ve created of it to atrophy too far. If you’re a game developer, or even just an avid gamer, I really recommend you check out Extra Credits on YouTube. The videos are always entertaining and educational. Anyway–this video got me thinking about the task list I mentioned in an earlier post, and I thought it might be kind of cool for some of you to see it. Note that this list is not static by any means. Items get added, removed and shuffled around all the time. I’ll start with a high-level task (like Spells), and then break that down into smaller tasks. Often time, I’ll get part way through and realize that, in order to finish the current task, I have to add another to the list and shift my focus to that (eg. I needed a base Stats implementation to implement spells), and then resume with the original task. I’m really glad I have this list. Juggling all of the interconnected systems and moving back forth between them would be a major headache without it. This lets me keep my mental RAM free for more important tasks. It’s not formatted as nicely as the Word version, but you should still be able to get an idea of what I’ve finished, what I’m doing, and what I’ll be doing next. Task Status 1. Define and Implement Core Gameplay Mechanics (Alpha) In Progress 1.1. Movement (Base Mechanics Only—Polish to come later) Complete 1.1.1.Define Movement Scheme Complete Moving (Translation) Complete Define Restrictions Complete Non-Walkable Areas Complete Walls Complete Holes Complete Non-Passable Terrain (Water, Marsh, etc.) Complete Max Climbing Angle Complete Max Drop Amount Complete Turning and Looking (Rotation) Complete Fixed rotation (Key presses) Complete Free Look (mouse) Complete 1.1.2.Implement Movement Scheme Complete Player Movement Complete Develop test level with walls, holes, stairs, drops Complete Develop test level with terrain Complete Turning and Looking (Rotation) Complete Moving (Translation) Complete 1.2. Turn-based Play In Progress 1.2.1.Wait for player action (Mode 1) Complete Define how the Speed stat affects turns Complete Define TurnManager (Passive vs. Active Mode) Complete Define Enemy AI Complete Determining Actions Complete Movement Complete Attacking Complete Melee Complete Ranged Complete Magic Complete Retreating Complete Pursuit Complete Patrolling Complete Implement Enemy AI Complete Movement Complete Avoiding Other NPCs Complete Pursuit Complete Patrolling Complete Attacking Complete Melee Complete Ranged Complete Ranged Melee (Spears, etc.) Complete Projectiles Complete Magic In Progress Define Spell System Complete Define Stats and Prepare for implementation (equations, helper functions) Complete Implement Stats Complete Custom Stats Inspectors Complete Implement Spell System (Enemy) In Progress Linked Spells In Progress Document Spellcasting In progress Revamp Spell System In Progress A couple of finished sample spells In Progress Define potential status effects. Not Started Implement base status effects Not Started Retreating Complete 1.3. Combat (Base) Not Started 1.3.1. Attacking (Player) Not Started 1.3.2.Melee Not Started Create Placeholder Weapon Not Started Attack Animations Not Started Damage Enemy Not Started Ranged Not Started 1.3.3.Ranged Not Started Create Placeholder Weapon Not Started Define how moving projectiles affect turns Not Started Projectile Animation Not Started Magic Not Started Casting Animation Not Started Implement Not Started Dual Wield? On Hold Define how the player will use dual wield (Attack both at once, choose which hand, etc.) On Hold Items Not Started 1.4. Define item types (Consumable, Weapon, Armor, Quest, etc.) Not Started 1.4.1.Define item script heirarchy Not Started 1.4.2.Determine item commonalites and differences Not Started Create item heirarchy Not Started Weapons Not Started Create Weapon Scriptable Object Not Started Make Weapons equippable (through editor) Not Started Share common animation based on type Not Started Practice with Infinity Weapons Not Started Practice with Mesh Effects Not Started Integrate Infinity Weapons and Mesh Effects Not Started Procedural Weapons Not Started Experiment with Infinity Weapons texture generation and Blend Shapes at Runtime Not Started Side note: looking at this list now, it’s starting to get pretty long. I might need to make some separate sublists. As you can see, I’m currently working on implementing the spell system for the enemies. I’ve been at this task for a while. It was nearly done, but I realized it was needlessly convoluted when I had to keep re-learning how to use it to create new spells. So now I’m reworking it a bit, and so far so good. Once the spell system task is complete, I’ll be able to move on to what I consider to be a major milestone: making the player do stuff. Currently, all he can do is move and take damage. After the spells, I’ll work on making him be able to attack back. Speaking of milestones: I really need to define some formally. Anyhow, I’m excited to get over this spell-casting hump and to start turning all of this functionality I’ve created into an actual game. As soon as the player is able to start attacking back, the need for new systems is going to skyrocket. We’re talking weapons, armor, items, inventory and all of the little pieces that make them all up. I’m realizing now that this next task is going to be a huge one, but I’m suddenly super excited to get to that point. As soon as I finish spellcasting, and before I start working on the player, I’m going to make sure all of my code is painstakingly commented. This will be a turning point in the project, and I have to execute it well. Cheers! -Jake NEW MUSIC AND A TEMPORARY SETBACK Originally posted by Mika Pilke on FidelumGames.WordPress.com on September 19, 2017 Here is another piece that was done for The Wayfarer! Last week was a chaotic one. My PC crashed so badly there was really no other option but to reinstall operating system and everything else again. That was a small disaster. Basicly I spent all of my spare time for 8 days to revive my setup. “Luckily” I did this same operation about an year ago, so I got most of the bigger installing files already there. Still there was quite a lot to do. Not only that you install all the programs, but then you update everything, upload the registeration managers, look for the serials, registerate, find out (again) that you have multiple accounts (at the same site) which cannot be merged (and that there are email addresses that don’t even exist anymore) ect. It takes time to relocate all the passwords for those over 10 different accounts. There was probably over 60-70 different products. Luckily only that much. It could be a lot worse. After you’ve installed and updated everything, you still need to find folders of all the dll-files so VST instruments and effects start showing and working in you DAW. Then open up the DAW, open up the instruments one at the time and look for the libraries so that instrument have something to play ect. ect. It’s quite a mess. To be honest I really, really would not care to do this again. It’s really time and nerve consuming. But now it’s done and I’m back in business and nothing crucial is missing. That’s life. Things happen. Then you clean up the mess and move forward. PS. The cause of this was actually drivers of my audio interface (it could be concluded from the file name showing at the blue screen). Fast Track Pro does not support Windows 10, but since it did work after the update from Win7->Win10, I did not quit using it. Now that interface does and will not touch my PC. It is a good interface and I have been using it for years, but I really don’t recommend using it if you use Windows 10. BR Mika Pilke
  5. GREETINGS FROM THE COMPOSER! Originally posted on FidelumGames.wordpress.com A few months back I was looking for projects that would be in need of a composer. Jake did contact me via GameDev.net and asked if I’d be interested doing musics to his game and since I’ve always been a huge fan of fantasy RPGs decision wasn’t really that hard to make, even though there was quite a lot going on at that time (I was offered six game music projects at that time, I had quite recently started in a new job ect.). Style of the game and the musics just seemed right for my style. Okay. Then who actually I am? My name is Mika Pilke. A Finnish hobbyist musician who has been playing around with music for about 20 years now. I’ve been writing music for years, but just lately I’ve felt that my material and quality of the mix have archieved the level where it is possible to actually consider accepting composing projects. I don’t really know how many songs I’ve written totally, but total number is probably somewhere between 150-200. I have also played in several bands too (mostly as a lead guitarist and/or as a singer), but I guess I never truly found comfort in playing live which is a chaotic moment where your senses are dampened and you can barely hear anything, let alone the small details (which I do find important). I’ve always felt that making music all alone, at night, in a dark room is what I actually love the most. It’s intensity, 100% focus and the flow. Tools Nowadays (and at this level) the magic happens mostly by using virtual instruments. I use Reaper as a DAW, a midi-keyboard (Axiom61) and various VST/VSTi/VST3/VST3i instruments from various companies (like Native Instruments, Steinberg and Spitfire Audio). But sometimes it also might add some extra punch to actually record something from the real world too, so I also have Shure Beta 58A, Rode NT1-A and Zoom H1 for recording sound. M-Audio Fast Track Pro serves mostly as an audio interface (and Behringer U-Phoria UM2 as for backup, or for recording sessions that are located elsewhere and you’re too lazy to unconnect M-Audio from the computer). In the end it’s quite a simple, but somewhat capable setup. And still somewhat cost effective too, even though software is not cheap. What is the meaning of music? Music and soundscapes are easily undervalued and even forgotten elements, yet they have (mostly passively) a strong impact to viewers/gamers emotions. I believe music is actually one of the key elements that will define the game’s identity and it has a strong purpose in creating memorable moments and atmospheres. I would even go as far to say that all the visual content is the body but music makes the very soul of the game. When these two elements are combined, sometimes there is a change to create something truly unforgettable. And of course sometimes a good storyline helps too ect. 🙂 But after all, how many games that have become a legend, has a bad soundtrack (if there are any, that is)? So there are quite a lot reasons to take music writing seriously. It’s a job that comes with a great responsibility and it’s a matter I wish to handle with a proper care and passion. One of my creations for The Wayfarer: BR Mika Pilke PS. Check out Mika's YouTube channel!
  6. Originally posted on fidelumgames.wordpress.com Strap yourselves in. This is going to be a big one. And hang in there. There’s some good media part way through. A CLEAN SLATE Since my last post, I let myself get a bit out of hand as far as staying disciplined goes. I had made some decent progress, and had some cool things to show off, but most of what I was showing was only superficial progress. The things I’m talking about are environments, enemies (actual animated models, not just cubes) and some UI stuff. The problem with these things is that they were all parts of incomplete systems. In one of my earlier posts, I wrote: This was a mistake, and led to me falling back into my old habits of sitting down to a development session and asking myself, “what do I want to work on today? What would be cool?” The result of this workflow was getting a given feature ‘good enough’, making it look cool, and then moving on to something else with the intention of returning to the feature I had just ‘completed’ in order to finalize and polish it. The problem with this was that I would often go too long before returning to that feature (if I did at all), and forget the mental model required to finish the system properly. I basically wound up with a bunch of fragments that didn’t fit together. This quickly became overwhelming and really sucked my motivation away. What I really owe myself is to not add any polish until the game is ready for it. Luckily, things have been slow at work lately (until today), and so I’ve been left mostly to my own devices. Without any project work to complete, they let me work on pretty much whatever (as long as it’s somewhat related to what we do there), and since Unity is part of the skill set I use on a regular basis at work, I was able to justify working on my own game in order to increase my proficiency with Unity. God how I wish that was the norm. Working all day long on something I love really makes the time fly. Some day. Anyhow, with all of this time to work on The Wayfarer, I decided it was the perfect time to throw away everything I’d done so far and start over, with a new mentality. This might seem like a bit of a waste, but I’ll be able to reuse some of what I’ve done, and consider the original work as a prototype. The most important thing I’ve been doing is forcing myself to plan everything (except for the smallest tasks) before I even open Unity. This prevents me from sitting down and asking that awful question “what do I want to work on today? What would be cool?”. Instead, I ask myself, “where did I leave off? What needs to be done today?” My new workflow goes something like this: Look at my task list (something I never had before, but to which I adhere strictly to now) and see where I left off. If a task is in progress, pick up where I left of. If not, move on to the next item, adding to the task list as required. These tasks break down essentially into two categories: planning/design and implementation/development, and both groups take up about the same amount of time. Before I write a single line of code, I establish my algorithms in my GDD in plain English (which feels strangely similar to coding). Then, I draw an activity diagram based on the algorithm, identifying any logic flaws along the way and revising the algorithm as required. Finally, after all of that is done, I move on to actual coding–simply translating the algorithm and diagram to code. All of this might seem like overkill (and it does feel like a pain in the ass sometimes), but it’s all worth it in the end, and makes writing the code so much easier. Not only that, but my code is cleaner, more robust and more easily expanded upon. Way fewer headaches now. For those of you interested, here’s one of the plain English pseudo-code examples taken right from my GDD, and the corresponding activity diagram (these are for enemy AI): I have to say that with all of the practice I’ve gotten in lately, and my new workflows, I feel like I’ve just come out of a learning plateau, and am reaching a new skill level with programming and game development. I’VE CREATED A MONSTER I’ve been spending nearly all of my recent development time working on my enemies. This and the following two sections will deal with the details of that. The first thing I did was rework my enemy AI, again with my cubes. I feel like my new system is much more robust, as I’m able to get a wide variety of behaviors just by modifying a few values in Unity’s inspector. I’m able to make my enemies favor ranged combat or close quarters (or any combination of the two), physical or magical attacks, determine how often they’ll heal themselves, and how likely they are to cast buffs on themselves during or in preparation for battle. I’m also able to dictate how aggressive they are by setting the chance that they’ll become injured and retreat during battle, and for how long they’ll pursue the player. I’m also able to dictate how well they can see. All of this without ever (hopefully) having to touch the AI code again (except for bug fixes). This system relies on a simple state machine in which the enemy can be Alerted, Unalerted or Injured. In each of these states, the AI will choose how to behave based on their preference for a particular behavior. You can see more about this system in the pseudo-code and UML shown in the above section. I’ll show a short video of the AI in action in the next section, but for now, have a look at the variables exposed to the inspector which determine an AI’s behavior: WORKING MY MAGIC My goal with my magic system is to allow myself to make everything as generic as possible so that I can easily create new spells without writing additional code, by easily adding status effects to spells, being able to reuse the same visual effects for different spells, setting whether the spell is a projectile or has an immediate effect, or combining/linking any number of spells or visual effects. The system itself is pretty difficult to explain. Suffice to say I use ScriptableObjects, prefabs and Animation Events, and can just work within the Unity Editor to make new spells. Also, I can just drag spells into an enemy’s spell list to give them the ability to cast them. The system itself is pretty much done (with the exception of making status effects actually dosomething), but I’ve yet to put any legitimate visual effects in. Just differently colored spheres for now. Here’s a short video showing how customizable I’ve made spells (I have hopes of letting the player create spells while playing as well): One thing I would like to point out that I think is kind of cool is the ‘Blood’ Magick type. This type of spell costs health instead of (or in addition to) mana to be able to cast. I see these spells being used heavily by warrior type players who have a lot of health to spare, but maybe don’t have enough mana to be proficient spellcasters And, here’s a video of my enemy displaying how it behaves, and how changes in its values modify its behavior. Note that the different balls are placeholder for different spells, and the green thing is a placeholder for a physical projectile, like an arrow. Don’t mind the bugs. PREPARING FOR THE FUTURE Along with all of this planning and trying to ‘do things right’ (if there is such a thing), I’ve been working on getting all of my stats set up, and having them actually be meaningful. The need for this came out of creating the status effect portion of my spell system, which needed stats to be defined (or at least a shell of them) in order to work. I’ve broken my stats down into three categories: Primary/Governing stats: These determine all secondary base stats, and base proficiencies with tertiary stats. Very D&D-ish. Secondary stats: Anything directly tied to primary stats. Health, Mana, Carrying Capacity, etc. Tertiary/Skill Stats Weapons & Armor (Dual wield, Ranged Weapons, Heavy Armor, etc.) Magick (Proficiency in different types of Magick) Other (Things like lockpicking, etc. If I decide to put them in the game) The Player, enemies and NPCs all have a common set of stats, and then, of course, some that only apply to a certain character type exist only where necessary. Nothing overly exciting here, except that I created my first custom inspector in order to make modifying stats easier. Here’s a before and after: This inspector lets me modify governing stats and see how it affects everything else. It also allows me to easily modify all stats and quickly restore a character’s health or mana at run time. Hopefully this saves me some time in the future. That’s it for me. Stay tuned for more! PS: We’ve got a new team member, but I’ll wait for him to introduce himself!
  7. JEJoll

    Medieval Story

    Not a whole lot of footage to go by here, but what you've shown looks beautiful. It looks like you've paid a lot of attention to the combat animations and the environment--I love the parrying and the trees swaying. Looks like something I'd love to play. When can we look forward to a longer gameplay video?
  8. JEJoll

    Doors, Dungeons, MakeHuman, Bug Fixing

    Not sure if you're aware, but there's a decent library of clothes, etc. for MakeHuman HERE. You might be able to find something better than a shirt and jeans.
  9. Waaaay too long since my last update. Since then, I've been working (not nearly as much as I should be) on outdoor environments and a skill tree. I want this game to follow the classic RPG class formula of Mage, Fighter and Thief, but I didn't want to constrain my players to a single class. Instead, I decided to go with a classless/multiclass concept where players are able to traverse a large skilltree which is implicitly divided into the three aforementioned classes. Take a look at the prototype: So this is still an early proof of concept, and all of the visual elements will probably change, but it's going to function in pretty much the same way as shown here. You'll also get a (very) small taste of the kind of skills you might see in the game. One more note: the three skill branches never merge in this example, but I think they will in the final version. Also, all parent nodes of a skill must currently be unlocked before unlocking a given child node. I'm not sure if this will persists, or if I'll remove that constraint to give me freedom of traversal. Other than that, I've been spending a bit of time building some outdoor environments to try to nail down what my worlds will look like. This first screenshot is, quite honestly, pretty bland and generic, but it will at least give a sense of how villages will be laid out in the world: After I made this scene, I procured a license for Gaia--a really powerful and full featured terrain generation tool for Unity. Here's what 15 minutes of work with Gaia looks like: Pretty amazing huh? So in the end, I think I'll be using Gaia to build my world, and then I'll refine the terrain manually and tweak the positioning of settlements and other points of interest to best suit the game's story and gameplay. That's it for me. Stay tuned for an update on NPCs and monsters!
  10. JEJoll

    LD38 - World In Progress

    This is going to be a super short post (and a bit late coming, too), because I simply don't have a lot of time, but I completed my first Ludum Dare entry last weekend. Here's a link to THE GAME'S LUDUM DARE PAGE, where you can read further about the game, and find links to play it. I strongly recommend downloading the exe to play as the WebGL build is rather clunky. I also recommend using the mouse for control. In a nutshell, you play a small planet who must collide with smaller planets to grow bigger, and avoid larger planets or break them apart with your guns. The game isn't as full featured as I would've liked, but I plan on adding more functionality and bug fixes in the future. I'll make a proper post in the days to come.
  11. JEJoll

    Cascapadia Closed Alpha

    Looks cool. I'd be willing to test it.
  12. JEJoll

    New Flicker Spell Animation & Tweaks - #2

    I like what you've done with the flicker spell, it looks good! Take this with a grain of salt if you wish, but to be completely honest, I think it could still benefit from a transition from point to point, rather than an instant move.  Keep up the great work!
  13. JEJoll

    Development Catch-up and Intro #1

      I was thinking some kind of trail would work. This way you could even keep the instant-move type effect and just show the trail from the origin to the new position.  On the other hand, the effect might also benefit from having the player transition to the new position, rather than just instantly being there. Even if it only took a tenth or a twentieth of a second, I think it would help remedy the disorienting effect. Then again, I suspect it's less disorienting than it seems in the video, as the player will be expecting to flicker. Keep up the great work. I'm definitely going to be keeping an eye on this project. I always wanted to make something similar :p
  14. JEJoll

    Development Catch-up and Intro #1

    This looks great. Definitely something I want to play.  Have you thought about having some kind of effect play when teleporting? It's a little disorienting, at least watching the video it is.
  15. Congrats! The game looks like it will be a lot of fun. I'm really interested to see the story as well.
  • Advertisement

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!