Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 21 Mar 2011
Offline Last Active Yesterday, 10:45 AM

#5194748 UDK 4 vs Unity - Which is better and easier to use to make a first person act...

Posted by Gian-Reto on Yesterday, 04:44 AM

AFAIK Unity and UE4 are pretty much on par when it comes to usability and features.


The ease of use of editors and tools are most probably more or less on par, altough I never took the time to really compare it (others will be able to help more here). I can only say I am a long time Unity users and apart of some small  things, it is a fantastic toolset that lets you do almost anything with ease. Of course, IF YOU ARE EXPIERIENCED ENOUGH!


Now, from what I have seen, UE4 might be a little bit more powerful with Unity only catching up with version 5 coming out in the next few months, and UE4 still having some highend features already added Unity currently is lacking (like temporal AA for example)... Unity 5 will have its own set of features not in UE4 natively yet (like enlighten), but anyway, featurewise they will be more or leass on par if you include available 3rd party tools.


I would say, performancewise UE4 might have a slight edge against Unity 4 because parts of its Engine core is still pretty dated and is using patched together solutions (for example no REAL deferred renderer, just deferred lighting)... that might change with Unity 5 though (a true deferred renderer is promised).

On the other hand, I would give Unity a slight advantage when it comes to documentation and community. I didn't really had a big look into the UDK and UE4 documentation and community, but Unity has longer been in the Indie-Scene-Game, their documentation is outstanding, the community is vast, and there are literally tousands of third party developers creating plugins, shaders and tools for it and distributing it over unitys asset store (part of it is even free).



The real difference comes in when you look at pricing. There is no better solution here, just different price points for different people:


1) cheapest is Unity Free. It is, as the name says, free of charge. You get some cut features like post processing, render textures, no deferred renderer, less batching options, no profiler. This will ONLY really matter when you are targetting really high-end graphics though.

2) UE4 comes close to Unity Free: it can be yours for 20$. that is right, you pay 20$ for a single months subscription, download the engine, and cancel your subscription. You can continue to use the engine, you will just have to pay 20$ again to get updates.

A warning though: If the product you create with UE4 makes of 50k$, you will have to pay 5% royalities for everything over that 50k$.

3) Unity Pro gives you the full Unity toolset: 1500$ per seat (or the equivalent in monthly or yearly subs... you will not save money that way, as you pay the same after a little more than a year). Yes, it is expensive. If you develop something that makes some money later on though, you will save that amount of money with ease though. 1500$ equals what you pay in royalities for UE4 if you make >80k$ with your app or game.



Now as a fair word of warning: to you as a newcomer, the difference between these options will be small. You will have a hard time really using all the options coming with Unity Free as a newcomer lone wolf, save all the advanced options you get with Unity Pro or UE4.

If you are ready to sink 20$ into getting UE4 you will certainly get a more powerful toolset than you would get with Unity free, just be aware, you might pay that 3-4 times a year, if an important update for UE comes out you cannot or don't want to skip, so factor in a yearly cost of 50-100$ over the course of your work with UE4.


But you need to be aware of the vast amount of time and skill needed for even a simple 3D game, you will need to be able to program, you will need 3D models (meaning you either learn the skills for 3D modelling or shelling out bucks for stock art or freelancing, IF you don't find free models that do the job), and you will need to learn a lot of basics about 3D rendering and engines, before you can even start to work on your projects.



Really, stick with Unity Free until you get a fair understanding of 3D Engines and how to create games. Moving over from Unity to UE4 is possible at any time, and while C++ is not C#, and the Unity Editor is different from the Unreal Editor, 60-75% of your knowledge will still be transferrable. Don't worry too much about the tools you use, worry about honing your general and basic skills that will apply to all tools and languages you will use over the course of your career (professional or hobby doesn't matter), and worry about your efficiency and planing skills (Most probably you have no idea yet how many years of your life the game you dream about at the moment might consume, if you don't compromise a lot and get much better skills)




Unity is much more mature and the assest store has a good selection, unreal is still starting off.


Uh... Unreal has been around since 1996, Unity wasn't even announced until 2005



Unreal is pretty new to the indie scene nonetheless. Until UDK, only big studios were able to afford Unreal, and even UDK was, while much more powerful than Unity 3.X, held back by that attrociously high royalities of 25%.


Unity has been targetting Indies and hobbiests from the start. It always had a free version, and an asset store. That is why Unity still is in much more demand among the smaller Indie studios than Unreal.

Depending on how much traction Unreal gets with its radically changed pricing structure and full source for UE4, that might change. On the other hand, for the first time in Unitys history its engine is no longer far behind the big commercial ones when it comes to features and performance with Unity 5, so who knows, maybe Unity will revamp its own pricing again (as it has in the past as a reaction to UE4 pricing changes... thanks to that, you can now target mobile for free, you get hard shadows in the free version (which can be turned into soft shadows with an inexpensive asset store plugin)). 



I wouldn't call Unity more mature than Unreal, Unity until Unity 4 had an very dated engine core, and even in Unity 4 there is some legacy stuff that needs work. Unity 5 might see Unity finally catching up. 

Still, the Asset Store is a fair point, Unity's asset store is most probably the best stocked asset store out there.


And really, Unreal IS kinda new to the low cost engine game.... At least Epic recognized both the danger of Unity becomming a threat (which kinda forced its way into lots of smaller studios and also schools lately), and the money that could be gained by hooking startups and new devs to its tools, so they continue to use it when they finally have the money to pay the full license...

#5194569 Tutorial Series

Posted by Gian-Reto on 25 November 2014 - 04:04 AM

hey riuthamus, good to hear everything is on track. Don't worry about the delay, RL happens to all of us sometimes (its all graphics and no content, but sadly you cannot skip the cutscenes.... sooooo many annoying Quicktime events! :) )


It's actually a relief to hear it is just a job related thing and not something graver (like health related or something like that).

#5194564 Some help with creating a Street Fighter style Beat Em' Up game?

Posted by Gian-Reto on 25 November 2014 - 03:37 AM

What Shippou said....



Also, about the graphics:


SF2 is a 2D Sprite based game, so all graphics will start with 2D Drawings. That means, you can use Gimp or any other Image manipulation program (Gimp is free, but tools like Photoshop, Manga Studio or Sketchbook pro can be used as well (each has its pros and cons)) to produce your Graphical Objects. Yes, that means you need drawing skills.


Animations were done with sprite sheets back in the day, and AFAIK this is still the only way to do high quality 2D animations. That means drawing a new picture for each animation frame, combining them into a sprite sheet, which later can be imported into your engine (the engine will then need information about which animation frame is located where on the sheet, and then you should be ready to combine this into an animation).


Soooo... either you already have good art skills, you are dedicated enough to learn it, you are happy to produce some horrible looking programmer art, or you get "outside help" - free or paid stock art from the net, or looking for a like minded artist to help you out.



About the language:


Apart from using Cobol for Game dev, almost any language out there can be used to produce a game. More important is the question, what frameworks and engines are available to shortcut your way, and save you from doing low level plumbing when trying to work in an efficient way.


Shippou already gave you a good example. But I agree with shippou here, if you are not extremly resistant to the frustrations of steep learning curves and an almost guaranteed failure the first time, start with simpler things until you get more expierience.



In my mind such a game can be made to be quite simple.


If you limit the game to one kick move and one punch move per character, two characters, and one special move per character this is within the reach of any person new to gamedev and possibly only as complicated as maybe something like Tetris or at most a simple platformer.



While I agree to your general statement, I would NOT compare it to tetris.


Yes, you can make blocks kick each other without animations.... still, the game logic is not as simple as tetris. This might be nitpicking, but there is another caveat:


Most people that want to create a SF2 like game want it to look SF2 like. And stuff like graphical fidelity and animation quality, to some extent, are just as much part of a game as game logic.

So even leaving all other issues out, a game that does not look at all like the game the newcomer targetted will not motivate him as much as a simpler game, that ended up more "on target" so to speak. I am pretty sure anyone will get a decent looking Tetris running.


You can simplify the fighting game to stick men, still, without animations it will look off. Not only that, playtesting and debugging becomes a chore without visual aknowlegement of your button presses (so you will have to insert graphical helpers just to make sure you can distinguish between punch 1 and punch 2).



So in my opinion, you CAN simplify a Fighting game to Tetris level of graphical fidelity and game logic complexity... the resulting game will be nothing SF2 like though. And might still be harder to develop and playtest because you are trying to reduce a more complex game logic to a simpler one


(Tetris logic is simple: have a line? the line should disappear, your high score should rise. Blocks reach the top? Game over should be triggered. In a fighting game, even in the most simple case, you need collision handling, MOST probably different punches and kicks (because people expect that), HP bar (again because it is expected of a fighting game))

#5194384 Best language for mobile apps

Posted by Gian-Reto on 24 November 2014 - 05:29 AM

I was waiting for other replies, but i guess not many people know or cared to anwers the question since theres over 100 views but 1 reply LOL. Thx TheChubu, i think i'll jump into the mobile app development field through Java. Then i'll branch out of course.


I think the Chubu basically answered your question 150%... there are just not that many options for systems that expect a certain language natively... which would be objective-C for iOS and java for Android.


The Chubu additionally gave you options to crosscompile from a language that is not "officially" supported to a platform that expects a different one, which is kinda a requirement for easy deplyoment to both leading mobile OSes.

No need to branch out and complicate your development when there is a tool that does the job for you.



So yeah, don't expect many more ideas to come up.


Other than "Unity does it for out of the Box"... but I guess you are not interested in this engine, else you wouldn't have asked the question to begin with (If the idea of using an engine itself is not so unappealing to you, know that most big engines followed suit and give you the same option now. I know Unreal does for a fact for example).

#5194382 MAKE A CHOICE engines

Posted by Gian-Reto on 24 November 2014 - 05:17 AM

disclaimer: i'm not cool in Englishhappy.png

Hello folks

i need your help, i can't choose an engine...


i need wich one that can render millions voxel-like objects with out any problems. (Yea minecraft killer i want to rolleyes.gif )

i put my eyes on these guys: Source Engine (Is it still valid? or only MightyOne in plumber inc. use it), Unity, UnrealEngine, leadwerks game engine, CryEngine.

And yes i want to integrate my stuff in SteamWorks.

Or you can advise other cool engines.

please helpwink.png


Micecraft killer... good luck!



But seriously:


1) There is no engine currently that can work directly with what you call "voxels". All engines on the market work with polygons (yes, that includes Minecraft). So if you are talking about rendering, you are talking about millions X <amount of polygons per object> polygons per frame... WOW! Think hard and long about this requirement, you might be limiting your game to only running on quite highend machines here. ESPECIALLY if all this objects are not static and thus CANNOT be batched into single draw calls!

There is another component at play of course, the "Voxel Part" of your engine (which has nothing to do with rendering, but with keeping track of your Voxels, for example when you add and delete voxels) will also need some serious grunt on the CPU / Memory side of the system, depending on how it is implementet. Again, your "millions of X" requirement might limit the minimal system your game is able to run on.


Are you sure you really NEED to render millions of objects at once? Are you sure you NEED millions of objects in the Scene at once at all? No engine today will be able to do that without some serious tricks involved (like batching draw calls, and discarding hidden objects), which again limit what you can do with your "million of objects", and no engine will be able to do even the work involved to save the GPU from complete overload in this situation without some serious hardware grunt in the system.  

So really, think long and hard about what you REALLY need...


2) Any of these engines can be used. They are all capable 3D Engines for POLYGON graphics. NONE of them will do Voxel handling out-of-the-box. You can get 3rd party assets from the asset store for Unity that will do Voxel Terrain handling for you. Maybe there is even a general Voxel System. All of this costs money though (not much, mind you, around 50-100$, which is nothing IF the system is written in a professional manner).

If you are not ready to shell out money though, you need to do one of 2 things:

- either keep on looking for an out-of-the-box Voxel based engine (C4 has Voxel Terrain out of the box, but its not free), I know there was a thread on this same forum some months ago where another poster was looking for a Voxel engine, and somebody produced some links.

- Write the voxel management and voxel-to-polygon system yourself. You will need to be quite good in programming, this is a seriously advanced subject.


3) If you want a list of engines, visit the engine DB at devmaster.net

#5194058 Bringing it all Together (What's next for a beginner?)

Posted by Gian-Reto on 21 November 2014 - 07:07 PM

I would, if I were you, start to really plan two different paths you have to walk at the same time, at least for now:


- Getting programming expirience and start building small projects (I GUESS you want to build games, but that is not so clear (which, by itself is a problem. If your not 150% sure you want to build a game, better leave it alone... to much work for to little gain involved otherwise))

- Getting a job.


Yes, I said it. Get a job. Now. IF you think you are good enough, try to apply for entry level programming jobs. You might get lucky. Without a good degree that might prove difficult though (which, again, I don't know if you have from your OP).

Important thing, to me, is: you need to be able to pay the bills. This is the most important thing at the end of the day. Without money no food, no PC to program on, and so on.

If you need to be self sustaining (I assume here you don't live with your parents anymore), hobbies, unpaid freelancing gigs, even education have to be a second priority in your case.


ESPECIALLY as in game dev, even more if you really want to continue down the Indie route (what I read from you wanting not only to program, but also modelling and art), a project can take you a long time to finish, and while smaller games will take up less time, creating a full portfolio from scratch will again take time.

Time where you will need to rely on your day job to pay the bills.



Now, as to the question at hand. Personally, I would go with whatever really looks interesting to you. If you have no passion for a project, its hard to keep working on it without pay or pressure.

Of course you need to be brutally honest with yourself: You will not be able to build an MMO in a lifetime, and even a good looking shooter takes a lot of time.


Start with small games (Tetris, Pong), and this time concentrate on finishing it. Maybe even create the art in a vector graphics program. Then move on to bigger challenges.

#5193641 First Game

Posted by Gian-Reto on 19 November 2014 - 11:53 AM

That's my plan. I love the pixel graphics of the "retro" games. I don't think it will save me time, in fact I think it may be a little harder than anything else but again, the end result will be worth it.


I will say that because this is a long term project my plans and end result could change/adapt in time. I'm watching a few video series on Microsoft Virtual Academy that talk about game development for beginners and I'm also reading a Unity book that talks about 3D development, as this book is a prerequisite for my 2D unity book. Its going to take me months to even get to where I can "Begin" this project and I hope to have a few small games under my belt by then. Who knows where this will take my and my idea my change into something else. Time will tell. 


As always, Thanks again!



Well, never forget that you have options today:


- creating that Pixel graphics looks by creating a 3D Scene and use a pixel filter postprocess effect on it. Advantage: buttersmooth animations without lots of frames to draw, a fully 3D environment. Cons: Hard to get the whole thing to REALLY look like a 199X Pixel Graphic RPG, finding / writing a good pixel filter effect is paramount to its sucess.

- using 2D bone animation: A good way to get around having to paint multiple frames for your characters. Cons: While it can look decent for a sidescroller, almost impossible to pull off for an isometric title

- Mixed 2D / 3D world: this is more what happened later in the PS / PS2 era, but mixing a 3D environment with 2D sprite characters can give your game an interesting character. You will need to carefully tweak textures here to match them to your sprites.



So learning the basics of 3D graphics and animations might help you later on, when you want to take your original 2D Idea in a direction that pure 2D cannot support anymore.



Anyway, I don't want to persuade you away from 2D anyway. I love to play my old SNES games still, so I can understand the urge to put out something just as pixely smile.png

#5193586 First Game

Posted by Gian-Reto on 19 November 2014 - 05:29 AM


This is what I plan on doing. I've enjoyed writing and drawing growing up having written a few short stories and half of a novel recently. I am currently teaching my self to draw pixel art and plan on creating everything from this game from the ground up. Story telling is something I really enjoy. I know that it is a huge task to take on, but again for me that's the fun in it. 


Again, I'm not trying to jump into it full force and complex without any experience, I do want to work on some smaller projects, work through a few gaming books and get comfortable and then work my way up to a more complex game. As I've mentioned, I've learned a lot in the past few days already, been working on sample code to accomplish certain ideas and researching a lot. Thanks everyone for your advice!



If this really will be a longterm project for you, you might want, after you learned the basics, and feel comfortable with unity (given you invest the time to learn its features, it really is a powerful tool), invest some additional time thinking over you options before embarking on "your quest".


There are certain pros and cons to different ways to approach your task, and you should really think through what you can compromise on, what will support your vision better before you commit to something. Maybe even start a small mini project to test your ideas (Vertical slice) to see if your decision is a good one.



Examples for topics to really think through:


1) 2D vs. 3D: I know, the general word is 2D is easier than 3D.... though this is only one part of the story. Truth is, 3D always has some overhead, because there are more minimal steps involved to get something working. Thus for SIMPLE graphics, 2D will be clearly far easier to get your graphics for.


This all falls down somewhat when you start using isometric views, and want good looking animations for your characters. AAA Quality 2D Graphics is just as expensive and time consuming as AAA Quality 3D Graphics, if not more.


You should really think about what you want to achieve here. If you want to stay as true to retro graphics as possible (for example SNES Era)... go with 2D, maybe even with pixelgraphics.

If you just do that because you think it will save you time and money, or you are trying to go for the best 2D Graphics you can achieve, really think hard about why you wouldn't want to give 3D graphics a try.


Lets be honest: AAA graphics are out of the reach of any Indie. Creating beatiful HD 3D models is a huge timehog, and needs and aweful amount of skill, or money if you buy stock art.

Simpler 3D graphics are not THAT hard to achieve though. And there are a lot of people that are decent at 3D Modelling, but can't draw at all. It might be that your target art style can be achieved easier in 3D than trying to do it the 2D way.


The good news is: if you learned to use Unity, you have both options. You can try out what will fit your project better.


2) manually build vs. procedural content: this can REALLY cut your work in half (or even more), while giving you the ability for additional gameply options (procedural dungeons come to mind).

True, you will have less control over the final outcome, but there are many ways to utilize procedural content. The extreme, having dungeons and levels be procedurally generated during the game, is only one option. You will already gain a lot of productivity by letting a procedural generator generate your level in the Unity editor, giving you still the possibility to give your generated level a manual finish after.

For some things, procedural generation can even achieve results that are near impossible by hand. I for example run all of my roughed out level terrains through a World Machine network that will create beatiful heightmaps with realistic erosion out of a rather naff and rough input heightmap.


Good news here is: there are a lot of free or not-too-expensive tools for procedural content generation for various tasks on the market, as well as Unity plugins for ingame procedural creation. You do not have to write everything on your own.



These are just examples. There are other things you will have to think through... but of course, you will have some basics to learn before these questions really matter.



Just be aware you are talking about a project here that will take you years to complete. It might be a fun journey, but it will be a long one. All left to say is: Good luck on your journey, and enjoy the ride! :)

#5193478 First Game

Posted by Gian-Reto on 18 November 2014 - 12:05 PM


Of course, giving your rather modest goals (2D SNES Style -> low Resolution, simple animations, thus most probably not taxing for either CPU or GPU), you might be able to achieve quick wins when writing it from scratch. And at the same time learn something about Graphics Programming and other valuable lessons (that I skipped, and might regret missing one day ;) )


Okay, reading Glass_Knifes post and then re-reading my own I feel compelled to post a little "additional disclaimer" to my statement above.


When I say "quick wins" its not meant as "some minutes of coding and your up and running".... even something simpler will take you quite a while to write and test, and SNES Style graphics, while not taxing on the hardware, are still more complex as 1st and 2nd console gen Games like Pong or Breakout.


Quick wins in this context means "You will not spend 2 years writing the engine alone"... which is basically already quite quick, if we are talking about a full 3D engine written by a single guy :)



And then comes the justified point of your expierience level... yes, for a complete game dev noob writing even a simple isometric 2D game will most probably be a gargantuan task! You will be able to fail quicker (and thus learn from mistakes faster) with even smaller games. And maybe you get some successes along the way for the much needed morale boost.



Another point you have to be aware of is, while the graphics and sounds of SNES era RPGs are simple (compared to todays AAA games), the scope of some of these games was quite EPIC, spanning maybe 80 hours of gameplay in total. If you are not able to write clever procedural generation scripts, you will have to either compromise (write a much shorter adventure), or you will have to design all the dungeons, world maps and towns for this epic adventure yourself... which again will cost you lots of time. Level design itself can be quite time consuming.

And the procedural systems I talked about are a topic for an advanced programmer again, don't even try until you reached that level, as it can be quite complex to come up with a good system.

#5193474 Can i create a game using c#

Posted by Gian-Reto on 18 November 2014 - 11:43 AM

5 Step plan to Game dev glory:


Step 1: ask yourself if you are really ready to devote many moons and years to a long epic journey to become a game dev. Be aware that you will not write the next WoW in a matter of weeks after starting out (most probably you never will). If you are aware of the time and labour involved in game development, and are ready to invest both into your very personal journey, proceed to step 2.


Step 2: Start learning the basics. That means to read a lot of tutorials and books. Then download the needed tools, and finally try some coding yourself (you already know how that works from school... now find a list of good books (this is a good start: http://www.gamedev.net/page/books/index.html) and install a good editor or IDE, Visual Studio for example). Start writing small(ish) games (wait with the -ish part until you become comfortable with the really small games), going one step at a time (there are literally hundreds of threads buried in these forums showing the way.... use the search function). Mostly these games will be variations of classics like pong or snake, but of course, nobody is stopping you from writing your very own text-adventure with an epic twist!


Step 3: When you feel you are ready to tackle something bigger, come up with a good game idea, work on your game design, setup a project plan, think about what to do for art and sound (make it yourself, outsource it, buy stock art), build a prototype, test it, enhance it, test it, polish it, test it, alpha test it, beta test it, release it!

By this time, you will want to either go with an existing engine to cut down on development time, write from scratch if your game is small and simple, or maybe go big and write your own engine.


Step 4: ???


Step 5: Profit! Your the next John Carmack, congrats! smile.png





.... okay, maybe I overdid it with step 5. But who knows?

#5193461 First Game

Posted by Gian-Reto on 18 November 2014 - 11:06 AM

Well, I am a business Programmer that started the (kinda) same route some years ago.


I went with an engine early, and amassed 3 years of expierence with Unity now in total. I did do some "from scratch" programming during University though when I wrote a game with other students (that in the end kinda failed because of severe performance problems... which was kind of enlighting anyway. Many mistakes to learn from smile.png )


Having said that, I aimed for a 3D game from the start, and wanted to really get my fet wet with developing a game and not get bogged down with Engine development or 3D Graphics programming. That is why I choose to go with a 3D Engine from the start. I still think this was a fine idea, as up to this point there is nothing I really miss from Unity as long as you are ready to either shell out some bucks for 3rd party assets or wait for the next Unity version to (maybe) bring the missing functionality.


Your case might be different though. Be aware that altough Unity is quite fine for 2D development, it will be quite overkill for simple 2D games, and you get lots of stuff with the engine that is specific to 3D development.

There are other, simpler, more 2D specific engines out there that will do just as fine for your use case. If you don't know where to look for them, head over to devmaster.net and have a look at their engine DB.

Or follow the herd and have alook at Gamemaker. No expierience myself with it but it gets highly recommend most of the time for 2D RPGs.



Of course, giving your rather modest goals (2D SNES Style -> low Resolution, simple animations, thus most probably not taxing for either CPU or GPU), you might be able to achieve quick wins when writing it from scratch. And at the same time learn something about Graphics Programming and other valuable lessons (that I skipped, and might regret missing one day ;) )

#5193405 Tutorial Series

Posted by Gian-Reto on 18 November 2014 - 04:37 AM

Hey, give the man some breathing space. I mean, yes, its been a long time, but maybe, you know, REAL LIFE happened, as it usually does when your unto something good. Real life is a b*tch just waiting for you to finally sit down to create your masterpiece... then it will hit you hard! :)


I still hope riuthamus gets around to do a first tutorial, but if turns out its a monthly tutorial, I am perfectly happy with that. It is, after all, a free service somebody is providing on the net, so anything you get is awesome.



Having said that, an update as to IF the first tutorial is still on its way, maybe a rough ETA, or an explanation if and why the idea got dropped might not only ease the mind of guys still eager for the series, but might hype people waiting for it even more.

#5193248 The left-hand side of an assignment must be a variable

Posted by Gian-Reto on 17 November 2014 - 07:50 AM

Edit: oops, misread your intent. okay, what you want is something like a singleton, right? Why not look up how this is done in Java (just google "Java singleton").

I know you do not intend to create a singleton, but in the singleton pattern, you also have to keep a reference to an object, and try to prevent somebody from instantiating it more than once, so you kind of keep the reference inside the class itself. Might still help you if you check how they do it there.


On the other hand, you might get more helpful answers if you try to explain what you tried to do on this line.



Old content:

the variable l already is "this.l" ... this is just a keyword pointing to the initialized object. l and this.l are kinda synonims in an initialized object, but this.l will always point to the class attribute l (which can only exist once in a given class), whereas l could also point to a local var l created inside a method and hiding the class attibute inside of the scope of this method.


By using this.l, you just make sure that the compiler is always using the class attribute, and not a local var hiding it.




As a side note, do NOT use var names like that... ever. Var names should be as descriptive as possible, which means no abbrevations and shorthandforms as much as possible. This will make it no only easy for an outsider to understand what your vars are doing, for the future you in 6 months to understand what in the world your present you today was thinking, but also will make it easier for random strangers on a forum like this to explain your code without going nuts about finding the var names to put into italic smile.png

#5193225 Can i create a game using c#

Posted by Gian-Reto on 17 November 2014 - 05:27 AM

+1 for Unity from my side. If you want to have a serious engine that uses C# for scripting and has a free option, look no further.


If you are completly new to the topic though, Unity MIGHT be a little bit overwhelming. I recommend reading into the topic first, maybe start with smaller games you can write without an engine to get a basic understanding of what is going on in most of todays game engines before starting using them.

#5193223 Graphic Creator

Posted by Gian-Reto on 17 November 2014 - 05:22 AM

If you want to graphics yourself, there is not way around having to practice, at least if you expect decent results.


Depending on your art style, your skill level varies (for example "Thomas was alone" style graphics just needs you being familiar with vector graphics creation of simple boxes and lines). But if you talk about Lufia or FF Style graphics, you really need to work on your skills.


The good news is though: If you are fine with using the same resolution as these old games (which is called "Retro" today, "Pixel graphics" or whatever, and makes some members on this forum puke instantly (rightfully so, it is overdone by Indies at the moment) smile.png ), your art does not need to be so good. Draw something that is good enough in a higher resolution, pixelate it, chances are, most errors are not visible anymore.

Of course, AFAIK the professional Pixel artists might also work in the destination resolution from the start, which makes it easier as there are fewer pixels to work with.



The bottom line is: there is no short path. If you want to save time or skimp on skill needed, you need to compromise. You can compromise by using resolutions and low-quality animations that were originally employed because of the tiny storage available on the SNES cartridges back in the day to save on time and skill today, or you can compromise by going with a highly stylized graphics (or completly abstract like Thomas was alone).