Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral


About orphu

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. orphu

    5: A short cinematic

    And now, with the scripting tool ready to be tested, and the beautiful placeholder as the main protagonist, it's time for some cinematic action. Remember: our goal was to make an rpg with a deep combat system and an entertaining story to follow (what else?!). The first thing you need to tell a story is having a story to tell. So, with a limited scope for lenght and complexity, I wrote two short scenes in my best adventure/fantasy parody style. The idea was connecting both scenes through the gameplay, making a short demo of what could be a game developed with these tools. The script is something along the lines of a couple of soldiers travelling through a desert to accomplish their super important quest, facing all kind of problems to continue their journey. What super important quest could that be? The omission of it makes it far more interesting than anything I could make up. I decided that two levels (two big scenes) was enough for a good demo. The first one being a desert, which I had to design. As the main goal wasn't a good level design, I didn't put much effort in it (altough in the next level, I tried hard making an interesting one). Even though, I think it's cute enough. So, in the intro cinematic we see these two soldiers talking about past adventures as they cross the desert. Of course, an enemy appears and then they have to fight it. The focus was not in originality, but entertainment. When I was happy enough about the script, I started translating it into the scripting tool. I splitted the work in two tasks: - Making the cinematic itself (controlling the behaviour of all characters and events in the scene). - Using a Unity plugin (Cinemachina) to "film" what the script was playing. So, on the one hand I had two characters talking for 30 seconds, and on the other I had to control from within Unity the camera behaviour. In retrospective, even if I liked the final result, I must confess I wouldn't do it like this again, mainly due to editing reasons (a living hell). Having the camera control independent of what's happening in the screen means that if I change anything (ANYTHING!) in the script, I must synchronize the whole cinematic again. That's a lot of testing and debugging. A LOT. In the following cinematics I made, I controlled the camera transitions and behaviour from nodes within the tree script, so unrelated changes usually don't affect camera behaviour. And after some work (the whole process took me a couple of days, I blame the camera issues), I finally had my first cinematic. Feel free to comment about it. So, we now have a combat system, a scripting tool, a silly story and a cinematic. The following step is using all of these things to make an actual game.
  2. For a game that tells a story... What do we need? Let's see... We need a way to tell the characters and events in the world what to do and when should they do it. And that's it for the most part. Sounds easy, right? The easiest approach, for me at least, was making a set of commands to be triggered by an event. I started by learning how other tools do the job. A tree with nodes specifiing orders was visual and clean. So I started with the minimum amount of commands and later on, I could add more as I see I need them. A few ideas: - We want our characters to speak casually. - We want our characters to have long and convoluted conversations with npcs. - We want to be able to tell our characters to move. - We want to be able to tell our characters to play an animation. - For cinematic purposes, we need ways to control the camera. - We need to read and write state variables. - We need some kind of flow control, making it a true scripting language. This was the starting point. Reusing some old code I wrote for making all types of editors, I quickly had a tool for editing script trees. Each level loads a file with the scripts for the scene, and then, when triggered, a unity script executes each node following the tree flow. When it worked I was surprised how easy to use and powerful this tool was. An example: Some work in progress for a level. Another one, just for the laughs: And then, with the right tools developed, the time for my first cinematic arrived...
  3. orphu

    Step 3: Combat & AI

    I apologize for the title. The computer player I had in mind is by no means an AI. It's more like a set of commands that are triggered if met a set of conditions, like when the player can configure the behaviour of his characters in games like 'FFXII', 'Dragon Age' or 'Pillars of Eternity'. As we can configure diffretent templates per character, we can adapt them to different combat scenarios. Maybe it's not the smartest approach, but it's easy enough and gets the job done. A quick example: Priority 1.- FireWave. It only triggers if there are two enemies in range. Priority 2.- Fireball. Move in range of target and fire this ability. Just these commands, in addition to the ones from other roles, make an interesting behaviour. If commands and combat scenarios are crafted carefully, they are more than enough to provide fun. I left Unity for a while and came back to the combat simulator. I spent some time coding and got a basic system implementation. Each character loads a template with his stats and AI triggers. Then I made a simple editor for this template. So ugly indeed. And back to Unity again. The moment I started the game and these sweet capsules kicked my ass was glorious. Now it was a game. Maybe a boring one,but a game. The first priority was adding some gameplay variety. A priest and a rogue, to fulfill the genre standards. Once I had it working (including new animations and effects) and was fun to play, I started thinking about giving it some visual variety. I downloaded some free models from Unity Asset Store. I've taken so much from others that mentioning all would require an entry of its own. I realized how easy was to use my combat animator in the new models, and soon I had other units to show. I added another layer of polish to the UI and suddenly it became a working and pretty combat system prototype. Here comes a new challenger Still, even if I felt the combat was fun enough, it was too simple. It lacked proper combat stats and formulas, a lot of abilities, more classes, passive skills, equipment... you name it. The combat engine was ready for all this systems, but... wait... what is the point of a combat system without a real game behind? I wanted to be able to tell a story, and there was so much work to do in other areas. So, for a simple prototype, it was enough. I decided my next step: a scripting system to set up world interactions.
  4. Meet the almighty PLACEHOLDER! Isn't he cute? His round face, his little nose... I think he is the all time most used protagonist for games. He does all the hard work, and later another fancy model gets all the credit. So unfair. Let's give him proper animations for such a hero. I used Unity animation editor to create an animation controller and a bunch of animations for movement, idle times and combat using only position, rotation and scale transforms. Now my combat implementation was firing triggers in the animation controller and, suddenly, all this tiny capsules were alive. Even the flow of combat was easy to follow, admiring heros swinging their swords instead of squeezing my eyes looking for the damage line in a log. I admit it, they grew on me. I found myself cosplaying them and... well...let me tell you they are cute as hell. Fierce warriors I also added some more UI elements and some code to show Action Points cost while moving. All that felt like a big step. But just two warriors... even for testing purposes... was too boring. I needed more characters, and everybody knows behind every great warrior there is a great mage. And it would be a good test for the combat engine, as it would add more diversity to abilities. While implementing mage abilities soon I realized I was missing a key ingredient of combat and visual wowness... particle effects. Now I have to stop here and admire how many good videos about this subject youtube has. So many people doing such a great work. I would like to, at least, mention the videos from Gabriel Aguiar. Almost all particle effects I ended up using are "inspired" by his tutorials. Thanks, man. So now with the mage. I chose three basic abilities: Fireball. Of course. It works as a projectile. Fireblast. To introduce critical hits to combat. Firewave. An AoE. Everybody loves AoE. So much magic. When the spells were implemented, the game suddenly became gorgeus. It's amazing how much can movement and particles add to the most simple visuals. As I was enjoying the upgrade in graphics, I started messing around with post processing effects. It added another whole level to visual appealing. So much with so little... It was very basic, but it definitely was a game. Except for one thing. A huge thing, in fact. I was playing both sides all the time. Not very interesting. The fun part is beating another one, even if it is a dumb computer player. And so the next step became clear...
  5. Where to start? Of course, we need an idea: I've always been a huge fan of World of Warcraft, and always thought it could make a great top down RPG. So the basic idea is to transmute WoW combat into a Divinity: Original Sin clone. Fair enough. Now let's imagine how a game in our combat system should be played. Describe it: First, player TURNS are ordered for each ROUND. When his TURN STARTS, a character can play any ABILITY in his ability bar. In the most basic version, these abilities can DEAL DAMAGE, ADD a CONDITION to a player (good or bad) or both. So, when an ABILITY is EXECUTED, we create an instance of one or more HITs, wich describe hit properties, and then apply them to one or more characters. CONDITIONs can be triggered by various COMBAT EVENTs, and when fired can create their own HITs. Each ability costs a resource, let's call it ABILITY POINTS. They also have other restrictions, like RANGE, TARGET TYPE, CHARACTER STATE or other resources. Now we need a character. We have a warrior with low level stats and few basic abilities. What kind of interactions these abilities should produce? A few ideas: - We sure need to move. So we should have a basic movement ability (walk). It shouldn't be for free, so its ABILITY-POINTS cost will increase with target distance. - We have a sword in our hands. Let's swing it. A basic melee hit, with a single target, dealing damage. - We are tanks, so a basic surviving ability could be handy. Recharge shields. - If we are tanks, we need tools to manage aggro somehow. A taunt ability. - Some kind of self buff would be nice. Maybe a counter hit ability for the next round. Finally, the character stats. We keep it very simple, later on we can complicate it. - Hit Points. Of course. - Shield. Another type of hit points. - Action Points. Amount of 'things' a character can do in a turn. - Power. Source of damage. - Armor. Damage mitigator. This was my starting point. Instead of jumping into action in Unity, I decided I should be able to play this basic version of combat on a simulator. Later it helped immensely with debugging and depedency managment. In little time, I was able to play a warrior vs warrior scenario: A gorgeous log based combat This was a great achievment. This kind of combat engine should make room for animations and user input. As there is so much stuff to cover, I'm skipping the details of the implementation, as it is a complex subject with so many different approaches. After making a lot of systems like this through the years, I always felt like a big step foward having them working. Great, I could finally launch Unity. I spent some time choosing graphic style until I came with something I liked enough. It was simple and clean, with a toon shader doing all the work for me. I don't have much experience in this field, so I felt that keeping it really basic was going to be a really good idea. Then I needed a place to test the battle system. No better place than an arena. So here is one. Colours, colours everywhere! After creating the most basic UI and abusing Unity NavigationAgent for movement capabilities, I finally replaced the combat engine interfaces with their Unity counterparts and... It worked! It's alive... alive! But it was ugly and lifeless. Barely a tiny step ahead of the log based combat system. It was missing just one thing to look like a game instead of a form: ANIMATIONS.
  6. First of all, an introduction: I'm a software developer who enjoys playing games. All kind of games. I always admired the game design process, and puzzled myself about every aspect of creating a game. In recent years, I've spent a lot of time experimenting with Unity, and after a couple of more complex prototypes, I decided I had everything I needed to create a complete game. Or, to be fair, I challenged myself to create the needed tools to develop a full game of moderate complexity. With this in mind, I started a new prototype, called "Virgil", to show a demo of how (with a lot of additional time and effort) could be a full game created by these tools. It will be a turn based RPG, ala 'Divinity: Original Sin'. I always enjoyed designing simple but deep combat systems. Graphics would be 3d, low poly cartoon style, trying to compensate simple custom models and animations with beautiful art style. The core gameplay could be split into two parts: combat and exploration. The combat engine must be able of execute any kind of ability designed down the road. It must provide a suitable AI for different combat scenarios and, as a system, should be "easy to learn, hard to master", as close as Blizzard QA as it reallisticly could be. The exploration part must be simple but powerful, allowing the characters to tell a story with a level of modelling and animation complexity paired to, say, Final Fantasy IX. Yeah, that's a big hope. So much work in so many diffrent areas. But perfect as a challenge. Where to start, then? Let's find our simplest approximation on combat.
  • 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!