Unity Build Engine Port
#1 Posted 08 November 2019 - 11:18 AM
I don't know if this has been done already, but I fixed up my old C# XNA build engine port, and got everything working in Unity, and put it up on my GitHub. Here it is if its useful to anyone. In the video I incorrectly say I used the original build engine code, I used Jonof's port as a base for the original port. Again I'm just uploading it, if its useful to anyone. This only includes the classic renderer. The logic behind only using the classic renderer, the software rasterizer consumes far less battery on mobile devices. You can move around Ken's game, and open sliding doors.
All code uses safe code(no pointers), means it should run on all Unity platforms.
The Code:
Mostly the same from Jonof/the original build engine. However I designed the engine to support multiple map files, all board logic resides in its own class, rather then globally defined in the engine.
https://github.com/j...nityBuildEngine
-Justin
This post has been edited by icecoldduke: 08 November 2019 - 11:38 AM
#3 Posted 08 November 2019 - 12:15 PM
#4 Posted 09 November 2019 - 03:23 PM
Quick question does anyone know how to load streamingassets, in Unity on Android/WebGL?
This post has been edited by icecoldduke: 09 November 2019 - 03:24 PM
#6 Posted 09 November 2019 - 05:31 PM
Tea Monster, on 09 November 2019 - 04:21 PM, said:
I'm looking forward to making a small game with it that can work on all platforms.
The advantage of having build work in Unity is, Unity can handle all the platform, networking, input and audio code on multiple different platforms, and build just renders the levels and the sprites.
#7 Posted 09 November 2019 - 05:55 PM
This post has been edited by MusicallyInspired: 09 November 2019 - 05:55 PM
#8 Posted 09 November 2019 - 06:19 PM
icecoldduke, on 09 November 2019 - 05:31 PM, said:
The advantage of having build work in Unity is, Unity can handle all the platform, networking, input and audio code on multiple different platforms, and build just renders the levels and the sprites.
Cool! Does this mean multiplayer as well!?
#9 Posted 10 November 2019 - 01:44 AM
MusicallyInspired, on 09 November 2019 - 05:55 PM, said:
Exactly right.
The Battlelord, on 09 November 2019 - 06:19 PM, said:
Yeah I did a small multiplayer test, it works fine. Basically each sector and sprite is a gameobject, and the engine takes care of the replication.
#10 Posted 10 November 2019 - 09:27 AM
Don't get me wrong, what you're doing could be cool as shit if you'd just stick with one thing before moving on to something completely different.
This post has been edited by Zaxx: 10 November 2019 - 09:29 AM
#11 Posted 10 November 2019 - 09:29 AM
#12 Posted 10 November 2019 - 10:07 AM
http://realvectormat...ower/index.html
This post has been edited by icecoldduke: 10 November 2019 - 10:07 AM
#13 Posted 10 November 2019 - 11:24 AM
icecoldduke, on 08 November 2019 - 11:18 AM, said:
I don't know if this has been done already, but I fixed up my old C# XNA build engine port, and got everything working in Unity, and put it up on my GitHub. Here it is if its useful to anyone. In the video I incorrectly say I used the original build engine code, I used Jonof's port as a base for the original port. Again I'm just uploading it, if its useful to anyone. This only includes the classic renderer. The logic behind only using the classic renderer, the software rasterizer consumes far less battery on mobile devices. You can move around Ken's game, and open sliding doors.
All code uses safe code(no pointers), means it should run on all Unity platforms.
The Code:
Mostly the same from Jonof/the original build engine. However I designed the engine to support multiple map files, all board logic resides in its own class, rather then globally defined in the engine.
https://github.com/j...nityBuildEngine
-Justin
Cool proof of concept. A friend was joking recently that after those botched Doom ports someone should show them how it's done with Build.
I'm curious about your battery life claim. In our HTTKC testing, Polymost was by far a better conserver of battery life than running the software renderer on the CPU.
Radar 100 Watts, on 08 November 2019 - 12:12 PM, said:
Amazing is not the right word:
icecoldduke, on 09 November 2019 - 05:31 PM, said:
The advantage of having build work in Unity is, Unity can handle all the platform, networking, input and audio code on multiple different platforms, and build just renders the levels and the sprites.
That isn't actually an advantage over anything EDuke32 has today. Between SDL and ENet, all of these needs are handled the same or better as Unity (better = completely free, less overhead). Unity can provide "networking" in that you give it a packet and it transmits the data over the Internet on any platform, but it can't magically add networking logic to your code which is the actual hard part. It can expose audio buffers for you to give samples, or even a rudimentary mixer, but you still need your own audio logic, or else if you offload functionality you'll get something potentially inaccurate/undesirable like BloodGDX's original audio.
#14 Posted 10 November 2019 - 11:46 AM
Hendricks266, on 10 November 2019 - 11:24 AM, said:
Thanks .
Hendricks266, on 10 November 2019 - 11:24 AM, said:
I'll run some tests and get back to you.
Hendricks266, on 10 November 2019 - 11:24 AM, said:
I don't need to mix the audio myself, in the demo above, I have 3d spatial audio by just setting the listener on the player gameobject and 3d audio emitter on various gamesprites that are bound to all of the gameobjects in the world. Even though the game renders into a 2D texture, the I get spacial audio because I'm moving the gameobjects around, even though visually it doesn't matter. That's all I need for my purposes and it works well enough.
As far as setting up networking, for my game I'm not going to assume all sectors can move. Instead only sectors that have sector effectors will have replicated game objects, which solves a lot of problems. Sprites work just fine as well.
Using Unity as a base, is in my opinion a great way forward. I have Android, WebGL, IOS, Xbox One, Windows, Mac, PS4 platform support, and the foundation of that support has been used in quite a few shipped titles. For my purposes putting my game on more platforms, without really any work, is something I'm heavily interested in.
This post has been edited by icecoldduke: 10 November 2019 - 11:55 AM
#15 Posted 10 November 2019 - 12:01 PM
icecoldduke, on 10 November 2019 - 11:46 AM, said:
True, if you're making your own thing the provided audio could probably give you plenty to work with.
#16 Posted 20 January 2020 - 03:08 PM
#17 Posted 20 January 2020 - 03:15 PM
#18 Posted 29 January 2020 - 01:26 PM
From what Gmanlives said, some stuff in kingpin was quite advanced for the time, if I take my own unity work for references, that could be thousands, tens of thousands of lines of code.
Of course there is the unity asset store, but it's not necessarily a shortcut, especially if you knows what you are doing. It's not likely that there is a Kingpin SDK for sale, which means whatever you buy will not be specifically tailored for your game and you will have to modify it anyway. If we are talking code, that may be easier to write it from scratch.
This post has been edited by Fauch: 29 January 2020 - 01:31 PM
#19 Posted 15 April 2020 - 06:47 PM
icecoldduke, on 10 November 2019 - 11:46 AM, said:
Porting the BUILD engine into Unity is a dream come true for me. So you are able to run .grp’s and con files just like native, *and* have multiplayer working? That’s amazing!!! And yes sprites work just fine!! Thank you for doing this!!!
#20 Posted 17 April 2020 - 11:00 AM
Hudson, on 15 April 2020 - 06:47 PM, said:
Unity doesn't magically add working multiplayer code. It's not gonna work any better than the code that ICD is porting into it.