next »

[markollivrin]

I´ve been tempted more than once to try different vertical planes as "bridges", but since knowing whether two ships see each other would become very counter-intuitive, I managed to leave that pandora´s box closed to date.

If this is the only one element that stops you from testing this idea, why not introduce some noise effect to "blur" under and so prevent a ship from "current" level to be able to clearly see ships from lower levels ?

And by commenting, i'm not only be able to suggest you an idea, but also to follow your devlog, btw
It's a tremendous job you've done so far with this so promising game, can't wait to play soccer with it

Thanks for the catslikecode tutorials link, and all you technical explanations, it was of a great help for me to improve my Unity skills on a project of mine.

[pnch]

@markollivrin: Thanks! Imagine ship A is coming down from a ramp, at the end of which is ship B. B should be able to see A too! Also, if B is on the boundary between the floor level and the ramp, I can´t think of a "correct" (as in predictable and intuitive) way to make them collide there without actual 3d physics. There´s quite a lot of these little details once you think about it. Glad to help with your Unity skills! I´m planning something along that line, stay tuned.

So, Unity 5 is here! The are also now including many features which previously were paid-only for free. Since Negspace´s budget is still exactly $0 plus a lot of spare time, this is NICE. Looking forward to rendering to texture and profiling the heck out of the game. Will let you know how it went once it´s done.

First boot after recompiling Negspace in Unity 5 aand... the game runs fine! Switching engine versions is something every gamedev treats with respect, if not straight-out fear  .
The fancy star field / parallax shaders somehow got totally screwed, though. Since I´m planning to rewrite them to support render to texture anyways (and therefore make the beautifully evolving nebulas and clouds accessible to lower spec graphic cards) that´s not THAT bad in echange for the new features... I hope, wish me luck!

Edit: bringing some last page's eye-candy to this new, bare, page...

[pnch]

OK, I´m finally catching momentum after the holidays! I´m glad to annouce that

#42 Clouds are working again in unity 5

The fancy shaders are now working in Unity 5! It´s not that they stopped working, but that all their finely tuned parameters went overboard with a change of behaviour relative to scaled objects vertex values in the new Unity version. In english: the underlying "blank page" behind all those nice clouds and nebulae changed, therefore causing havok in everything that was drawn over it. Also, shaders, as their name implies, are nifty pieces of code that tell your graphics card how they should "shade" each object on screen. Usually they are used to show lighter tones in the sides of objects that are facing a light source, but they can also be used to do some crazy and creative stuff. Also, since graphics cards are pieces of software specially suited for graphics (duh), anything that gets sent there is something that the processor won´t need to calculate, therefore giving it more breathing room to do something else, like calculating everything else that´s going on .

Here are some weird images took in the process of the fix.

Aand, done:

Now each object looks up its scale and serves it to the shader. With that input, the shader can build coordinates similar to those that were built by Unity4. It´s maybe not the ideal setup, but for the time beings it keeps everything working exactly as before, without manual tweaking of every cloud and star that´s already in-game  

For those of you having a similar problem:
It seems that Unity5´s v.vertex * object_scale == Unity4´s v.vertex


Also, a tiny new detail: decoys now fold themselves, both after launch and before dying:

Thanks for reading!

[jwaap]

Beautiful!

[TheWing]

Holy actual shit, how have I missed this :D looking damn awesome, posting to follow now and then proceeding to read the rest of the pages between 1 and 10

Didn't yet see a mention on what platform this is on, linux build maybe?

[pnch]

@jwaap: Thanks, it means a lot!
@thewing: Thank you! Last time I checked it ran just fine on Linux, though I can´t confirm platforms at this stage. Actually, as a first project from an unknown developer (just me) on a $0 budget, which has yet to  reach out to the press, it´s quite hard NOT to miss it! Do spread the word if you like it, it helps!

#43: Nodes

For a while already, I wanted to be able to work with Nodes in Unity. What are Nodes?

This can be easily represented as a list without taking my entire screen, so, why would I want them?
See what happens once I add sidequests and different ways to reach a goal (absolutely non-Negspace related) :

Notice how easy it becomes to read all those complex relationships between elements, and think about a more straightforward way to depict them. I´ve yet to find one (the interface could be improved, though).

What would I use nodes for in Negspace? I don´t know for sure yet, but since anything non-linear becomes quickly empowered by a node editor, I´m heading this way. Potential uses besides quests? Dialogue, AI Behavior, Machinery parts interaction, and whatever you can think of that´s possible to graph as nodes and would be otherwise awkward to represent as a list (or list of lists). Will any of this be featured in Negspace? I don´t know  .

Is this an original idea? Not at all, a lot of different softwares use node editors. There´s even many examples of Unity Node editors out there, but those that seem fully-fledged are usually binded to plugins, and already aimed towards a specific function (therefore lacking flexibility). That means, if you are working in Unity and want one, you´ll probably have to build your own (if someone wants to prove me wrong, be welcome!).

So, I got into extending Unity.
My thoughts so far: getting a window to display correctly, and support undo can be a challenge in itself, and each of these challenges can´t compete with the rewarding feeling you get from actually working on spaceships that swirl around the screen... Luckily, having worked long enough with node editors in other softwares, not having nodes was becoming sort of a bottleneck. Plus, to make this happen I´ll learn a part of the Unity codebase that´s completely new to me, and that´s always a good thing.
Here´s what I have so far (ATM it´s doing nothing besides actually drawing the nodes):

Wish me luck!

[pnch]

#44:  Node editor II

On news that can only be moving for people who went through UI hell:
The node editor now zooms, scrolls, and connects with the inspector!

After introducing pan and zoom, node windows started to live in a different space than the mouse itself, and it became a bit of a pain to keep track of both spaces for every action (context menus wouldn´t appear where you expect them to, and sometimes didn´t correspond to the context you right-clicked over, even simple node selection had it quirks). I´m glad that´s all now working fine.

The editor also got his first keyboard shortcut (the Supr key now deletes the selected node), and I made the interface a bit more similar to Houdini´s UI, by removing the fields from the nodes themselves, and showing all of the node´s fields in a separate panel (the inspector). See how the selected node, "Slay dragons", displays its contents in a separate panel (and supports serialized objects from the scene).

[pnch]

It´s been quiet again around here, sorry!
It was so for many reasons, but there´s one of them I´m particularly proud of:

Those of you who have been following already know that Negspace is a love project, and that I´m not actually coming from a gamedev background. What most of you don´t know yet is that Negspace was started in the middle of another love project.

It is with immense pleasure that I can finally announce "Fuego", such is the name of that film, made it into ANNECY´S Graduation Film Competition! It passed an awesomely tight selection: from 2600 films in all categories, only 49 graduation films made it, and it´s the only Argentine film in all categories! Annecy being one of the leading animation festivals, this is the best things that could happen to "Fuego" right now.

This is a really good thing for Negspace too, since it´ll help build more visibility for the project.
For those of you willing to keep tabs on my projects besides Negspace and gamedev, I just opened a new FB page: http://www.facebook.com/bypencha. Those of you that are already following me on twitter (cheers!) will get all of the updates there (as you already did, before anyone else  ).

Thanks for reading!

[pnch]

Tembac and 2Bam decided to build a home for argentine indie titles, and they kindly offered to make room for Negspace there. This saturday the "Argentron" will be parked at the Centro Cultural Matienzo! (Buenos Aires, Argentina) There will be plenty of other stuff going on, since it's in the middle of the Let It VJ Festival.

Despite being on a different global change of scale and ported to Unity 5, the build will look and feel similar to those shown at previous events, but the setup forces 2 player matches only this time. It will be the first build shown in public to include drones and turrets, though  . Also, I ditched the decoys in favor of an instant-ejection button, looking forward to see how that affects gameplay.

Can´t wait to play it on an arcade cabinet for the first time!
Here's a backstage pic, featuring a happy 2Bam

Reporting back soon!

[pnch]

Late for reporting, but reporting nonetheless!
The arcade worked fine, it was nice to see what would happen bringing Negspace to a party atmosphere. I think the first minutes proved too hard for the general non-gamer public this time, on the other hand, some players managed to put up a fight in the centrifuge level without any issues. It was nice to show the drones in public for the first time too.
Players mostly did a quick zapping of the games included in the arcade (a LOT), and almost no one respected the arcade "quarter law", so there were long queues to play the whole night.
In the same room, projected on a wall, were my friends from Coffee Powered Machine showing Okhlos and Videogamo showing an experimental project - they also brought NAVE, their own arcade.

#45: Different node types for the quest editor

-Added support for different node types (Kill / And / Or / Win).
The Win node is the win condition for an entire quest tree.
-Rewrote the nodes in a slightly more elegant way, in order to allow for dialogue and behavior trees in the future.
-Made the header of the window display the node type, and moved user entered titles to and a small label beneath.

Despite slowly starting to look functional, it's still a prototype! There´s no link with actual quests yet, and there's a couple more bridges to cross before being able to actually build quests using this method, but I think in the end it will be a more elegant solution than a ton of one-off state variables, and hopefully allow for more interesting quests.

[pnch]

#46: Node Editor IV
Getting more comfortable with writing Editor code, and coding in general  
-The currently selected node and the win node now have different colors from the rest.
-Prevented creating multiple instances of the Win node (it´s supposed that if you reach this node, the quest ends. By using the Or node, you can still end a level following different paths).
-Added a base inspector for each quest node (node type label, quest title, description, completion message)
-Added support for different inspector extensions that match the selected node type (the kill node now also has a "target" field on which to load a target, etc.).
Having fun, and learning quite a bit, but can´t wait to have this working, and get back to less abstract dev!

[pnch]

#47 First approach to Unity + Git

-Started looking into Git, to be able to make big changes to the codebase with relative peace of mind.
Git, a source control system, is sort of a commented timeline of changes to the code, allowing you to go back in time to a specific change anytime, and seeing each line of code that changed with each "commit". Way more flexible than copy/pasting the entire project at regular intervals, my actual method.
I already worked with Git on a previous (non game related) project, therefore I had a basic idea on what I was getting into. However, after trying and failing with a GUI version (both unity and sourcetree wanted an empty folder to start with...), I managed to get git command line to work on a sample project, and I suspect now that the initial setup was done via command line, I could use the GUI on that.

My unity scenes are pretty big, since they hold each tile and polygon collider built from the tilemap themselves. As it is now, Git would end up bloated, spending more time on scene changes than on actual code changes. A proper fix for this would be preventing all this info from being saved with the scene, and refactor to allow the editor to build the level from the tilemap file each time a scene is opened (plus something similar at runtime). It is something I planned to do in the future anyways, since it´s a simple fix and it would greatly reduce the build size, but I don´t really think it´s a priority right now.

In short, it´s great to know it´s possible, and I´ll surely adopt that workflow in the future. If you are making a game and never heard about source control systems, backup and give it a go! Once you get past the fear of accidentally wiping your project clear, they will help you sleep at night even if you are in the midst of a large change, and you´ll probably hack and slash through your code without that much contempt, knowing every change is properly logged. Plus, if you plan to work on larger projects, it´s sort of a standard way of working.

Here´s a basic tutorial on Unity + Git, you´ll probably need some googling to fill the gaps, though.

The quest editor is still advancing at a steady pace, more on that, and hopefully some less abstract dev coming, thanks for reading!

[pnch]

Well, despite all that nonsense about game development, I know you´re all here for the gifs (#screenshotsaturday)

[pnch]

#48: Deprecated quest system

Remember a while ago I logged about the game getting bigger? It turns out, as much as I like hotseat multiplayer, I´ve spent a lot of time thinking on some sort of single player mode for Negspace, that´s doable and more elaborate than thrashing bots (as fun as it is right now  ).
I didn´t log it (shame on me) because I was just starting to fiddle around with it, without a clear direction, but I already had a basic quest system up and running before starting to work in the nodal quest editor. Here´s the UI of the previous quest system:

The quest loader is a list quests that evaluates each quest in a sequence by its ID (4,3,2,0,1), and each different quest is loaded into the object as a monobehavior to make entering the data easy. It´s not pretty, nor a recommended approach, but it worked nicely for prototyping, and i'm dropping it here for reference
Note it supports different kind of quests, but always in a linear progression.
After prototyping simple placeholder missions, I thought quests could work, but I´d have to build a more robust system if I was planning to do more organic quests. Having a system that works, and planning to integrate a new system over the old one was an ideal case to test Git, so that´s why I was looking into it the other day!

Thanks for reading! How´s it all going? As always, C&C welcome!

[Cakeprediction]

This game truly looks stunning O.o
Nice job!

[pnch]

@Cakeprediction: Thanks!!!

#49: Optimizing the field of view effect

Games ideally run at 60fps, which means the computer has 16.6 milliseconds (1/60) to execute all the calculations and draw an image to the screen, if the calculations end up lasting longer, you get stuttering, which may or may not be noticeable, depending on how much longer it takes.

Although the game runs fine on most PCs, the field of view effect is the bigger performance hurdle right now, and, wanting a break from the node editor, I decided to take a look at it, to see if there were any easy ways to make the calculations faster.
 
The effect is inherently performance-intensive but, using the profiler, it´s rather easy to diagnose which lines of code are the heaviest. For example, the effect works throwing n rays around the ship, and then builds a mesh from these inputs (there´s a previous entry about that). The rays should be thrown at every calculation, but if instead of rotating a vector around as an aim and throwing a ray each time, I do a cache of all ray directions on the effect startup, and use a lookup to throw a ray, I get to shave a few ms from the calculation, since now I only have to calculate all possible rotations at startup. This simple tweak made the calculations a lot faster. Other tweaks applied were:
-not clearing the mesh anymore (since it will always have a constant topology)
-that in turn allowed me to write the triangles just once

Why didn´t I think of all that the first time? It´s best to just check that your system works first, before doing any optimizations. At a later stage, you´ll be able to see which calculations are affecting your project, if any, and you can start optimizing there. Why is that? Optimization usually makes your code less readable, and it takes longer to write performance-conscious code, which most of the time isn´t needed (google "preemptive optimization" for more on that!).

After applying these and a few extra optimizations,the field of view mesh now runs about 3x faster! That in turn frees plenty extra ms to use for other game systems   .

The mesh in action (sloppy piloting included)

Back to gamedev, thanks for reading!

[YM]

OOoooohhh been a while since I poked my head around here. Quests look good.

Pretty good idea to cache the angles and only build the mesh once, I take it you're also only editing the verts that are on screen and skipping all the offscreen ones too?

[pnch]

@YM: Thanks! That´s usually a good idea in most scenarios, but I´m not sure the overhead introduced by those comparisons would outweigh the advantage of not having to cache some vertexes, will check it if I get back to optimizing this
Best case scenario: all hits are outside of the screen, would run faster, worst case scenario: all hits are inside, runs as before, but slower since it also has to previously check whether hits were inside... as long as I can´t find a way to get that info VERY quickly.

[TheWing]

worst case scenario: all hits are inside, runs as before, but slower since it also has to previously check whether hits were inside... as long as I can´t find a way to get that info VERY quickly.

May I ask why you need that previous info? My head can't get around this for some reason.. unless it's because you're like, just modifying the "line-of-sight"-mesh to adapt to changes?

Anyhow, I bet it'll look great no matter what you end up doing, so.. yeah, keep that up o/

[bauer]

Just wanted to drop by to say that this looks very unique, I really love the deep parallax effect!