I have decided.

it finally happened. I am switching to Unity. Why ? Well although my trust in 3DGS was high it does not deliver.
Promises made did not become true. It’s hell for me to learn a new engine and its programming language but it gives far more options to create games on different platforms.
I will visit this place to see what’s new but from this day I will focus on learning Unity.
What I learned so far is that physics and movement are fairly easy to use in Unity but the layouts and working interface of it all is a struggle for me 😊

It’s a shame though 3DGS could be a real contender if they went along with new times instead of staying behind.


Deep down i hope 3dgs will rise again someday so for now it's goodbye
thanks for giving me years of fun with gamecreation.

Hey man!

I might follow you in near future! Sad to say, but it's a wise decision. I wish you best of luck with unity and your future projects man!

My best wishes and regards!

good luck realspawn! thanks for being awesome in the 3dgs community!

I'll be around some times must say i find C# harder the the lite_C I was used to.

sad to hear you go!

yeah, gamestudio development was abandoned a while ago. But also Unity is not a magical tool. I mean, some things area easier to do with gamestudio and others are easier on Unity. I think we should choose the engine depending of what kind of game are you aiming for and the features the engine currently has.
If you are targetting only windows platform and you aren't looking for the best AAA graphics then Gamestudio is quite enough for more simple or cartoon graphics. If you want to target more platforms such as mobile or consoles and looking for complex graphics then you should go with Unity (or even Unreal).
In my case I've playing around some time with Unity but as right now I don't take too much time on game dev and I'm working on a game with simple graphics on free time gamestudio does the job perfectly fine.

The problem i have is i can easily pull fun little games up with 3dgs but the sad thing is they only work on windows platforms. So as user your stuck to one single platform. I find Unity hard in using although it has its plusses it seems scripts 2 lines in 3dgs are like 5 lines in Unity that are completely different Ah well we will see what time brings.

Unity is actually super easy. The thing is that most users here are not familiar with the concept of object oriented programming. Once you get the gist of it, Unity is a piece of cake. C# is also easy to handle and reduces your error potential to near zero. Just stick with some tutorials and also do some trial&error. It took me ~1 month to understand the whole ecosystem. But once you're in, you'll never want to leave it, because it's way to comfortable.

yeah once you get used to OOP it gets more fluid. However I don't agree with you about never wanting to leave it, sometimes I got tired of the "super cool" and "clean" UI and miss the old-school UI gamestudio has

The whole every thing needs a script added then connecting i find hell.
how come a simple wait is so much lines of script in C# so far I hate the script language I am ruined by 3DGSor spoiled:)

Well I actually meant the scripting language. It's not as easy as with 3DGS to have Memory Leaks or invalid Pointer errors with C#. The compiler tells you on the fly what you're doing wrong.
3DGS has its charm of course, I can't deny that. I'd also love to continue with 3DGS if it were up to date.

wait is not really a concept outside of 3DGS (for good reasons). It's super expensive in terms of runtime costs, and it doesn't necessarily lead to cleaner code. The one big advantage that it brings to the table for 3DGS is that you get to keep your local storage around. However, in OOP, that storage becomes part of your object and you don't need wait for that anymore.

Long story short: Do yourself a favour and forget about wait and don't try to create a similar looking bandaid. Instead, try to figure out why you want to use wait and how to solve that issue with what you have at hand.

i figured it out that's why i know in C# so much more script needed to simply hold a function hold for a few second

C# needs Coroutine and yield while in lite_C a simple wait(-2) works.

The fact that i need scripts for all game objects annoys me since you don;t have a complete overview. Simply dragging in a sprite or bmap in a 3D world is not working in unity instead i need to create a gameobject then drag the picture onto it then it needs a script.

i believe unity has a lot of ready to use stuff in it. Still i am not
convinces the working enviroment is that great.

perhaps i will do a little 3dgs vs unity game example.
It's a shame 3dgs is not update as it would and could be still a cometitor in game engines. ah were is a full script library when you need one.

Hi Realspawn !

First, Thank you for all the time and work you gave to the Gstudio Community and the Gstudio forum.

I hope you make no mistake, because that long being a member of the Gstudio community, you must be pretty familiar with Gstudio. Switching to a new 3D Game System to me is like after mastering the piano "Change to the cello now and become a virtuoso on this instrument". I know you make music, and you will definitely understand what I mean. Starting with a new system takes some time and the new system will NOT offer the manpower we all need to make a good game: Story, Level design, Characters and their animations,Skinning, textures, good scripts, good music, good sound FX, testing the Game and so on.

Also, after thinking about the multiplatform Game Editors/engines myself, I think Windows PCs with DX and a good monitor. are still the most importand Game plattforms. Nobody will enjoy to play a 3DGame like Skyrim on Android smartphones or Win/tablets or even on a laptop in a park. Linux and Macs maybe an option, but, but, but... Game Consoles ? O.K.

Unity also has a shop build in called Assets Store. I hate stuff like this. Sorry, yes, Im Oldscool :-), I do it myself.

I dont think that "Gamestudio is dead". You can see pop up new projects in the showcase. I only think that many of the people who bought Gstudio were not aware that Game creation is hard work and stresses nerves (inluding bugs) and needs some time. Or they do not master programs like MED.

Gstudio offers a lot of features imho, and do not forget there were a lot of addons and tools, scripst and plugins given to the community by very good programmers (unlike me)

But anyway, if you think you can do better with unity or the unreal engine (very remarkable anyway), give it try. Perhaps will come back later.

Best wishes and thanks again.

Neodumont

Still struggeling with "1913 a race before the war", Historical St. Pauli Millerntor Scenario from 1803, PCXanim "Mergenthaler edition" and some other stuff.

--------------------------------------------------------------------------------------

If I had boat I would go out on the ocean,
and if I had a pony, I would ride upon my boat.

@NeoDumont

Thank you i will still be around here and 3dgs is still usefull for me to setup a quick game idea.
(i finished one today that i will place soon)I hate that asset store to,
the whole seperate models that still need adding their texture skins to it in Unity.

Unity has a few things I like the physics work but the standaard and so called ready scripts i dont like that much, it blocks somehow the way of free coding.

I had an idea of lite_c library on the shelve and i am planning to finish it and upload as soon as its done.
The lack of good explenation is a minus factor of unity to. Sure there many tutorials but man most of them suck. Sleepy voices trying to explain stuff.
Programming but not letting you know what each line does. Simple beginner stuff is giving head ake while i see sometimes in 3DGS it can be done a lot faster.

I always loved this community and how many persons are willing to
share clear examples and explaining how it works. Unity offers complete script assets but thats it buy it and figure it out yourself.


Ah well we will see how things turn out.

My experience with Unity is that - yes, it is more versatile engine, with great options for porting your game to different platforms.

3DGS seems to be a more powerful engine that can run a lot faster with more things going on.

This could be because I don't know enough about Unity, but I made a Unity version of one of my games "Anomalies" and it runs really slow if the object count goes a bit higher. 3DGS handles lots of moving objects really well and smooth (with limits of course).

I am still wrapping my brain around Object Oriented Programming, but I keep coming back to 3DGS because I know it well, and can get results faster.

I do think my next project will probably be in Unity though ... we'll see.

is there javascript no more in unity? it was very easy similarly to lite-c, when I tested Unity 3.
unity is definitely easier to start with than unreal (but I really love ue4).

It has java so i have to study wich will be the best to relearn.

JavaScript != Java. And please, do not try to use the JavaScript version of Unity. There is no advantage, JavaScript is just plain awful as a language. This is what history has to say about JavaScript:



But seriously, do yourselves a favour and learn C#.

I'm by no means a huge fan of C#, nor am I a huge fan of Unity. But I think they get a lot of false critique here because Lite-C and GameStudio have garbage conventions that C# and Unity actually do better. Give it some time, and you'll realize that what you think is too verbose and complicated actually is very powerful.

yeah, I would use C# too, just have some old memories of Javascript which seemed much easier as a beginner than C#...

https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-off-into-the-sunset/

unityscript will be abandoned soon.

i also have no idea why it often gets called javascript-like or the javascript version of unity. it doesn't have any similarities to javascript.

It's in fact a dialect of ecmascript(just like actionscript and javascript).

Also while i agree with Sid on javascript, it's kinda getting better lately. JS on Node 8 and JS on browser are currently in waay different leagues. Also Typescript is kinda making things better in browser side of the thingd(albeit sloooowly).

Also yes, use C# version of unity. Unityscript will not be helpful when you actually try to move on to actual javascript(be it nodejs or browsers) because even though they are both ecmascript based, due to differences in nature of game engines and places where JS is used, it will not be much of a use to you.(In fact language does not matter on this point, what you actually need to learn is the way to program things and programming practices, which differ greatly when programming games vs other types of programs/apps, but i will not go in to detail in this thread) On the other hand, C# you learn will probably be more useful outside of unity, at least syntax and datastructures will be similar. Plus unityscript is deprecated and support will be removed in the future.

is the only reason gamestudio is not updated because not enough games have been made to garner attention towards the engine? If it was made popular enough, would conitec work on the engine again?

, realistically speaking, it would have been if >7 years ago, now it would be incredible difficult to make it popular again. I do think gs3d could be a good engine to quickly develop mobile/tablet games, but alas no android/ios support and no touchscreen button features etc.

If I remember it correctly, Gamestudio was in fact too popular for Conitec. They hadn't the time and resources to support it any further so they gave it back to oP Group. And oP Group got obviously a good amount of money for developing Zorro and creating trading algorithms for a number of clients. As a business owner you do what gets you the best profit.

But Gamestudio is still a really good engine. The most important things it needs are updates to 64 bit and DirectX 11/12. For mobile development better use another engine like Godot. In my opinion the engine isn't really important for quality games. It depends a lot more on the personal skills of the developers. Of course, a good engine can save you a lot of time.

Have you thought about using Unreal? It's free, exports to multiple platforms, you can script, too, but you also have Blueprints, which is a way to "program" schematically.

GameStudio is quite dead. The last beta released was from 2015 ... two years ago. The engine is quite dated, though it could indeed be used to make "decent" games. However, what really gets in GameStudio's way is the editors. WED is terrible to work in and MED is even worse. Both Unity and Unreal have really nice, modern editors that help bring development of a game together. Conitec (and no oP Group) seemed reluctant to actually ever change WED and MED. In a sense, we are still working with editors from the days of Quake, with some updates.

Speaking about editors, why didn't they continue to improve & fix GED at the time and just make that the main editor?

they were working on a new WED based on the engine but they abandoned it. In fact it still appears as 75% completed on the forecast page (now hidden) http://www.conitec.net/beta/forecast.htm

, at 75% they should just have released it in beta or such with some features turned off >.> , such a waste. Also why did they make 2 map editors (WED + GED) in the first place? I get the differences between them, but still seems like a waste of time.

GED was released later, during A7 lifecycle if I remember right, and developed by an external studio (crew51). Maybe it was a temporary solution to try to compete with other engines which were starting to use realtime editors.

75% could mean nothing, like an early prototype that crashes every five minutes. Usually, the first 80% are done relativity quickly and only take 20% of the development time while the last 20% take 80% of the time. Releasing a beta typically means releasing a nearly 100% finished product (not like modern game publishers).

WED was the original editor for 3D GameStudio and was based off of really old, Quake-era technology that they kept updating. WED was actually pretty awesome and easy to use ... back in the day. When it was a fairly "modern" editor, you could do a lot with it. But game development and level design changed a lot and WED couldn't keep up. There comes a point in time when updating old tech is not enough. You need to replace it with something built from the ground up. Apparently Conitec was not prepared or able to do this, so someone stepped in with GED. However, that never was fully realized and the end result is that GameStudio ended up with two editors ... one that is old, clunky, slow, and another that is not really completed.

It's a shame, really, because GameStudio has a long history, (had) a loyal following, and, in the right hands, could have continued to be something really amazing. There's still a lot that could be done with GameStudio v8, but it gets more and more outdated every day ... and it's not fun (anymore) working in either of the editors.

Im pretty sure there are many indie games made now using old software, outdated even, so I wouldnt mind finishing my game in gamestudio, knowing full well I wont really get any support from the company, outside of great forum members here.

Honestly, its much better to move onto Unity when you get a chance. Dont worry about the growing pains. There is a thriving community, coming up with such clever things, as well as an active company. Seeing the company host a unity only conference, seeing all these amazing games made with that engine, is such a nice feeling, and you can have it too!

, that makes sense, and I agree gs3d could indeed have continued to be really amazing.

I mostly agree with you guys. By now, I see no way that acknex is going to make a comeback unless it's completely remade to live up to todays standards.

I still enjoy using it for smaller test or simple tools (like the image processing app I made recently) but in terms of actual game development I'm not sure if I'll keep using it in the future. I do have a 2d (pixelart) prototype that I really like and might use at some point but other than that I'll probably go for Unreal Engine.

But since I'm doing what I do solo, I don't even feel like taking a look at Unreal Engine right now. Mainly because I don't think I have the skill (and time?) to finish a full-blown 3d project (edit: also UE4 looks really complicated and somewhat bloated to me)

I recommend libGDX for 2d games

One thing that attracts me to UE4 is Blueprints, a schematic way of programming your UE4 game/application. I was skeptical and have not delved into it yet, but just about everyone I talk to tells me that Blueprints is both powerful/flexible and easy to use. For a virtual non-programmer like me, that is pretty attractive.

after lite-c Blueprints are easy. it is also programming but in a visual way, the logic is similar... (but object oriented)
the same is valid for UE4's material editor, after some 3dgs shader knowledge it is relatively easy to use.

I really recommend UE4 for any 1st or 3rd person game, especially for multiplayer. there are tons of basic/advanced tutorials and free stuff available (large community with talented people sharing projects/plugins) enabling you to make a high quality game much faster than with 3dgs. the editor gives you great options even for creating AI for your NPCs. and it is also easier to find team members for a project...

I'm glad @sivan brings this up. All the talk of blueprints like you have no need for programming logic is wrong. True it is easy and visual people like artist find it easier to work in, but it's still programming. Building "IF" trees is a lot of mess like in the "Paper2d" example.

Unreal tools benefit teams because there is a lot to learn. Each section of unreal dev is best mastered by a single person working in a team. There is so much more to learn and do, it's hard for a solo dev to get it all. I can only hope the community is helpful. As you're sure to get to a point that you need help. Just watch a tutorial about importing a model and setting up animation and you'll clearly see why that is a single job in of itself.

yeah in blueprints you need similarly declare variables, create functions or macros, but calculation intensive stuff can get really messy because of the lot of nodes...
if you want to make a professional game you need a team, else you need infinite time just in the case of my RTS project except if it is really simple both in graphics and programming.
beside my project I joined a team where dealing only with AI, but also had to dig into animation, networking, version control, and a lot of other areas. luckily, the editor tools make it really easier, and you can reuse the knowledge later in other projects, not like when you work with project specific custom tools...

Very sad to see that another one is going... But I can understand you! For the same reason I'm also searching for another engine cause I want to bring my next game RPG PARTY to the Nintendo Switch.

I made a prototype with A8 (you can find it in the Showcase section ) but a game focused on local multiplayer makes no sense for Windows. Because I just use 2D I think I will switch to YoYo GameMaker engine. As far as I heard, they will support the Switch soon. And I think it is a lot easier as Unity (at least for my purposes).

However, if I would create a new Windows-only game, I would choose A8 again! I love to work just with SED and my graphic program - no huge world editor.

/////////////////////////////////////////////////////////
Now I've got an idea: Maybe we should start a Kickstarter campaign to bring A9 to life with multiplatform support ???????
/////////////////////////////////////////////////////////
What do you think?

The question becomes ... why? Why bother? With the likes of Unreal (for free, basically) and Unity, why try to resurrect GameStudio? The only reason I could think of to resurrect GameStudio is if a new version did something really significant ... really revolutionary (something a lot more than multiplatform support). Because, otherwise, we already have it elsewhere.

^ +1

I'd rather spend money to move projects to new engines. Forget the whole "Save our engine" thing. It's time to "Save our projects and talent."

I'd put my extra penny into a project Kickstarter. Or I'd put it into a mentorship that links ex-3dgs user with current ones to quickly get them started in new engines. I mean if my pennies will help @sivan mentor @preacherX so 'RPG PARTY' can get up and dev'ed on UE4 faster. Well, that's money better spent in my book.

@Superku has his current project at 95%. That's too late to move it. But I hope after he can quickly get up and run on a new engine.

I know for a fact we talked Kickstarter years ago to save this engine. We even asked jcl who said something like - "Sure go right head". That was after the engine was already sick. Now it's litch!

"Save our projects and talent." And let the litch lumber in the internet dungeon for all eternity.

If you hadn't already moved to Unity I would've recommended Unreal4 instead. C++ is just a better language overall for game development (imho) and having free access to the engine source just seals the deal. At my first game industry job I learned the tools in two weeks, then was able to modify the engine to support instanced skeletal actors within a few months super easily. It was awesome.

All in all I believe Unity gets more attention than Unreal4 because it was leagues better than anything else for a few solid years, but Unreal4 is better on the whole. If anyone else is looking to move away from Acknex, try Unreal4, I'd be surprised if you end up regretting it.


Yeah, for the past few years! Come on Superku, time to finish that thing!

Just to make some "advertising" fitting the topic:

lemming and I are currently trying to develop an "engine clone" in terms of engine style...

https://github.com/TeamRetro/acknext

I know that we can't compete with Unreal or Unity, but we're trying to achieve a better level of usability than current acknex, but with a really similar workflow (create a script, create some assets, press F5, run your game!)

Maybe we'll get into a state where we can say "hey guys, wanna test?!", but that day is far to come...

Also: If you guys want updates, i can open a new thread here in offtopic...

@MasterQ32, awesome, bookmarked. An offtopic thread might be a good idea to let more acknex fans know. Also love that subtle name change.

Hahaha love to see dear imgui and the stb headers in there!
Interesting project, I'd be interested in a thread.

I am learning DX11 instead of moving to another engine. Just a matter of fun.

A couple of weeks ago, I wrote a basic dx11 renderer, aswell

Though, for more visually demanding applications I'd still go for an engine like Unreal, simply because it has some advanced features that would take too much time to write myself (temporal AA, texture streaming, GI, light baking, sophisticated tools, etc. all with pretty good optimizations)

Haha I'm trying...
I'm so done with making linear story based game(s) (including cutscenes and all that horrible stuff), I won't touch a game idea like that for ages after Superku.


Never was into Unity and looked forward to getting into Unreal 4 with C++. After a few weeks of trying to code in Unreal 4 - procedural game and mesh stuff - I was pretty bummed though. I was fighting the whole framework more than doing anything else. They try to make it approachable with blueprints and a few often used classes you derive from, yet I find that detrimental to actual coding in (UE4)C++, similar to the post(s) in this thread: https://www.reddit.com/r/unrealengine/co..._engine_4_isnt/
Managed to procedurally generate some stuff, then had enough of UE4 for now sadly. Tried Unity a month later and, much to my surprise, I found coding in it a lot more enjoyable. Haven't tried proc gen stuff in Unity yet but - in contrast to UE4 - I'm looking forward to it.

Despite my experience I think UE4 probably is the better engine and toolset still - if you can somehow manage to get used to it.

EDIT: @MasterQ32, interesting, keep us updated!

Well to be completely honest, for as much as I praise Unreal4, I've built my own engine once again for my next game -- and one of the main reasons I did was because I do so much procedural stuff in it.

Over the three months it took to do my engine modification to U4, a large part was just spent dissecting their render pipeline. But in its defense, I often found that the engine was built the way it is for good reasons. The unreal editor is vast, even from a user standpoint, and its code is tightly interwoven with the engine core. Despite this, I usually found that the code is as straightforward as it can afford to be, given all the interfaces it needs to provide for services like physics, networking, rendering, editing, etc. So perhaps this is my lack of experience talking, but it's hard for me to imagine anyone making something as comprehensive as U4 without compromising the simplicity of their code somewhat.

On the flip side, I finished working at Monolith recently, and their code appeared to have a much flatter, simplistic structure overall -- but this simplicity actually made the code less readable in my opinion, more prone to bugs, and definitely less functional overall (particularly evident through the engine tools). So there are much worse things out there than UE4 imo.

Can you elaborate on how simpler structure made the code less readable and prone to bugs because I'm having troubles imagining that.

The whole point of having highly structured code is to improve readability. Maybe I wasn't clear, but my point was that I found Epic's code more structured than Monolith's, which is generally a good thing. I did not find it any more complicated than it needed to be.

I say Monolith's code was less structured because the various modules (ie files, projects, and classes) were divided up somewhat haphazardly, it was not clear or consistent what modules owned what systems, there was a real dearth of useful comments and documentation, and plenty of overgrown functions/files/classes changing state from within and without in lots of non-obvious ways. In a word: spaghetti code.

Unreal was not perfect in any way, I came across some notable examples of the exact same problems there as well (plus some fresh ones I would call "macro magic"), but on the whole I just found their code easier to parse because it was more self-consistent, logically segmented, and coherent overall. But I guess that is what I'd expect from a company dedicated to the task of building the best game engine in the world, and having the budget to do it roughly 10x over again, versus a company tasked with pooping out a AAA game in three years or going bust.

I went on with unity quite a while ago.
I'm lazy and not very good in graphics and fancy stuff, so I don't push unity anywhere near its limits anyway.

It just works and does its Job. All I need.

However I don't know whether I'll ever create another game. I'm sick of this Lone Wolf life.

Try to join a team! I was in the same shoe, moreover it gives you a lot of new experience and fun, beside some extra load and responsibility. I'm sure there are many unity teams looking for members, similarly to Unreal.

I joined a team just for future royalty, and it seems to be now a good decision, I have learnt a lot about multiplayer, version control, team work, and got useful hints from more experienced programmers. For a paid job I would need more time, and deeper C++ knowledge... maybe next time I can get a good AI related position as remote work.

Nah, I went for sports and I'm pretty Happy with it. Never expected that.

Because it is so easy to program and you can program much faster!

For example, I just spoke with someone who is studying Game Design with Unity and asked him how I can create a sprite in Unity with code:

The code would be something like this:


Vector3 rndPos = new Vector3(10.0f,10.0f,10.0f);
GameObject Go = new GameObject();
Go.transform.position = rndPos;
Go.transform.localScale *= 10.0f;
Go.transform.rotation = Quaternion.Euler(0, 0, 10.0f);
SpriteRenderer renderer = Go.AddComponent<SpriteRenderer>();
Sprite tmp = Resources.Load<Sprite>("Stein");
renderer.sprite = tmp;


In lite_C I would just use this:

ENTITY* Go=ent_create("Stein.png",vector(1,1,1),StoneBehaviour);
Go.roll=10;vec_fill(Go.scale_x,1);


Or does someone know if there is an easier way to do this in Unity?

Unity works better using prefabs. In the editor you create your sprite gameobject with all the settings, components or scripts you want, then you make it a prefab (dragging it to your project files). After this you can instantiate it via script with a single line of code.

It seems like a lot of people judge Gamestudio based on the fact that they know it and because Unity/Unreal et al do it differently, it's inherently bad. Smells a bit like sunk cost fallacy.

The sprite creation example seems a bit contrived for example. Yes, lines of code wise, Unity is longer. Yes, it does have more boilerplate. BUT, in general, how many times are you writing this code? In reality, you'll have a certain type of sprite that you want and you'll have a factory method to create it that does all of the boilerplate set up code for you. Basically exactly what ent_create is, except you create it yourself.

Gamestudio is limiting! To stick with the example, what if you don't like the default behaviour of ent_create? Now you start writing your own boilerplate around Gamestudio and can easily balloon your one liner to a 50 liner. Even worse, there are limits in Gamestudio that you can hit fairly easily and then you are at the end of the road. You can't hack around certain internals and that can be extremely limiting. The more tools the engine gives you, the more complex the code might seem but the more freedom you have and less limits. Sure, Unity _does_ have its own sets of limits, but they are quite a bit harder to reach than Gamestudios.

Now, don't get me wrong, I still don't like Unity personally. But that's not to say that it's not a perfectly capable engine. Instead of trying to do an apples to oranges comparison, why not give Unity or Unreal a real chance?

This thread reads to me like a guy who has only ever put screws in by hand and is given a powerdrill for the first time in his life. Dude goes "Yeah, you see, I prefer to rotate it myself and I also never need to charge my screwdriver. Why would I need such a thing, it's way to complicated?". My dude, you missed the whole point of the powerdrill.

@painkiller.

Thats what i ment I am studying unity now in my spare time
and it amazes me how many lines are needed to do something that in
3dgs is 3 or 4 lines of script I know 3DGS fades out so i have to learn but man it's giving me a headache

@preacherX:

I Mostly agree with Sid.
Plus, the difference between those two code examples is that the lite-c code has the position cramped into the .._create-line. Other than that, Acknex just hides a lot while (- from what I can see in the code snippet -) Unity offers you more possibilities here. The resource loading is most likely a lot better than Acknex's, too.

Ignoring all that, you could simply write a function for either engine and use it as a one-liner to create sprites. Yes, the additional freedom in Unity/Unreal also requires you to write a few more lines at the lower level, but once you have that intermediate layer of code working, this difference is not really a problem anymore. Honestly, I'd prefer it that way in acknex, too, because I regularly run into problems that the engine is making difficult or impossible to solve by obfuscating and hiding things in engine functions to "make things easier". Now, I don't wanna turn this into an "acknex is crap"-rant but I don't fully agree with your point.

(also, I don't wanna be nit-picky but there are pointer errors in your code that only work due to lite-c's automatic (de)referencing. I'd recommend anyone who uses Acknex to turn that off)

Hi,

It is not as difficult as it looks like.
But you have to know that you need two different objects.
First you need a sprite object. This can simply be created with Sprite.Create



But this is only a sprite object in memory.
If you want to render this sprite, you also need a gameObject for it (or many gameObjects
if you want to render that sprite many times in the scene). This gameObject is similar to an 'entity' in 3DGS.

GameObjects can manually be created in the level editor, or at runtime via the following coding:


A gameObject is only something like a container for all kinds of entities.
It can be a sound, or a mesh, or many other things.
GameObjects can have one or more Components who defines which functionalities this object has.

Such Components can be 'MeshRenderer' or 'AudioSource' or 'VideoPlayer' or physics effects,
or hundreds of other things. And you also can develop your own Components (classes).

And one of these Components is the 'SpriteRenderer'. It is used to render sprites in a scene.

So if you have created a gameObject for the sprite at runtime, you also need to add a Component for
rendering sprites. And this is done by:


And then you only need to assign your sprite to that SpriteRenderer Component (set parameter 'sprite').
This is done by:

That's all.
Okay, then you also can use e.g. transform.position to position your sprite, or transform.rotation,
or something like that. Because each gameObject automatically has a 'transform' Component which
can be used to position, rotate or scale a gameObject.


Here is a typical example for a class, developed for Unity.
It has one parameter for the texture (public Texture2D tex;).
It creates an empty sprite renderer, with a light grey non transparent background color.
And it creates a button with text 'Add sprite' on the screen.
When you press that button, it is assigning the texture to the sprite.


Here the documentation:
https://docs.unity3d.com/ScriptReference/Sprite.Create.html

Greetings,
Harry

After some hard hours of Unity learning and a skype session with a Unity insider I think I got it!

These are my first steps with Unity:
https://www.youtube.com/watch?v=NeY7oAZp2Ro&feature=youtu.be

Not much yet to see, but I'm very happy that I understand it and now I'm coming closer to my goal bringing RPG PARTY to the Nintendo Switch!^^

I have to admit, Unity have some cool features (for example nice particle editor). However, for a beginner I think scripting with lite-C is easier to understand. I think if I had started with Unity many years ago without any programming experience I would had been lost!

Just for shits and giggles, this is the terse version of the Unity sprite code (I kicked the weird scale because the Lite-C version sets the scale to 1 which is the default for Unity anyhow (same of GS, so I don't really understand what it's there fore to begin with).



No idea what I'm trying to say with this. Ya'all need to learn how to move on in life. OOP is great, and once you grok it you won't be able to go back to Lite-C.

This looks really clear!

After all, it is not so hard as I thought and you're right, sometimes you have to move on! ^^

Something strange I learned in Unity and can tell all beginners working with Unity:

In lite_C you could do this: "Go.x = 10;"

In Unity you can only read the single vectors like " if(Go.transform.position.x > 10)" but you cannot write the single vector like "Go.transform.position.x = 10.0f;" !

You would have to use something like this: "Go.transform.position = new Vector3(10.0f,Go.transform.position.y,Go.transform.position.z)"

Some more letters to write but if I can go to the Nintendo Switch in exchange it is okay for me!

Yes, because Go.transform.position.x is just a float attribute and not a vector. So you need to call the constructor to create a complete Vector3 instance.

The game object in Unity obviously uses a component pattern to decouple code. This adds a lot of flexibility but makes the code more complex which makes it harder to understand for beginners. But the larger your projects gets the more you will benefit from such patterns because if your requirements change late in development you will spend a lot less time to modify your code.

okay, I think I have accidentally found the perfect game engine for 3DGS refugees: Xenko https://xenko.com . Free for individuals, uses C#, its editor is called as Game Studio and objects are called as entities , and you can use 3DGS entity action styled updates (see Asynchronous scripts) :
http://doc.xenko.com/latest/en/manual/scripts/types-of-script.html
(it is WIP, a lot of features are missing, so imo not a real option currently)

@sivan: sounds kinda promising, although I wouldn't expect too much from it...
also, personally I'd prefer C++ over C# ;(

@sivan, that looks like a good alternative to Unity, good find.

tbh I would not use it, I just wanted to share it because of the funny correlations. I also prefer C++ (and UE4!), but Unity is also a good choice. btw its code snippets look simple, so might be easier for beginners similarly to 3dgs/lite-c...

if choose Unity or UE4, you can get many-many tutorials, source codes, assets, information, and partners, which can be more important when you jump seriously in game development.

You're right! When I have a problem with Unity, I can just use Google and get the answer in no time!

After my first week with Unity I have to say that I really like what I got so far! At first I was afraid of the "huge editor" but now I'm loving it - the prefab system is also a great help.

Plus it is free (until you earn $100k in a year ) even for exporting to consoles like the Switch!

So I will go on with it!

It reminded me of Unity when I looked at the code snippets and editor, so I meant more that it could be a possible plan B (/easy transition) when Unity for whatever reason isn't going to cut it. I am not sure yet if I really like Unity; I like the component based scripting, I beginning to like c#, I like prefabs, I like parenting/childing and the editor.
I don't like that it crashes often, I find the documentation lacking and I encounter specific annoying things like e.g. reading managed code from a dll its sooo slow (probably the garbage collection's don't like each other or such), or e.g. anims not working after importing but do work when I import an other model etc (the latter might be solved now when I looked at their latest changelog).

Note that you still need extra licences to publish for console (need a devkit and store license for each target).

True! But for some other engines you would also have to pay if you want to export to consoles! For example YoYo's GameMaker: 800,- $ for console export PLUS the extra licences.

UE4 editor is quite stable, but I have found it a good practice to upgrade to next version only after the 1st hotfix, e.g. 4.18.1. Upgrades also come together with code changes, sometimes it is tricky to follow, fortunately the forum is full of helpful professional programmers. I don't use too much blueprint scripts, but I have heard there could also be issues...
he fbx importing works fine, but the UE4 export feature is removed from Mixamo. as a consequence a user made a script for free that solves the problem

Never. You instantiate a prefab after WYSIWYGing your sprite together. Which is just as long as ent_create().

By the way, here is my progress with Unity after about one week:

https://youtu.be/IczMpOGW6NM

There still many things missing like sounds or damage points / effects but this will come soon. There also no monsters yet so the two heroes have to fight against their "Prefab" clones! ^^

like a battle in Heroes II btw looks really nice.

After some month working with Unity I have to admit that it is really cool. By the way, if you want to take a look how I work with it, I made a video about it (only in german available):

https://www.youtube.com/watch?v=9W9hYPzcJbU

You should check out Godot (www.godotengine.org). It's pretty amazing and, best of all, free.

As long as you don't earn 100.000,- $ in a year, Unity is free too. And if I would earn 100.000,- $ a year with my games, I will pay the price with ease!

Another problem: Godot don't support exporting to consoles like the Nintendo Switch - this would only be possible with the help of third party developers and I suggest that this would cost money too.

So the mighty export feature of Unity AND the great documentation/ tutorials/GoogleHelp were the main reason driving me to Unity. Until now I'm very satisfied with it.

I took a look at Godot and while I do think it's neat I would probably only use it for 2D applications.

In terms of 3D rendering I was not too impressed by it. Of course you can't expect it to have the same features as UE4 but I also saw a few things that I didn't like:
There's quite a bit of room for optimizations and it does some questionable things including "improper" blending of bloom and allowing too extreme values in the PBR-shading. Aside from that, parts of the shaders that I looked into seemed like copy-paste (for example the tonemapping operators with faulty/incomplete implemementations). That being said it's open source and I already experimentally changed the tonemapping and bloom blending - which worked, but I still don't think I'm going to use it for 3D stuff.

In that regard I'm leaning towards Unreal Engine. It's C++, the 5% fee seems fair, it has a nice workflow and it satisfies my high visual standards aswell as graphics programming needs, lol.

is 3dgs the easiest Games Engine for C language?

I have make jams with python, c#, JS htmpl5 PHP SQL, SDL-Basic, FreeBasic, GML(GamemakerStudio1.3), Fusion(klickabla 2d Gameengine)and 3dgs,

but for now I'm read a C11 Book to have real deaper skills in a language.
So in 3dgs I can make Games with C in for now.
I wont learn C not only for games, but I use 3dgs because I have problems to make Code:Blocks fit for SDL and CSFLM (c version of SFLM) i have now power mor to check if I can the C++ dokumentation use in C.

or is ther another way to use C18 fpr 3D game developing? or may another C game engine?

no idea, but I would rather choose the engine according to the needs of my planned game (built in features, editor features, artist workflow does matter a lot), then check the available languages they use. imo you could easily switch to C++/C# from C.
but if your focus is on keeping using C, then it is a different story.

later I want switch zo c++ or if i making more games to c#, but first i want relativ completly understand C i make some thing with microcontroller and i have so often interest to the compilers and hope with c more understanding low level like driver compiler tool chains fo other devices and so on

Using C for game scripting is stone-aged. It is still quite common in embedded development, though.

nice to read that.
maby C games are retro