Porting Dagon to Unity


#1

This is a bit of a shocker at first but no need to panic: Dagon is here to stay. Please, take a look at this Kickstarter update were I explain the motivation behind this decision, what is happening now, and what would happen in the future: https://www.kickstarter.com/projects/agustincordes/asylum-kickstart-the-horror/posts/838872

In short:

  • The current engine (let’s call it Dagon++) is not being abandoned, though development will wind down as we refocus our energy on Unity and Asylum.

  • Dagon for Unity (or Dagonity) is going to be a visual rethinking of Dagon, allowing to produce games with a similar structure and workflow. I am, in fact, looking into the best way for brining already existing Dagon++ scripts to Dagonity.

  • My hopes for the future is to allow some sort of interoperability between both projects. For examples, allowing games created on Dagonity to run on Dagon++ (sans the Unity-only features such as environmental effects) and vice versa.

There’s loads to discuss, so I’ll let the news sink in first. The development of Dagonity will be completely open, and very active :slight_smile:


#2

Wow, this must not have been even close to an easy decision, Agustín. It takes a lot of guts to steer the tanker in a different direction having spent so much time pouring blood and sweat into Dagon (sacrificial blood and ogre sweat, of course :slight_smile: ). Even braver when you know people are going to be annoyed but you did it anyway for the greater good of the end product.

Reading the update, there were mixed thoughts. Sad that a lot of effort has already gone into the Dagon engine but also excitement at the prospect of working in Unity. And thanks, again, for open sourcing your tools - as soon as I read that, I let out a little cheer :D. I’ll be honest - I took a little bit of a back seat while waiting for the dust to settle on Dagon (mainly waiting to see how the final scripting code was going to pan out). This turn of events opens up a whole new spectrum of features that come with Unity out of the box.

Some initial queries:

  • What language in Unity are you using (C#, Javascript or Boo)?
  • Will you need Unity Pro for specific Dagonity features or will free Unity suffice? I noticed only Unity Pro has the video texturing - a key feature in Dagon but maybe there are other workarounds.
  • Will a small demo project be included with the Dagonity tools?

I know you have more posts planned so waiting in excited anticipation for a more in-depth overview of Dagonity!


#3

So, Agustin, when can we get our hands on Dagonity? I have to admit to some trepidation about venturing into Unity again and want to see how your integrating Dagon into the 3D engine.


#4

Unity Indie can play animations in a sense, just not video files.

I did a successful test once in Unity Indie that involved using a custom script to swap out image files as textures on a sphere, at a rate of 30 times per second. It worked beautifully, as a way to create an animated panorama in Unity Indie. That was before I switched from Unity to Dagon, an action I took because the challenge of crafting a panoramic adventure game from scratch in Unity was proving too complicated for me, coding-wise.

Now it looks like Augustin wants me to switch back to Unity. :o

Augustin, I like Dagon (the open-source Dagon) because it is a relatively intuitive first-person adventure-game toolset, and I can afford to use it.

I actually backed Asylum not primarily for the game but as a way of supporting development of the game engine.

If ‘Dagonity’ requires Unity Pro, it will be out of reach for me - and, I imagine, for many other indie devs who aren’t prepared to shell out $1500 for a Unity Pro license.

So this is a plea to Augustin, now that he is branching out into a new development direction and leaving the original plan on the backburner:

-Make a version of Dagonity that is compatible with Unity Indie, not just Unity Pro, and make the various forms of Dagonity reasonably user-friendly if possible.
-Secondly, even though its development is inevitably going to slow down, don’t stop developing Dagon in its other standalone form. Some of us are using it!


#5

OK, to briefly address the overall concerns:

  • The language currently used is C#. I’m analysing switching to Boo for scripting as it integrates seamlessly with C# – that said, I’m aware that current Lua scripts should be reused so I’ll look into every option.

  • Dagonity will support Unity Indie alone. I’m aware about the video texturing only supported on Pro, but I promise we’ll come up with a viable alternative for the free version. We only need to render video frames to a square texture, a far simpler task than the RenderTexture API offers.

  • We will definitely include demos with Dagonity, be it Asylum content or even porting Serena. Whatever we do, we will give you all the tools.

What I can tell you is that building first person adventures in Dagonity will be even simpler. Our visual editor is way too convenient over scripting alone. Most importantly: Dagon standalone is here to stay. I am NOT abandoning the project, though it’s true it will be on a brief hiatus. If you need any features ASAP, by all means, let’s make a list of priorities and I will look into implementing them :slight_smile:

To recap:

-Make a version of Dagonity that is compatible with Unity Indie, not just Unity Pro, and make the various forms of Dagonity reasonably user-friendly if possible. -Secondly, even though its development is inevitably going to slow down, don't stop developing Dagon in its other standalone form. Some of us are using it!
All of the above!

We will release our experiments with Dagonity within the next few weeks. Just so that you know, there’s already FOUR developers working on the code, so I expect some quick progress.


#6

Can you tell us about the experience with Unity? Was it particularly negative or just too complex?


#7

Hmmm, it’s been over four years since I abandoned my efforts with Unity in favor of Kinesis…

I was trying to do this –

I took a cube object and reversed the normals for the sides so that my texture showed up on the inside of the cube. Each area of the game was to be a Unity scene and each node in the scene was set up with its own 1st-person camera at the center of the cube. The player “moved” from node to node or to a close-up view by swapping cameras when a “hotspot” (an invisible collider object) was clicked on. Puzzles and close-ups were to be projected onto fixed planes by setting the camera to an orthographic fixed view and using the GUI for buttons. I was trying to build in modular form, so that the prefabs (cameras, scripts and collider “hotpots”) could be dragged and dropped into each scene with minimal changes needed to the scripts.

In the end, I had to set up each node as a separate scene, but I did get a script for movement working, which snapped the camera from place to place by clicking on an invisible target mesh. It used fade-in and -out for transitions. However, sometimes the “exits” got shuffled and I was also having trouble getting the camera to recognize the direction it should be facing when you entered or re-entered the room. I managed to get a looping background sound, sounds attached to target meshes, a blinking light on a door panel, and two particle effects running (using the standard fog and fire prefabs that come with Unity). It was hard going… and took me about four months of dedicated work to get that far.

However, the GUI for me was the biggest stumbling block. It’s what finally did me in. I needed to use Unity’s nightmarish GUI system for a journal, portal, inventory, and object viewer as well as for close-ups and puzzles. I made some progress when I purchased a utility called EZGui, but it was not enough.

The bottom line is that (at that time) the Unity engine and the Unity community were focused on making 3D games (shooters), not the 2.5-ish hybrid that I was attempting. My skills were simply not up to the task and I gave up because of a mixture of frustration and exhaustion.


#8

Really good to hear, Agustin.

This is not what I expected the announcement to be (I thought the announcement would be just a version update, to 0.7.0 or something) but given the fact that it’s Unity Indie compatible and apparently fairly user-friendly, it sounds good. I’m looking forward to trying out the Dagonity toolset.

This could work out really well actually.


#9

Agustin, with the Dagonity module, are we using a single 3D box mesh and swapping out the images on the sides each time the player moves? I’m looking at Unity and trying to absorb the many changes to it since I last tried it. It’s a whole new language to relearn. ???

Oh, also in the photo of Pablo at the computer that you shared in the Kickstarter update — is he using spherical panoramas for the sky? What size? What format? I could be rendering… :stuck_out_tongue:

Also, I’ve saved the alpha maps for each size of the cubes separately from the images maps. Should I be combining them into the image maps + alpha? I also saved depth maps, if those are going to be used.


#10

I have many of the same questions as Imari - what are the typical graphics formats and settings for panoramic nodes in Dagonity? What about audio and video? I’d like to be ready to move forward quickly once Dagonity is released, and prepared to run some tests in it, to determine whether it’ll work better for my projects than Dagon++.

Basically, the current version of Dagon is nearly adequate for my purposes, except that it lacks the ability to consistently synchronize multiple video streams in a node. I’m attempting a string of inventive workarounds right now that may or may not prove viable… but ideally Dagon, in one of its forms, should be capable of doing this more easily.

BTW, do you have a release date estimate for Dagonity? You said a few weeks, almost a week ago, and I am wondering how many weeks, roughly, are likely left before the first Dagonity release. If it’s about 3 weeks, that affects my plans/schedule differently than, say, about 6-7 weeks.

[EDIT: One of my workaround tests actually ended up working extremely well. It involved changing the video loops from 30 fps to 15 fps… which apparently Dagon can handle nicely, consistently, without losing synchronization, even if the video is on 4, 5, or even all 6 faces of the cube. In other words, a full 360-degree video sequence is possible in Dagon. The downside is that the video in these sequences is a bit less smooth in terms of motion, the upside is that it’s seamless and half the filesize. I will try using this technique in a few other places and if it continues to work as well as it has in the first 3 nodes I applied it to, I think I may stick with Dagon and not worry about Dagonity, at least on this first project.]

[SECOND EDIT: Spoke too soon. After trying this on more panos, I’ve realized that video sync on 5 or all 6 faces in Dagon is still not consistently reliable, though undoubtedly it’s working better than it was before.]


#11

I’m really glad I put Dagon Studio on hold until Dagon was updated.

Good luck with Unity, I hope it works out and help build a stronger game :smiley:


#12

Augustin: How much longer until the first version of Dagonity is released? You said ‘a few weeks’ about a week ago and I’m wondering, how many weeks, approximately, are left before we get access to an early build of Dagonity?

I’m really looking forward to testing the Dagonity toolset.


#13

Sorry all, I was away last week. I’ll catch up soon with all the inquiries! As for timing, I’m hoping we can have the core mechanics (node movement) along with the visual editor within the next two weeks :slight_smile:

Sent from my iPhone using Tapatalk


#14

Catching up with the thread and all questions!

Imari: my first attempt was precisely what you did, that is, create a mapped version of the game where each node is an actual “physical” cube. Each room would become a separate scene. It quickly became evident that this is wholly impractical for a game like Asylum or similar.

I concluded that the best course of action is to keep the procedural development, so the game is essentially one scene with one cube and what we do is load the different textures of each node whenever needed. Pretty much what we were doing with Dagon++.

That is already working and looks the same if not slightly better on Dagonity. My intention is to make this new incarnation feel anything but Unity, so that you could focus solely on our customized editor. The additional features provided by Unity are always there should you need them :slight_smile:

One important question is if we retain Lua for scripting or switch to the more appropriate Boo. The internal code is definitely being implemented in C#, and Boo integrates far more seamlessly. In any case, the scripting will be mostly similar and migrating the existing scripts should be fairly painless. We’ll find the optimal way to do this migration, so no worries!

The environmental effects are precisely achieved with a spherical mesh to which we apply textures and lights. It looks incredible and we will bring built-in settings to Dagonity. Basically, you will be able to define the current weather for the entire game (i.e.: stormy, rainy, foggy, etc).

It’s perfect to have the alpha map separated, as that’s exactly what we’re also doing. It’s all going to be as automatic as possible :smiley:


#15

Matt: we would essentially support the same formats, though we’re favoring PNG. Unity automatically converts to a similar TEX compressed format when building the game, with better results even. Very useful.

Same with audio and video!

As for standalone Dagon, I can help with some maintenance if required, but please do read my latest comment about the video synchronization. It’s very hard to achieve. I’m hoping it will perform smoothly out of the box on Dagonity, but it’s too early to tell. I’m sorry this particular feature, the one you need the most, is so flaky :frowning:


#16

That’s overall good news I think which will make Asylum an even better game. Test videos shows that the game is already improved.

For my game however I’m not sure how it will turn out. I already scripted most important stuff in Lua and I believe I can’t handle porting codes to other languages by myself. Also I’m not particularly fond of Unity due to its performance problems. I’ve tried using it a few times before and they all ended up with disappointment. Its tools are just not good enough as far as I can tell from my experience. Which makes me hesitant to use it. I don’t really want to waste too much time on something I might potentially fail at.

In any case, my game doesn’t have 3d requirements and I’m fairly satisfied with the performance of Dagon 0.6.5 excluding the crashes I have to deal with every other time I launch the game. If that’s fixed I have no problems. But if worst comes to worst and I can’t finish the game on Dagon, it’ll be very sad since I don’t have much time to do big changes. With all the things I do by myself it’ll be a struggle against time. I’m sure it’ll work out some way or other though.


#17

No worries, civanT, I will definitely maintain the Dagon C++ code, which is open source anyway. The major pending thing for commercial games would be the save/load feature. That is certainly going to take some time but, other than that, it’s already possible to create a game like Scratches with the current standalone Dagon.

I’ll make sure to let you all know of any major developments. I’m still trying to ensure that existing Dagon scripts can run fine in Dagonity. Worst case scenario, Dagon C++ is still around and supported :slight_smile:


#18

Thanks for the update, Agustin. It’s much appreciated and I must say, it’s a relief to hear what’s planned.


#19

civanT,
I was checking out the Unity forums and people have been experimenting with Lua integration with Unity with some successes. They mention AluminumLua and KopiLua. There’s an asset using KopiLua that addresses dialog trees. Also an asset called uLua that seems more broad based. However, uLua costs $40 and only works with the pro version of Unity.
https://www.assetstore.unity3d.com/en/#!/content/13887


#20

I’m thinking that we could reuse quite a lot of the current Lua code, so there wouldn’t be a need to purchase an additional asset or even go pro. I’m investigating both Lua and Boo, and ideally I’d like to offer these two options for scripting. If implementing Lua support happens to be too much of a burden, then we could produce a tool that converts from Lua to Boo automatically. I believe that could be done with minimal hassle (for you).

But it’s too early to say, I hope to have a more solid prospect soon! :slight_smile: