Thanks for the explanation!
I tried to do a build for iphone. but failed .
i have posted the error part from log here:
not only this demo . none of the c++ based(both c++ code and c++ plugin ) project is getting packaged.
tried both from windows pc and Xcode on mac.
c++ part never getting compiled.
I want to thank all the great folks at Unreal for taking the time to give us all this great info!!
Nice release!
Is this the best place to ask questions about the project? If so, what is the best way to add/remove tiles from the game? I’ve removed them from the Tile Library in the Grid blueprint but they still spawn and I’m not seeing anything about them in the C++ files.
EDIT: Nvm, figured it out. For those wondering you have to modify the Theme Data blueprints located in Content/Blueprints/Themes. This is called during begin play inside the level blueprint of GameLevel.
Now to figure out how to add my own abilities 
Hi,
trying to download this project with Launcher(2.9.0) but getting this error. Any clue ?
Hey, how much worse would you expect a project like this would run if you’d convert all C++ code into blueprints?
Did you do parts of the code in C++ for any other reason than runtime speed?
Thanks.
Hi tas,
We just did a quick test download against 4.10.1 and the download went through okay. Could you make an AnswerHub post and then add the link here (https://answers.unrealengine.com/index.html) so someone can take a look? Also, are you able to download other projects from the Learn tab?
Thanks!
works now, thanks!
We did parts of the code in C++ for a few reasons. First, because I’m a C++ programmer and was available to work on the project from pretty early on. While native C++ code is always going to run faster than BP code, BPs are actually pretty fast and we do use them in projects that we intend to ship. In this project, it likely wouldn’t make too big a performance difference, but the big functions where we loop over the entire grid would be the kinds of things I would usually do in C++. The thing to remember about optimization of code is that it’s important to optimize the bottlenecks - the pieces of code that are actually slowing things down. These bottlenecks are usually big loops that run often, or little functions that are called from many places, many times per frame. For example, if there were a few redundant NULL checks that happen less than once per frame, that might not be worth your engineering effort to fix. I believe we have a redundant NULL check in our touch/mouse input code because it made the code a little cleaner and it’s not enough to make a speed difference. On the other hand, if we had something like a sloppily-written FVector struct, that would be a major problem because FVectors are used frequently in many areas of the engine and game. In our game, probably the biggest performance issue is when you shatter a lot of gems all at once and we cover the screen in particles. This is OK, because a slight drop in framerate during these moments won’t harm the game due to the fact that the player can’t do anything while gems are animating and the board is being changed anyway.
In general, the way we approach C++ and BP code is to write the things that aren’t going to change or that are big and complex in C++, and let BPs call those functions if we think it will be helpful. BPs are used for things where we want an artist to have freedom to make things look the way they want to, especially things that might involve delays. For example, when gems are being destroyed, we created a C++ function for BPs to call to report that the gem’s destruction has finished. This way, the C++ code can tell the gem to shatter (through a BP function), and then wait to be notified (via a call coming back from the BP) that the shattering is complete. As a programmer, I can code these two functions, make a default version that just instantly destroys the gem, and then hand it off to an artist. It’s really more of a team issue than a code speed issue.
On the other hand, the majority of our online code, including all of the code for achievements and leaderboards, was written in BP, and there’s really no need to go back and try to squeeze extra performance out of that code by porting it back to native C++. It is entirely possible to build significant features just with BP.
I hope that this helps explain why we made the choices we did in this specific project. More importantly, the TL;DR version is that anything that’s not very computationally intensive and a bottleneck for your performance can be written either way, and it’s probably best to consider your team structure as the primary factor.
That definitely answered that question! Thank you very much Richard.
I also noticed something else, in the TitleScreen widget there’s a FlyInAnimation which is animating overlay_11 Slot’s ‘Offsets/Top’. This doesn’t seem to do anything when I play the game (haven’t tried on a mobile device yet), nor when I scrub the animation timeline back and forth.
I can’t find where this ‘Offsets’ was added from either, if I try to add an animation with +Track it will give me three options, and none will be of this ‘Offset’ type.
To me it seems this might’ve changed in some version perhaps? I’m testing it in 4.10.4. Using the RenderTransform.Location.Y on ScaleBox_0 strikes me as what was intended. It would be interesting to know.
Thanks again!
Cool, about to give it an shot with making an game like Cookie Cutter for Android/IOS and see how well it works out.
Should be interesting if I manage to actually do it and complete it.
Edit; Any ideas what the general picture resolution would be for most mobile devices? I’m assuming using images that are generally in 480p format should work fine.
I’d say develop for 1920*1080 and make sure you test in various formats (UMG has a great way of letting you see your UI in various devices’ resolutions). The image size of course depends on what you want to do with it, but keep images in 2^x size (1024, 2048 would be a good general idea, with those images containing multiple tiles for use across various materials to keep your draw calls down). Not sure if that’ll help you out but had a second to spare, so there ya go. Have fun!
Oh, and some devices are now in 4k, lol. That’s imo a bit ridiculous, unless you constantly connect your mobile screen straight to your 4K TV. Which I have never seen anyone do in my life.
Sweet thanks. Reported an bug recently about viewing other device resolutions which made me waste quite an bit of time learning it was zooming in causing crashes.
[Question]
During the Thursday March 3rd stream, Richard explained that to increase performance of the tiles (actors) they made a design choice to remove the “Scene” component. I was wondering what the impact on a game would be if I removed the “Scene” component from actors in a project. To word that differently would I lose blueprint functionality? Is the Scene component really just a placeholder? Perhaps Richard was explaining that he was able to remove it because of it being a specific situation for the project - which I did not understand if he did mention it as such.
I’ll PM UnrealAlexander as well - I’m assuming this is the correct thread. Thanks.
UandmE4ever!,
SmashRash
Hi, SmashRash. Originally, we had a USceneComponent as the root, and it had two children. One was the sprite, and the other was the collision box. The scene component was, as you said, being used as something of a placeholder. The idea was that we wanted to be able to scale the sprite without affecting anything else that the tile might include, so we couldn’t have other components as children of the sprite. However, our performance information showed that in worst-case scenarios, namely when we had a big combo and were spawning lots of gem tile actors at once, we were taking some hits on our component-creation functions. So we decided to remove the scene component and let the sprite be the parent of the collision box. This does introduce the problem of scale being inherited by children, and we don’t want the gem’s collision box to grow when the gem is selected, so we wrote special code to scale the gem and then scale its child (the collision box) by the reciprocal, effectively undoing the effects of inheriting the parent’s scale.
If you have an actor class that has an unneeded component, you can remove it in your code. Note that an actor with no components at all will not have a world transform. An actor’s location/rotation/scale are really drawn from the transform of its root component, which must be a USceneComponent or derived class in order to have a transform. Actors that don’t have a transform are valid, such as AInfo actors, but most actors will have a transform.
The issue that we had was because we were spawning a lot of actors all in a single frame, and then, in the case of a big combo, doing it again on another frame within the same second. Spawning like that is generally not a thing you do, but we did it here because this game isn’t pressing the system to its limits. As examples of other games with different solutions, when Gears of War spawns groups of enemies, it only spawns one per frame. When paragon spawns amber (the “experience points” that come out of destroyed enemies), it uses a pool of amber pickups that are created early on and hidden from view, and then reused later after being picked up. We could have tried other approaches, but for this game, we felt that this was a reasonable solution.
To answer the question about deleting scene components, I would recommend that you only do things like that in your own actors, so you know how they work and can decide what’s best for your game. I would not go around deleting them from actor classes that you didn’t write, since the parent class may expect them to be there. I personally prefer to have a USceneComponent as a root in any actor class I write where performance isn’t a problem, because that gives me the ability to adjust the position or scale of any of the other components without having to worry about them affecting components that I don’t want them to, such as scaling or jiggling the gem sprite without affecting the collision box. In this case, I got rid of it because performance became an issue.
I hope that clears it up. Please let me know if there are further questions. Thanks for watching/posting!
I’m having a blonde moment here - you’re saying they will not have a world transform, do you mean they will just not return correct values when getting/setting world transforms and local will be fine (somehow)? That sounds unlikely to me, and if so, how did you control the tiles’ movements?
I posted another question above at post #31, if anyone has a moment to check it out it’d be great… to me it seems to be a mistake there but maybe that’s just another one of my blonde moments.
Thanks!
No, with no Scene Component an Actor has no Transform (no location) in the World (so it is somewhere in the World, but nowhere exactly)
Huh. So how do they move the tiles around without being able to set any transforms? I doubt they’re using actual physics…
Awesome! Just what I needed!