next »

[BeautifulGlitch]

Hey! It's possible we met on Barcelona recently? :O

[Juju]

Love the look it has and being a fan of the Front Mission series, this is exactly tailored for me :D as I am a programmer myself, I am quite interested in the AI side of it -- is it scripted, hard-coded to all or each enemy type, or something else?

The basic AI pathfinding is the same for all actors (including friendlies) and is node-based. GM doesn't strictly have a component system, but that's a useful analogue here. There'll be at least two full-length posts on how it works in the future.

[Skydsgaard]

Hi everyone!

@Hao Thanks a lot!

@7heSama Ok, I think that I finally understand what you mean, (and don't get me wrong, I really appreciate getting feedback) but the last thing that I don't get is, why that way is going to be better. I think there is more room in the bottom than in the top, ..sooo the animation doesn't collide with the white details this way? Maybe it is because you thought/realised something that I didn't xD
Anyway, are you sharing any progress of your game online? devlog etc? I would like to take a look

@MCHLVSSW that means aaaaaaaaaaa lot, thank you very very very much dude <3<3

@sidbarnhoorn thanks a lot!

@Aedous 

@BeautifulGlitch Nah, probably that person lied trying to get a discount on one physical copy of your awesome Indie G Zine xD. Just kidding, it was me Congratulation on your successful campaign for Monster Prom btw.

@juju gotcha


Update!

Basic demons / human interactions:

So after rescuing the humans, they can get attached by the enemies with 2 possible results:
The demon will attack and kill them with just one hit (since they are quite weak)



And the other is, they both get stucked in a fight during a little amount of time, where you can help him survive.



But if you don't, after that time, he will just..well:



And, just a first approach to upgrade threes and icons. This will change during the entire project, but better to have something to begin with. I also kind of suspect which ones are less readable, but I would love to get your opinions and thoughts about them.





The idea is that when you select them, they will do a little animation, so it will be easier to recognize what it is about:



And that is everything for now, have a nice weekend!

[Romain Rope]

Love the overall icons design!

I just don't get this trio though

[VertexZero]

Looking so sweet!

[io3 creations]

I just don't get this trio though

Seeing them animated would help.  My guess for the middle one is that it's flamethrower or fire related.  The one on the right might be something electric.

[flipswitchx]

That armor up animation. I'm in love. 

[Sustrato]

New art! So, the humans can't really fight back until they find a weapon?

The icons look sick. I love the pulot's hair in the top left and the way the mech's silhouette interacts with the diva one outline in the top right, just flows really well. The center top tower is very recognizable, and the center right helmet follows the lines of the pilot very nicely. My biggest concern is the trigger-pull; it's kind of hard to recognize the shape of the finger, I didn't get it until I saw it animated. The bottom three also look good, assuming like io3 they're weaponry and would make more sense in game (I do recognize the cannon and flame).

As for the spinner triangle thing, true it may conflict more, my thought was that since the center piece leaves horizontally, it should also enter horizontally, rather than vertically.

I do have a devlog, in fact! It's called the Foregunners. Thanks for taking an interest!

[io3 creations]

I do have a devlog, in fact! It's called the Foregunners. Thanks for taking an interest!

Marketing tip: If you add the devlog link to your signature, more people will discover it.

[Juju]

A question came up on a GameMaker chat group I run: "How do you store your configuration data, and why do you choose those methods?" What a great question! Highly technical but generally useful for beginner programmers regardless of language. This is going make for

A Fantastically Dry Tech Post
in which Juju discusses basic data storage

Irkalla is creating a lot of configuration data. Previously I've chatted about how I'm using JSON to store animation meta data, specifically frame timings and gun barrel positions. JSON is absolutely wonderful as a format: it's supported everywhere, it's human-readable and machine-readable without parsing finagles, and its agnosticism towards integers/floating point numbers play right into GameMaker's hands. (For the uninitiated, GameMaker stores all real values as doubles.) Irkalla uses JSON for not only animations but its save files and level files as well.

Let's have a look at how the level data is laid out. For visualising the data, I use http://jsonviewer.stack.hu/ which seems ok I guess, though there are probably better tools out there.

This first layer shows each major section of the level data. I can add more sections to this at a later date with ease and still keep everything organised.

Some elements in the JSON are quite simple. This is a location and depth definition for some scenery. In this case, we have two bits of scenery, but I can add more scenery to the JSON and have it automatically enumerate them (0, 1, 2 etc).

Other game objects need to have more data attached to them. Note how I can nest nodes inside other nodes - this is extremely powerful. Knowing that I can build a system now and still hold the door open for expansion means I can program the game one piece at a time instead of worrying about having to refactor significant portions of code due to a design change. Add the bits I need, take away the bits I don't need, and the JSON's integrity is still valid.

However, not every kind of data suits a tree-based approach. Of particular note is supporting translation of game text from one written language to another. It would seem obvious to use a tree-like structure for translation, right? Have your text key as a node in the JSON, then have each language as an element inside that node. The issue here is that the people working on translation for you may not be comfortable working with JSON, online editors get a bit sketchy with large amounts of data, and manually editing lots of JSON in plaintext can lead to silly, unnecessary errors.

It's important when building a tool to not only think about how your end-user is going to work with it, but who you end-user is. Freelance translators are rarely tech heads like us and we need to take that into account. In this case, I'd use a CSV file (some top-tier games do the same, including Paradox titles). It is supported by every spreadsheet editor under the Sun so even the most technophobic of translators will be able to work with CSV. As a plus, I've found editing a straight-forward spreadsheet much faster than clicking around inside an large JSON tree.

That's on disk at least. For my sins, I do tend to turn CSV data into JSON when it hits the game engine for the sake of consistency and faster look-up times. For example, animation timings are actually stored in a fat CSV on disk but are translated into JSON when loaded. This keeps things smooth my end, especially for debugging, and smooth for whoever's writing the data into the spreadsheet to begin with.

[Skydsgaard]

@Rope Thanks! Yeah, mostly the first one. They are by order: gaus riffle, flamethrower and taser bolter. I hope when I animate them, it will be easier to recognise :/

@VertexZero Thanks! I also like your designs of the cat warriors for Swansong a lot, keep rocking!

@io3 creations Thanks for taking the time! Yeah you are right, I think the animation will help too.Two of three! not bad

@flipswitchx Glad you like it dude <3

@7heSama The Foregunners is looking very interesting and promising!
About humans and weapons is something that I need to think about. I would love to have the possibility of equip the humans with weapons, but since I am planing to have 3-4 different skins for the humans, it means that each skin will have an “armed” and “un-armed” version, meaning that we would double the number of states and they are already actually a lot, soooo, let’s see.

Glad you like the the icons dude, and yep, I was really surprised that nobody was complaining about the trigger. I tried a new version:



About the UI navigation, finally it looks the icons need to rise up... like you mentioned in the first place xD Mostly because I need to separate the upgrades into categories, so you will explore the UI pyramid in 2 directions, vertically (to explore the upgrades available at the end of that branch) and horizontally (to change category/branch). So horizontally exploration will make the pyramid warp like you have already seen. And vertically exploration will work like this (very shitty animation just to show the functioning).



And yep, I also agree with @io3 , (I see that you already took the advise), but it would help even more to include an image/gif)

@Juju   CSV  

So, while we keep working on the next update, a couple of animated icons to give you a clue of what is going on



Have a nice weekend

[maruki]

You are the king of making spin animations in pixel, Skyd. I like everything!

edit: grammar

[Skydsgaard]

@maruki That is because they are easy xD

[egor.botov]

Icons are cool. Humans idea and animations are fantastic. In my opinion first ver. of "trigger" icon is more clear, at first I haven't recognized three fingers on latter, thought it's some kind of mechanism. Hope this can be useful.

[rek]

So glad to see so much cool stuff being done over the last few months!

[Skydsgaard]

@egor.botov Thanks!
@rek Glad you keep visiting <3

Soooo, let's do a 3rd try I went for a mixed version of 1 and 2, keeping a more "old-school/recognizable" shape for the trigger, and a clear frame for it, and I have also made a more organic configuration for the fingers. Do we have a winner or should I go for a 4th version? xD



v.1                                                     v.2                                     v.3

[egor.botov]

Yeah, ver. 3 inherits best parts of previous ones.

[Sustrato]

Third version looks good! The fingers are much more readable. Also, on the second version the black gap between the index finger/trigger widens when she pulls it; that really throws it off, so I'm gland you cut that. Only critique I would have is to make the white body of the gun not pull back from the top-left edge during recoil - since the gun should extend further than that, only the details should move, not the apparent edge of the weapon. If that makes sense.

The turret and wall icons are sweet! Are you gonna pull up some base building elements? And the tech post may have been dry but it's very helpful to see how people handle this sort of thing. What languages do you plan to support?

As for my project I'd love to have an image sit but I'm afraid the art isn't up to par yet hahah. One day.

Looking forward to the next post!

[Skydsgaard]

Hi dudes! Happy new year everyone! <3

@egor.botov Thanks!

@Kris with a K Yeah, it makes totally sense, I was trying to play with some depth/frame casting shadow thing, but yeah, you are right, I will follow your advice and remove it

And yeah, we have been working a lot on buildings lately, here you have a video about them:





Buildings are going to be useful for expanding and defending your domain. They will  also produce units to help you in the battle. And remember, humans are very crucial for this purpose, you need to rescue/collect them to repair and run your structures.

Later on, we will add more complex tech-trees, with more buildings and units/armor/weapon/movement upgrades.

But our plans for now are to get back again on AI and combat mechanics so let's see what happens in the next update.

To continue, a little introduction to the tier 1 basic unit from the factory:



And in last place, totally gamedev unrelated, (but I wanted to share it here anyway) I have been trying something lately and that is all I can say for now



We hope you guys like it and please, give us all the feedback and criticism you can, it is much welcome

This is going to be an exciting year xD

[Juju]

Post-Processing and Irkalla

A Journey To The Heart Of Darkness

Sit down and I'll tell you a tale. It's not any tale, you see, it's a true story. And it's about how a game was made.

---

Prologue

In a time before me, and before the person before me, there was David Hontecillas.

Irkalla's original engine was based in OpenGL, custom written by Hontecillas himself for the sole purpose of supporting Irkalla's large world and comprehensive artificial intelligence. The game's design lead, Skydsgaard, is an artist and thinks like an artist: every frame of this game is carefully positioned for pacing and impact. But plain pixel art it is not; Skydsgaard demands more nuance from his visuals. The lens through which we see this world is the screen and the viewport, and it is post-processing that modifies that lens.

Hontecillas had long been out of action, taking his own path down the river and through the fickle mists. He was only reachable via some crackling radio that operates on a frequency found in dusty manuals. He hid deep in the interior. My mission, a mission I banefully accepted, was to track down what he knew using only the fragments that were left behind. It was my job to execute the aesthetic with extreme prejudice.

Skydsgaard, in his brief, laid out the three main effects that I needed to implement to give the necessary aesthetic twist that Irkalla needs. All I had was the guidance of a few short videos and some OpenGL shaders that I could salvage from old tech demogs. The deadline was tight.

1) Fringe darkening, at the top and bottom of the screen
2) Reverse-fisheye
3) Gaussian blur, most extreme at the edges and non-existent in the centre

I packed my bags and caught the sunrise steamer. Somewhere in the jungle and its forever twisting paths lay the answers I needed. I was venturing into this markless territory not to meet a man, but to discover his secrets.

---

Act 1

I had been adrift for days, fiddling with this and that, waiting for inspiration and the winds to blow me toward the river delta. I took a disappointingly short drink from my lukewarm beer. If the bottle could have simply stayed out of my hand for longer, it would've chilled in the early morning breeze. This bottle was dry now, I had drunk too deep, and we were both empty. We pressed on as best we could.

GameMaker supports OpenGLES shaders, amongst others, and it's this tool I tend to use for shader solutions. The easiest way to build a flexible and fast colour gradient is to program it algorithmically. Using a texture gradient is of course possible; however, textures have a nasty habit of being slow and inaccurate in situations where you need smoothness. To top it off, Photoshop's gradients look pretty nasty when examined closely or scaled (Lack of dithering? Unusual colour grading? I'm not sure).

Gradients are typically done as linear functions. However, it became apparent as we were testing that this wasn't having the intended effect - it was far too noticeable where the gradient finished, part way into the screen. I played with some functions until I settled on the classic smoothstep() function. It's the labrador of smoothing functions - dumb, clumsy, but keeps on going even into its old age.

---

Act 2

The next leg of my voyage took me further up the river to a supply base that can be found on no maps. When I stepped hesitantly off the rusted riverboat, there was no one to be found. There was only dense fog and hastily abandoned shacks made from unfinished wood. The fresh earth that had looked, at a distance, to be so reassuring now wrapped my naked feet in thick and sodden mud. And between the trees, I saw eyes, unblinking and watchful. We took on provisions and brown beer, and sailed away.

I had a working inverse fisheye shader that I had written prior to starting on Irkalla. It used a quadratic equation in two dimensions to "pinch" the centre of the screen, a bit like dropping a ball in the centre of a stretchy bed sheet. This was a bit silly because it compressed the centre of the screen so that only pixels at specific points around the edge would ever be in a 1:1 ratio. The amount of distortion was horrendous!

Instead, I opted for a different approach. Instead of pinching the centre, Irkalla's post-processing keeps the centre flat and stretches out the outside layers. This reversal in thinking allows for loads more control, not least how big the flat area is. The curvature itself is performed using a simple power() expression that takes distance-from-centre as its primary input variable.

---

Act 3

The dim ebb of the weak lamp cast shadows past my shoulders. Up the wall, long and high, until it touched the empty ceiling - there hung disgracefully a silhouette of a man I've never known. "Hontecillas, you cur! You know how this acursed mechanism works, and why it continually creates overblown and streaky images!" I stand up suddenly and the floorboards opened beneath me; they too had started sagging in the wet heat of exhaustion.

Gaussian blur is a relatively complex topic and not something I'm going to go into here. For Irkalla, we're using two-pass (horizontal and vertical) blur as it reduces the number of texture samples and makes the maths a bit easier to digest. The basic principle is that you take a number of samples and sum them up, but samples further away from the target texel are weighted less.

In order to achieve the desired elliptical blur profile, it's necessary to change the "range" of the blur depending on distance from the centre of the screen. Usually with Gaussian blurs, you precompute the weights for each sample so that you don't have to do as much calculation per texel. If you're changing the blur radius, however, you don't have that luxury. That means figuring out coefficients on the fly which is on the more complicated end of things. David's code was very helpful to have as a reference.

The biggest problem that we ran into wasn't actually the blur (though I did have to fix some small issues with the change in aspect ratio). The biggest problem was controlling how the blur radius changed at different points on the screen. It wasn't as simple as linearly increasing the radius from the centre to the edge - it needed a start and stop point, as well as a way to control how quickly the blur radius increased with respect to distance. David's code didn't need that, and I actually don't know why/how something got lost in the transition. Regardless, I programmed around it.

---

Epilogue

I had disembarked in the eye of madness. Every notion stirred fear in my mind, around every bend there squatted preponderously unique and terrifying spectres. Fatal errors long buried rose, stale with fungal spores and decay. Graphical glitches previously undreamt of by man lay about the screen. It was carnage waiting for the vultures. So we brought down fire and retribution and cleansed the land. The last drips of dry alcohol flowed staunchly across my dry tongue.

Skydsgaard and I spent a long, long time tweaking individual values until, finally, it was just right. Every possible parameter was exposed and modified minutely. At last, after making sure the enter/exit transitions for the buildings looked as smooth as possible, Irkalla took its first breath as a truly artistic creation.

But I tell you - I carry with me whispers. Every word I utter trembles with an insidious doubt. Have we truly buried the machines of David Hontecillas? As a farmer torches fallow crop to feed the aching soil, Irkalla is sustained by the salts of an ashen field. Are we so different, him and I?

---

A huge thank you to David Hontecillas, a man whose contribution to Irkalla is indelible, no matter how much we screw up.