Rogue Like Project

Hi guys,

I'm an experimented Flash game developer, I already made some big and successful games like Rogue Soul.

I'm currently working on a bigger project for Steam which would be an huge Rogue like inspired by hits like Biding of Isaac and Rogue Legacy. But this cannot be achieved with Flash which is known for his lag issue in big projects. My question would be : do you think Unity is a suitable option for this kind of project?

I know Biding of Isaac was made in Flash, but I also heard that developers started moving the game to another language to prevent lags! I heard that Rogue Legacy had been coded in C# using Microsoft XNA framework. So basically, I wonder what I should actually start to learn for this project.

Thanks a lot for reading

 

Unity will defiantly suit your needs. C# is a good place to start.

Here is a solid resource to start with: http://unity3d.com/learn

 

I would agree, Unity sounds like a fit for the game you're trying to make. Another place to start is the new Unity 2D features, found here: http://blogs.unity3d.com/2013/11/12/unity-4-3-2d-game-development-overview/

 

Thank you both, glad to hear that.

I've already made a pong and started a shoot'em up with Unity using different nice 2D tutorials, but it's still not clear how things will work for a bigger project.

 

I came to unity after flash. It's even friendlier for fast content production than flash is. And easier to learn, if you can believe it.

I see this trend.

First code style shown in tutorials: scripts everywhere on everything with update functions on everything so each object is controlling itself. This makes a lot of sense conceptually but having lots of update functions running is (I've been told recently) not great.

Second code style is to have scripts on everything, but no update function, just lots of public functions. Then you'll have a master update function somewhere in charge of behaviors for all objects of a certain type where you iterate through a list of objects and call their public functions for their movement.

The third is something like... tags on objects at most, otherwise they're prefabs for visual and audio componenets. Everything else is done by master scripts that iterate over collections of them an control behaviors per object from the master script with functions in that script.

 

Thanks, that's very interesting and gives me a nice insight of how it actually works. But I'm a bit surprised, because having a huge update function which would controls everything else sounds not really great regarding oriented-object standards!

By the way, do you know if C# in Unity is actually considered as a oriented-object programming language?

Anyway, it's a relief to know that a former flash dev like you now prefer Unity.

 

I'm not really sold thats how it works... I think pretty much everyone has each object controlling itself via a MonoBehaviour, at least for most things, I think that Unity would sort out the functions internally or something, or its just not an issue.

 

It would be definitely interesting to find out whether or not having an Update on multiple scripts is a cause of lag in big projects.

 

Worry about that later, first learn to use the engine. Also there's some good sites out there, search for Unity patterns and practices.

 

Definitely do that, thanks.

 

You really don't want to use the second method. Check out this article on entity-components: http://gameprogrammingpatterns.com/component.html

The real important bit is at the end, where he mentions how components in an engine are stored in a contiguous array in memory. The engine runs in C++ and is likely very well optimized to run through the update loops of game objects.

Using the second technique you could store an array of references to components, but this still requires a trip to the heap for every reference (I think).

The only real way is to run some tests, its not that hard. Just create an Update() function with a nice O(n^2) evaluation (write random float noise to a 2D matrix or something) and then copy it in a public OnUpdate() function and try both ways. Even without the profiler, if you have enough copies of the GameObject you should notice a difference. Maybe I will try this when I get home.!!

 

This article is awesome. That's exactly the kind of issues I was concerned about, and I definitely want to start my learning by using those kind of good practice. Thanks!

I don't feel comfortable enough yet to make the kind of test you mentionned, but if you happen to do it, I would be very interested in the result.

 

I just finished to read the article, even if it's still awesome, I begin to hate the programming world! When you think you're reading the nicest solution ever to make your code clean, you learn that it can become CPU expensive in half cases! Well, I guess we'll have to figure things out step by step.

Anyway, thanks guys for the head up, it helped.

 

You shouldnt have a problem doing a rouge like game with unity especially if you already did one in flash. I would say look prime31s tutorial on events and delegates and you'll love it.

So imagine you want to have a boat load of spells, and maybe some enemies types arent effected by certain spells, all you need to do is not subscribe to the events for those enemy types. Imagine you had a frost spell that slowed down all the enemies, but you had a frost enemy type that wasnt effected by it, no problem

 

I didn't exactly make rogue-like games in flash, even if it was randomly generated tough. Anyway, this is a cool stuff, just put it in fav, I'm gonna watch all the serie, many thanks for the link that will help.

 

Send me a message and maybe we can work it out together I wouldn't mind helping you out. You have to enable messages on here though.

 

I would recommend moving to C# someday as it's probably going to be better all round, but for now unity js is pretty close to actionscript. There's no "wrong" way to make a game, only poor optimisation - something that can be fixed easily enough once (if) it's actually a problem. Unity is so much faster than flash it isn't even funny so I'm not sure you'll have any problems.

Just go ahead and make it however you feel you should instead of feeling cautious- take the plunge then learn to swim, it's the best way.

After taking the plunge, a few weeks later, you too, could be a surfing hippo:

 

Everything has trade-offs, don't get worked up about it. The trick is to know when and where cleaner code is more appropriate, and when/where to focus on optimization (i.e. only where it really matters, and that's going to be different per project).

 

Thanks for those nice advice, it's very comforting. I'm gonna take the plunge as you suggested