Something Classic Games

Wow, hard to believe we’re already at Week 33! Initially, this Development Blog was to record all of the week-to-week changes as production continued, and note any new additions (Or subtractions) of the core content and features of the game as time went on. Instead, this development log evolved to be more than that. We delved into musical influences of past composers who influenced the sound of Shadows of Adam, we have a three-part series about budgeting the art costs of an RPG, we have an article taking a look at some of the retro flaws afflicting some classics, we have level design articles and we even have some boring technical articles. Looking through our post history, I noticed we don’t have many articles where we talk about what we actually worked on between posts, so I am dedicating this week “Development Log” towards a changelog of what changed since my last post on September 22, 2015, and quite a lot has changed!

New Menu Skin

We wanted the ability to change window skins (ala Final Fantasy window colors), and unfortunately the old menu skins were simply a single image texture that had text aligned to match the image. This doesn’t give us any flexibility at all, and makes it impossible to add any movement animations to individual windows since it’s all one big image! Well, that was all fixed! We introduced Scale9 image support and completely re-worked the UI so we can add multiple different window colors, and have it be an option should the player wish it. I think it looks nicer, and it’s easier to work with as well! Still some alignment issues to do, but nothing major 🙂

Area Text Enhancement

(Image is a GIF) You know in -some- classic RPGs when you enter a new area, a helpful box appears telling you the area name? We always had that simple feature in, but the area box had to be called using our scene system before it would appear. As such, it was only being used during certain puzzles. We improved this functionality so the area intro actually acts as an area intro, but only fires off once. You want to always be told which area you’re in, and don’t want to talk to the nearest town guard? I’m sure I can make an option for that.

Named (string) IDs instead of numerical IDs

I still find it hard to believe this ‘developer sanity’ feature wasn’t pushed more heavily by the team. Basically, we were using numerical IDs instead of named IDs for EVERYTHING. You want to add a treasure chest to a map? You have to go into the item data files, find the name of the item or piece of equipment you want to give the player, collect it’s ID and then attach that number to the chest object. Oh, what’s that you say? You can collect the item continuously and the chest never goes into it’s ‘Opened’ state? Wellll, for that you have to go into our ‘Treasure IDs’ worksheet on Google Sheets, assign a ‘treasure switch ID’ to your chest in the sheet (To prevent someone from using the same ID) and then assign that number to the chest. BOOM! Your treasure chest is now working! With a named ID, now you just reference the name of the equipment by it’s name, give it a opened state name and BOOM done. No more going back and forth spending coveted development time searching for the ID of the “Basic Armor”, or navigating development folders trying to find the treasure chest switch ID list. Now, it’s all automatic.

Why we never did this sooner? We’re stubborn here in SC land 😉

Quest Flow Engine

I can’t believe it took us this long to get this feature in. Our ‘de-facto’ way of handling quest flow for the game is by using boolean switches. Nothing wrong with that, right? Well, our switches (and variables) in the game suffered from the same problem mentioned above. It was all numeric numbers, and was not stored in a human readable way like an actual WORD. You meet a witch in the woods? She turns switch 113 to 1. If switch 113 is 1, then a new monster spawns and turns switch 127 to 1 and 114 to 0. These numbers mean nothing to me (And I’m one of the developers!) Now, with our named IDs, it is very easy to manage our quest flow. Our ‘Quest Flow Engine’ consists of two parts:

1.) The controller

2.) The trigger

The Controller is a special object that can be activated by any other game object. All it does is control the state of the game. If your quest flow looks like: ‘talk to Bob’ THEN ‘innkeeper lets you into the secret room’, then once the player talks to Bob, the ‘Bob’ game object tells the controller “Hey, the player talked to me! Set the “Talked_To_Bob” state to true!”
The trigger is made up of two parts: The condition and the logic. A single trigger can have any number of conditions or logic associated with it. If the Controller has the power over the game state, the trigger has the power over the properties and states of each game object. So using the prior example, the trigger could be waiting for the “Talked_To_Bob” condition to be met, and once met, fires off some logic which updates the ‘Innkeeper’ NPC to allow the player entry into the back rooms.

Joypad Support + Control key rebinding

Joypad support was in for awhile, but we never really talked about it. Shadows of Adam supports any Gamepad that uses the XInput API. The standard gamepad using this API is the Xbox 360 controller. If you have an older gamepad that uses DirectInput instead of XInput, we don’t support it natively, but you -may- be able to use additional software to convert the DirectInput signals into XInput signals. Further, we’ve also added in key re-binding. This is a must-have feature in my opinion. There is no way every single player of your game will enjoy the default key bindings, so having the option to re-bind goes a long way!

Skill Leveling

Each character has seven core skills, with the exception of Asrael who has eight. We wanted to avoid the level-up mechanic found in classic jRPGs where a party member learns a more powerful version of an already learned skill (Fire 1, Fire 2, Fire 3, etc), so at the end of the game the skill list is populated with a large amount of identical skills of varying strength. Instead, we decided to use a character MP pool, with each skill taking a certain percentage of the characters available pool and a base percentage is recovered each round. Each skill becomes more powerful as a character gains higher attribute points, and the cost of casting a skill remains mostly fixed. I say ‘mostly’ because we wanted the player to be able to customize the builds as each hero becomes more powerful. So we took a page from Super Mario RPG. Every time a hero levels up, the player can choose a single level-up bonus. These bonuses can be a stat boost, a reduction in the cost to cast a skill, and once in a while; a Skill Levelup, which changes the functionality of a single skill to make it much more effective and useful. Every skill can be upgraded three times, but the final “Ultimate” version of the skill may require more than just an option select 😉

That’s it for this week, I hope you enjoyed this post :). If you have any suggestions on what you would like to see us write about, let us know either in the comments below or on one of our social media accounts, and we’ll see what we can do 😀

See you next week,

Tyler

Particle effects play a huge role in modern video games. Not only do they look fabulous and really add that extra juice to a scene, they are trivial to build… at least on paper. The tricky part about a particle engine is optimizing the creation and destruction of the particle objects, in addition to making those particle objects render fast within your rendering pipeline. The requirements Tim had for a particle engine were pretty standard (Basically, everything the Starling game engine could do. See an example here: http://onebyonedesign.com/flash/particleeditor/). I am also going to try presenting this post mostly in images (And GIFs) to show the progress from the beginning to the final product with some short spiel, so beware! Lots of images and GIFs!

The first step was to flesh out our emitter and particle classes. It obviously doesn’t look like much, and chances are the thumbnail appears only as a black box. (Click the thumbnail to enlarge it). The performance at this stage was incredibly poor; we achieved a meager 300 particles per 3.00ms. If we want to hit a frames-per-second rate of 60FPS, then we need to cram collision detection, drawing, particles, scene composition, pathfinding and entity processing in sixteen milliseconds. Having to allocate 1.00ms per 100 particles of our 16ms budget isn’t good enough. So the next step is to add an object-pool. If you’re not familiar with object pooling, what we do is create a large ‘pool’ of objects and then recycle these objects for our particles. Whenever we draw a new particle to the screen, we request a blank particle object from our initiated pool of particles, set the desired attributes and push it to our draw list. The advantage this has is then we do not have to create a new Particle class everytime a new particle is created. Constantly creating and destroying the same thing repeatedly is both expensive and wasteful. Once a particle is destroyed, instead of marking it for memory clean-up, we maintain a reference to it and add it back into our object pool.

Another bland looking thumbnail image. It will get better, I promise! With our object pool in place, our particle engine now performs at 1,000 particles per 3.00ms. Compared to some powerful particle engines that can push out millions of particles with ease, ours is terrible. But 1,000/3ms is good enough for our needs. Further optimization can be done down the line when we get closer to release. The next step is to be able to support multiple particle textures, so we can have a special fire texture that turns into a special smoke texture when the particle is destroyed. So let’s do that now…

(Click image to view the GIF) Now we can support multiple textures. But I look at what is finished compared to the requested features list and I groan. There is still lots of work to go, and we want to get this game finished. So what options do I have? Instead of maintaining a “not-invented here” mentality, let’s open Google and see what I can find…Well, hello Proton.

After discovering Proton and diving into the examples and some of the source, I ask myself an interesting question: “This does almost everything we need, is fast, looks fantastic and is easy to implement. Why am I re-inventing the wheel?” Less than thirty minutes after setting myself on Proton, I had it integrated with our game engine and had some simple but cool looking effects being rendered.

I greatly respect developers who build their own engines from the ground-up, it is a monstrous undertaking but choke full of rewards. But I’m of the opinion where if you’re not a successful developer with a large runway of cash saved up, you should drop the idea of building your own engine and use middleware; unless of course your goal is to create an awesome engine. But if your goal is to develop a game, pick an engine and create that game. There are no “best engines”, pick one and use it. Work around its flaws and keep pushing forward.

Trying to build everything yourself will only add to your development time, and although it is greatly rewarding if you can pull it off, the time expense in order to develop all of these engines and components can push your small project into an area where it becomes significantly harder to break-even or even make a profit. If you want to develop for the long term, you have to find a balance. Of course, we all have different goals. Some people are not motivated by economic rewards, and are happy in knowing that they completed something of substance. But if you are starting out as a small developer, drop the “not created here” mentality and instead focus on creating the game you want to make. Don’t waste time picking the “best and greatest” engine, choose one that you understand and clicks and work around the flaws; even the biggest game engines will have its quirks.