Similar Content

Hi everyone! I'm currently working on a series of books about 2D Shader Development.

The idea is to synthesize a bunch of techniques that are specifically useful for 2D, even if they work on 3D as well.

I released the first book last week. It's 4.99 on Amazon or free on the series website, https://www.2dshaders.com

This is an independent initiative, I don't work for any publisher whatsoever. The contents of the books are the result of a 4-year span where I started teaching this in Argentina and USA, always making the workshop better. Now I'm expanding it to make more sense in book form.

I'd love to hear your opinions on the idea and if you get the book let me know what you think.

By the way, the examples are in Unity, but the concepts from the book should be easily transferable to any graphics api/engine.

While looking out for that pesky Terrator, our little alien is doing a bit of relaxed mining down on the new gas planet "Lelantos" this weekend....
#gamedev #indiedev #madewithunity #screenshotsaturday

I have a native iOS game (objective c, XCode build) which I am considering to port to other platforms.
Core gameplay is based on solely on geographical maps, and custom drawing over maps. It also has Core Data. This part is complete in development.
What is not done yet is: monetization, gamification (leaderboards, challenges) and multiplayer functionality.
As I think more about it, I am tempted to think if this is the right time to move to a cross platform tool such as Unity. But before dedicating time to port my 5 years side-project effort in Objective C, I really want to know if its worth it.
- Does Unity support such plugins / assets that will fulfill all my above requirements?
- Unity Personal seems to have only 20 concurrent users - is it too costly scaling if I decide for extending to web and android platforms?
- What is the general workflow involved in publishing to iOS, Android, PC, and web platforms while using Unity? I mean to ask about various points of signing stuff, paying fees and getting certified.
- How long will it really take to port my entire Objective C project into Unity? I am somewhat familiar with C# but I am finding it hard fidgeting with Unity IDE as lot of things are focused around FPS and 3D while my game is still 2d - not much action involved. I seem bit overwhelmed by the list of features I see there. All in all, I do not want to lose my momentum while still making sure its portable to everywhere.
- Any assets I could use (for free to try basis in debug) that are relevant for my game?
- Last but not the least, are there any costs that I need to be paying upfront to Unity, for using it (apart from their monthly subscription model)? I don't understand their costing for multiplayer in conjunction with their subscription fees - if someone could kindly elaborate.
Thanks in advance for your time reading a newbie

Hello,
me and few friends are developing simple city building game with unity for a school project, think something like Banished but much simpler. I was tasked to create the path-finding for the game so I mostly followed this tutorial series up to episode 5. Then we created simple working system for cutting trees. The problem is that the path-finding is working like 90% of the time, then it get stuck randomly then there's clearly a way to the objective (tree). I tried looking for some pattern when it happens but can't find anything. So basically I need any tips for how I should approach this problem.
Use this image to visualize the problem.

Share this post

Link to post

Share on other sites

Screen captures are big, and reading from the screen's display takes time.

First, the size. A single screen capture image may be 1920x1280x24 = [Edit: Bath math originally, sorry] 7 MB uncompressed [end edit] . Or 2560x1600x24, or 2880x1800x24, or even more. You can spend compute power to compress it if you want. Multiply that by 50 or 60 or 75 or 120 frames per second.

Second, the speed. Graphics APIs are normally built as write-only systems. You write to the card, then discard the results and write the next frame. The card dumps the image to the display and you don't need to. Reading back from the graphics card is a moderately slow operation. A naive approach can take over a second per frame to read. Driver-assisted approaches can help give you faster results for recording rendered frames, but they will still consume a lot of time as data transfers across your hardware bus.

It is generally faster and easier to just record the source data stream.

Edited December 15, 2015 by frobSorry for some bad math.

8

Share this post

Link to post

Share on other sites

The first option also lets you play the replays at different angles or with a spectator camera, with additional overlay information that may not have been available during the original gameplay, etc. It's waaaaay more flexible. Even if you're immediately replaying gameplay that happened just seconds ago, the ability to replay it at a different angle or with different post-processing effects or different UI cues or the like is massively useful.

Replaying is a matter of feeding the input from the saved values instead of the player's keyboard/network/etc.

If you start with this method from ground up, it's very easy to implement. Otherwise it's a PITA if the engine is halfway through (main trouble is guaranteeing determinism and ensuring all sources of undeterminism are isolated).

The best of this feature is that it's useful not just for replaying, but also for debugging. Got a crash? Catch the crash, save all the input and close the app. Now reply the saved session with a debugger hooked. Also if you have a race condition or an uninitialized variable, it will be spotted almost immediately. Very hard to miss.

The disadvantage is that if you update your application, the saved sessions become useless (since it needs to be played on exactly the version it was recorded with). For Unity's, you also have to add that updates to the C#'s .Net runtimes may affect the determinism (unless you embed Mono dlls with the app?), and due to the JIT nature of C#; it probably won't replay correctly on another machine.

Thats still something but 58MB seemed a little much for a single screen picture, even uncompressed.

You're correct. The numbers were wrong. However, the actual problem is that at 60 fps that amounts to 60 x 5.93MB = 355MB/s.
You would need an SSD to record it, since no current user-grade HDD can keep up with that write bandwidth.
You would have to compress it. H264 live encoding is possible, but you would have to use the zerolatency quality profile for fastest speed, and deal with H264 licencing and patents. (and also high CPU usage)

A more reasonable approach is using YCoCg at 30fps and later reconvert to your favourite compression scheme to lower CPU usage, and workaround the H264 licensing/patent issues.

Share this post

Link to post

Share on other sites

I created a replay system that, every update frame, simply recorded the locations of all the graphical objects in the game screen as well as when sounds were played and saved it to a file. This is much simpler than recording inputs and trying to make it deterministic, and it's much smaller than taking a screenshot every frame. You can still do the replays form different angles as Sean was mentioned as well.

It worked great for a game I made years ago, I don't know why it won't work for you.