Hayat / Life

Voxxed Days Belgrade 2016

noreply@blogger.com (Hakan Saglam) — Wed, 26 Oct 2016 10:52:00 +0000

Finally I have presented (almost) all my works. It was a great pleasure to be part of Voxxed Days Belgrade 2016. Search #vdb16 in twitter and instagram to see what happened there.

We went there 4 colleagues from Peak Games

It was started with arrival of our flight. Dimitri was waiting for us, he is one of the actual organisers. He is so nice and funny guy, we had great times with him during the event. And actually he has been to Turkiye multiple times, and seen some of uncommon places for a tourist like Diyarbakir, Nemrut Mountain etc...

We had one day off before the event to have some sightseeing and to taste some traditional Serbian cuisine. I think one or two days are quite enough to know the Belgrade. Of course it is based on our performance on the first day. Thanks to Selim, we have done 30K steps in total. And went almost every location by walk. Then we learnt that there is 5 days bus ticket (for 1040 Dinars around 10 Euros), use that ticket and public busses for the rest of the days.

By the way, in general foods and drinks (with alcohol or not) is very very cheap, and the taste is quite similar to Turkish style. I strongly suggest to make a trip to Belgrade, especially if you consider that we (Turkish citizens) don't need visa for Serbia.

Let's come to the event. The opening with the music of Tesla Coil and a very big Gong was fantastic. And also keynote was very successful by Scott. Organisation was flawless. Overall talks were fine I guess, and sponsors prepared some great games, presents and stands. So overall it was a fantastic event. I have tried to attend as much talks as I can in the first day. For the first night, we went to Historical Museum of Serbia as speakers. Which was also very inspiring, I strongly suggest for the ones who visits Belgrade.

Second day my mind was full of my talk, so I have spend most of the time in the speakers room to get prepared on my talk. I could attend only some of the talks, but of course I didn't miss any of these delicious food :) Second night we went to Nikola Tesla Museum as speakers. It was nice, but not like the Historical Museum. If you have one choice between these two museums I would suggest the former one.

After museum, I spent all night to get prepared for my talk. So finally the time had came and I did it. Here it is my talk, I didn't watch yet but I think I am happy with the result. It could have been better of course. But I think, I am getting better with every new presentation/talk :)

So as you might know, the talk was about Unity in general, specifically about these topics. You can find all the subjects and more here inside of this blog:

And this is my presentation stack, please take a look and leave your questions/comments.

Finally, I admit that it was not a big deal, but still it was not that easy for me. Especially from the language point of view, it is quite challenging to have a talk in a non-native language. So as a result I am happy about what I have done. I want to thank to my colleagues at Peak Games and also to my wife and my little ones Sarp and Atlas for their supports.

Please feel free to contact me about anything you wonder. Hope to be around with this blog couple of times in a month. Let's see...

Unity Services

noreply@blogger.com (Hakan Saglam) — Fri, 23 Sep 2016 08:40:00 +0000

This is the last post about Unity3D, if you wonder what I have said before, please take a look:

1. Why do we move to Unity3D?

2. Power of Unity3D Editor

3. Coding in Unity3D

4. Testing in Unity3D

5. Debugging in Unity3D
6. Performance Optimization in Unity3D
7. Continuous Integration and Delivery with Unity3D

With this last post I planning to explain Unity Services and Tools. Unity provides a range of services to help developers make games and engage, retain and monetize audiences. Unity Ads, Unity Analytics, Unity Cloud Build and Unity Multiplayer are fully integrated with the Unity Editor to make creating and managing games as smooth, simple and rewarding an experience as possible.

Unity Ads is Unity's video ads tool. It is designed to become a natural part of the game that actually enhances the players’ experience. We are already using Unity Ads to monetize some of our native games with rewarded video ads. But we didn't experience any Unity game yet. It is not that difficult to integrate on native platforms, I guess it will be much more easier on Unity games here it is the documentation.

Whether you offer your gamers a chance to earn more currency, extra life, or double their score in exchange for watching a short video, the power is in their hands. Your players can choose to watch the ad at the right place and time in their game experience - putting more money in your pocket over the gamer’s lifetime with the highest ARPU of any global rewarded video ad network.

Unity Analytics gives you an easy access to important information that helps you improve your in-game economy and the player experience. It has a dashboard to visualize your game data. In this data you will have high-level overview of how your game is being used. Players' progress (and where they get stuck). Address different audiences by creating player groups and segments based on unique game scenarios and behavioral patterns. We are not using Unity Analytics because we have our own custom analytics solution.

Another thing is, you can enable in-app purchases across multiple stores (iOS, Mac, Google Play, Windows and Amazon App Stores) with single API called Unity IAP. And it enables you to monitor and act on trends in your revenue and purchase data across multiple platforms. Learn how to set up Unity IAP for multiple stores. We are not using Unity IAP also. Because we have our existing custom native solutions optimized and working specific to our needs. We just created native plugin for these solutions and started to use in our Unity games.

One last thing is Unity Heatmaps. It provides a visualization of spatial events that occur in your game. Where do players clicks? Where do they scores? Which roads are most travelled in your game? By collecting the data from hundreds or even thousands of plays, you begin to assemble a large-scale picture of how your players experience your game. The patterns that emerge can help you tune your game. So you can improve your game economy, reduce the gameplay difficulty curve and increase the level of player enjoyment. This is something that we are planning to use sometime in the future, but right now we didn't try it.

Unity Cloud Build helps you to automate your pipeline of compile, build, deploy and test. Simultaneously build for multiple platforms and app stores. And also distribute and share your builds that your team can easily download and install from anywhere. So it is yet another continuous integration and delivery tool specific to unity games by Unity. Since we have our own CI solution, we are not using this one either. Actually there is also other issues like being queued among all Unity Cloud Build customers.

Unity Collaborate is there for small teams to save, share, and sync their Unity project. It’s cloud hosted and easy to use so the entire team can contribute to the Project, regardless of location or role. Your project is cloud hosted so you’re always up to date with your team, no matter where you are. You can invite collaborators right in editor and start working together. It can be used by the entire team artists, QA, everyone (15 members max). It is in beta right now, and requires 5.4+ version of Unity3D. It is something we are planning to use (after beta) because right now it is impossible to work together on the same scene or prefab concurrently. I hope it will resolve these issues.

Everyplay is a SDK for recording game play of user. Recording is done in the background with virtually no impact on performance for users. According to Unity, players love replays. A user that watches game video typically plays more often and plays for longer than the average user. And it helps to market your game as your players share your game's replays, their friends will try it out too. We are not using it, and I am not sure if we even think it in the future. Once we tried built-in iOS Game Recording mechanism but it didn't work for our game genre.

The purpose of Unity Multiplayer is to create real time, networked games for Unity. It’s fast to implement and highly customizable. Unity-provided servers ensure that your players can find and play with each other. It can be used from turn based games to real time fast action games. Unity Matchmaker Servers makes it easy to connect your players. Unity Relay Servers brokers network traffic to ensure quality sessions between your players no matter where they are. See more on this documentation. We are not using this service also, because we have our own dedicated, robust, highly scalable and performant servers (some of our games have more than 100K concurrent users). And they are not generalized servers, they have been developed and being maintained specific to our games. We are not planning to use this in our board games, may be we can think some experimental games in the future.

Unity Performance Reporting automatically collects application errors, across devices and platforms, so you can find and address issues in real time. It consolidates errors across platforms, devices, and builds. Automatically collects and views errors as they are generated by app users. And best part is it requires no sdk. We are not using this one either. We are using Fabric/Crashlytics for tracking our crash reports. Actually we are very happy with it on native games. But on Unity games it is not as good as the others. We didn't discuss or investigate yet, but if Unity's solution is better than Fabric, we can think to move this one.

Unity Asset Store is home to a growing library of free and commercial assets created both by Unity Technologies and also members of the community. A wide variety of assets is available, covering everything from textures, models and animations to whole project examples, tutorials and Editor extensions. The assets are accessed from a simple interface built into the Unity Editor and are downloaded and imported directly into your project. Unity users can become publishers on Asset Store, and sell content they have created. To find out more, see Asset Store Publishing.

We are definitely using Asset Store actively (as a customer, not as a publisher yet). We have downloaded both free and paid assets. We are using some of them directly in our games and some of them to just investigate or to get inspired.

Here it is some of the assets that we are using directly (or in-directly):

DOTween is a fast, efficient, fully type-safe object-oriented animation engine, optimized for C#.
UniWebView is an easy solution for integrating WebView to your mobile games. You can set up a web view and embed web content in your game.
Log Viewer helps you to check your editor console logs inside the game itself even on mobile.
JSON .NET brings the power of Json and Bson serialization to Unity with support for 4.7.2 and up and is compatible with both .NET and IL2CPP backends.
TextMesh Pro is the ultimate text solution for Unity. It's the perfect replacement for Unity's New UI Text & Text Mesh.
Best HTTP is a plugin that supports request customization for REST, WebSocket, Socket.IO, SignalR, Server-Sent Events (and much more) out of the box.
Console Enhanced is a vastly improved editor console for Unity.
Realistic Effects Pack The package includes effects with particle systems, uv-animated textures and distortion for mobile. Dimensions are approximate to reality.
Enhanced Scroller virtualizes your data, showing only the elements it needs to. Take thousands of rows and display them in a handful of UI elements, speeding up processing and saving memory.
Stats Monitor is a customizable FPS counter and performance measuring tool.

Unity Labs is Unity's experimental projects, research, and explorations into the future of game design, VR, AR and development. Some of the current services started inside the Unity Labs like Heatmaps. Most probably you will not find anything that you can use directly in your game. But it can inspire you or helps you create new ideas. And articles gives you some deep knowledge of Unity Ecosystem.

There are very useful Open Source Libraries / Projects / Demos by Unity. As you might know Unity Game Engine is not open source. It can only be accessible for certain enterprise deals. But some important parts apart from game engine is open sourced in the account of Unity Technologies on bitbucket. It is always good to keep an eye on these projects to have better understanding of how Unity is working under the hood. And also it can give you some insights about the development style and practices of Unity Team.

Some of the very commonly used open sourced libraries by Unity:

Entire Unity UI system is open sourced.
Heatmaps that I have mentioned above is open sourced.
Memory Profiler that I have mentioned before is open sourced.
Unity Test Tools that our testing approaches based on is open sourced.
XcodeAPI is for the post process that we are using to configure intermediate Xcode project is open sourced.

Unity collects very useful statistics about the specs of mobile devices running Unity games. They share these stats on Unity Hardware Stats page. I strongly recommend to check this page frequently, it can show the characteristic of devices based on different dimensions and also platforms. The hardware data comes from users who installed some sort of Unity game, so it represents combined statistics of all Unity game players. Please be aware that, your particular game might be targeted at different type of users with different hardware.

The End

So I have posted eight blog posts including this one. I have written more or less everything that I have planned in the beginning. Thanks for reading.

Now I will make a presentation from these posts to present on voxxed days belgrade. I don't promise but most probably I will tell you about the event and also share my slides here.

Continuous Integration and Delivery with Unity3D

noreply@blogger.com (Hakan Saglam) — Mon, 19 Sep 2016 12:16:00 +0000

This is the seventh post about Unity3D so far, if you wonder what I have said before, please take a look:

1. Why do we move to Unity3D?

2. Power of Unity3D Editor

3. Coding in Unity3D

4. Testing in Unity3D

5. Debugging in Unity3D
6. Performance Optimization in Unity3D

All jobs should be green

We are already using Jenkins as our Continuous Integration (CI) platform. CI is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

We are using Jenkins as CI platform at Peak Games including server side, CRM, mobile, web... So obviously we decided to use Jenkins for Unity projects also. We have seven Jenkins jobs for a single Unity game. Let me tell you about what these jobs are doing.

Common Gaming Libraries

Since we are planning to use Unity for at least 2-3 board/card games, we started creating common libraries that will be used by all Unity games. Before Unity, we have done similar work for iOS and Android native. That is why we have the knowledge to decide what functions would be common and re-usable across all games.

Right now we have 18 common libraries written in C# and 2 native plugins written in Java and Objective-C. To be able to integrate these libraries to actual game code we didn't use any dependency management framework, we just use two different custom approaches. When we are building these integrations we couldn't find a well known, mature enough dependency management framework that is why we created our own custom solutions.

For native plugins (Peak CRM API Client, Native IAP Client). We have created one project for each. Each of them has similar approach inside the project. Actually each project includes four separate projects inside. One for iOS in Objective-C, one for Android in Java, one for creating a dll in C#, one for reference sample Unity application. And of course one build script to build all native codes and create a dll file. Creating native plugins for iOS and Android is quite different, for more information please refer to these documentations (iOS and Android).

So we have two Jenkins jobs to create these plugins and generate available links to download. Once these plugins developed, they will not change a lot. So to integrate them, there is a manual operation. Actually just copy and paste after downloading from given URL.

For C# common libraries we have created one single Unity project called GamingLibrary. Unlike native plugins we don't want to create one or more dll files. Because these common libraries might change (with additions, changes, removals) a lot during the game development. We want to see the actual code of these libraries while we are developing.

So we tried to generate Unity Package from this project and import it into actual game project. It was working like a charm in Editor. You could import any package even your code has some compile issues. It would not compile because there were dependencies to our gaming lib package. But after the import it will compile and work successfully.

We were happy till to see that importing in batch mode (via command line) has a very subtle difference according to Editor. In batch mode, Unity needs to compile the project to be able to import any package before the import action. Which would not work for us because as I said our game code is not compiling before the gaming lib package import. We try to find a work around for this, but couldn't find.

Then we write a script file to copy gaming libraries into actual game code base. Basically we just use rsync to make synchronization. So we have one Jenkins job to compile and run unit tests on each commit to gaming library.

Game Code Base

So the rest of four Jenkins jobs are there for each Unity game. I will use Gin Rummy Plus as an example.

First one is there for actual CI purposes, it is compiling and running unit tests for each commit to main branch. Before compiling, it is using the above script file to integrate gaming libraries into code base and then using Unity's batch mode mechanism to compile it. For Gin Rummy Plus it has been 2187 run so far and it takes 40 seconds one individual run.

Second one is for running integration tests, it is working twice a day and manually when required. I have already mentioned about integration tests in more detail. And for Gin Rummy Plus it has been 462 run so far and it takes 18 minutes one individual run.

Third and forth ones are there for creating binary files for iOS and Android. Actually each of them is creating two binaries one is to send HockeyApp for testing purposes, one is to send App Stores for publishing. The jobs are not just creating binaries but also sending them to HockeyApp and App Stores. These binaries have some differences, for instance the ones for HockeyApp includes some extra debug features like cheat buttons to be able to test some scenarios, or some extra information to be able to understand a/b test groups for instance.

We are running these jobs manually, when we think that a new version of the game needs to be published. After job uploads the binaries it is informing our product managers and testers automatically. After that it is up to them to publish the binary or open tickets about the issues they have discovered in this version.

To differentiate the builds inside the code base we are using Scripting Define Symbols. I mean custom compilation flags (see Unity's platform dependent compilation page for details). We have two extra flags (DEBUG and ADHOC) a long with build-in PRODUCTION flag. DEBUG is there for development purposes it has more logs, more extra functions. ADHOC is there for testing purposes, and PRODUCTION is for stores.

Let me give more details about these binary build jobs.

Binary Builds

For iOS, when you build a Unity project it creates an intermediate Xcode project, from that project you can create the actual binary ipa file (you have to run it on MacOS system). And this job is doing it twice in a single run, to create two binaries as I mentioned above. That is why iOS jobs is taking 17 minutes on average.

After creation of intermediate Xcode project, most of the cases you have to make configuration on this intermediate project to be able configure some native iOS settings like compile flags, like info.plist updates, like url schemes updates. So we are using Unity's post process build attribute frequently to make this custom configuration programatically.

To create the binary from the Xcode project, and upload to HockeyApp and App Store (TestFlight) we are using our custom iOS Build Library which is already being used for our native iOS games. I will not give any details of native builds and all confusing provisioning profile configurations. That is another post's topic.

The last binary that we have sent to App Store is 56 MB. It is almost two times bigger than our native iOS games. It is mainly because of splash screen. Yes, you read it correctly, just because of splash screen your binary is increased at least 10 MB. I hope there will be a solution in the next versions of Unity.

For Android, it is much more easier process. Because Unity can create binary apk file without creating an intermediate project. So it takes way too quick to create two binaries according to iOS build. It takes around 7 minutes to create two binaries and upload one to HockeyApp and other to Play Store. We are using Jenkins plugins to make these uploads.

Unlike iOS builds, to make the native configurations we don't need to use post process build attribute. We just use the Manifest files to make the configurations.

The last binary that we have sent Play Store is 36 MB. It is also higher than our native Android games, but not like iOS. It is just 5-6 MB bigger. I can give more information about how to decrease the size of binaries on iOS and Android in another post (may be).

So as a conclusion our CI system for Unity games is consist of Jenkins, Unity's command line tools and a little bit of shell scripting, that is all.

We are very close to end of this Unity3D series, just one more :)

Performance Optimization in Unity3D for Mobile Games

noreply@blogger.com (Hakan Saglam) — Sun, 18 Sep 2016 13:44:00 +0000

This is the sixth post on Unity3D so far, if you wonder what I have said before, please take a look:

1. Why do we move to Unity3D?

2. Power of Unity3D Editor

3. Coding in Unity3D

4. Testing in Unity3D

5. Debugging in Unity3D

Performance is important. Nobody argues with that, it is important on every software projects backend, web, mobile it doesn't matter. Whatever technology it is, whomever using it, everyone wants that product to be fast, smooth and responsive.

In casual games, may be it is a little bit more important. Since it is casual game, it should open very quickly because you just want to play the game for 5 minutes, you should not wait for minutes to open. And more importantly it should work on any kind of device not just high end devices, because you don't expect anyone to have that device only for game purposes.

When you consider all of these, performance is not something you should leave behind. You have to consider it in the very beginning of the project and also keep in mind while you are developing any feature.

With Unity it is harder I guess. Because it is a black box engine that support multiple devices from mobile ones to game consoles. It is easy to create a game project and develop a playable version. But it is really hard to polish it in means of performance. It has a lot of adjustment points, some of them makes console games much better, but makes mobile game suffer. So it is important to have good knowledge and experience on Unity to optimise your game.

There is a talk in Unite 2016 Europe about Optimizing Mobile Applications, I strongly advice this talk.

The main things you'll want to consider are the size of your game, how much memory your game uses, and how much computing power your game needs. When targeting mobile devices, remember that a large portion of the market has phones that are a few years old. To reach the widest possible audience, you should optimize your game for low-spec devices. Unity releases very useful statistics about the specs of mobile devices running Unity games.

I will mention three practical points about what we have done in our card games to improve performance.

Sprite Sheets

In computer graphics, a sprite is a two-dimensional bitmap that is integrated into a scene. To render / draw that sprite into scene, game engine has to issue a draw call to the GPU. All the purpose is reduce Draw Calls and increase Total Batched Calls. A draw call is one pass from a GPU. The goal is that we want to have everything batched because batching is what happens when we actually talk to the GPU, so the more draw calls we have batched into a single pass means that the performance will be better inside of the rendering of our game.

To see how these objects rendered into screen we are using Frame Debugger. And it shows that how sprites rendered in which order. When you look at the gif image in the left, you can see some sprites rendered only single call, some are rendered together with other sprites, which means they rendered in batch. No matter how many sprites exists while they are in batch it is count one draw call means one call to GPU. To be able to batch all sprites we are using sprite sheets to load every sprite into one big atlas file and load to GPU and increase the Bathced Calls and reduce the Draw Calls.

A sprite sheet (atlas file) is a bitmap image file that contains several smaller graphics in a tiled grid arrangement. By compiling several graphics into a single file, you enable Animate and other applications to use the graphics while only needing to load a single file. Unity has built-in Sprite Packer to create sprite sheets from your sprites. We are using TexturePacker which is a better packer according to Unity's built-in one.

One other key point is the scene hierarchy. Unfortunately it is also impacting the draw calls count especially if you have multiple sprite sheets. Let's say you have two sprite sheets and you need to render some sprites from one, and some from other in the same scene. Try to organize your hierarchy to gather all your sprites that comes from same sprite sheet, so that they will be rendered in batch with one draw call. And then put others that comes from second sprite sheet.

Unity Profiler

In the editor there are two types of profile tools.

One is called Stats Window. While your game is running, click on the Stats button at the top right of the game window to open the Stats window. Here you can see some basic stats about your game. At the top is your frames per second, which is not that useful since it will be different when running on a mobile device. But things like the number of draw calls, triangles, and textures should be consistent with what you'll get on mobile. The more draw calls and triangles you have, the more processing power your game will require to render your scene. There's no hard and fast rule as to many draw calls you should have, since it depends a lot on what shaders you use. Under 50 draw calls should run quickly on most devices although newer devices and tablets can handle more. If your game is running slowly, and you see that you have hundreds or thousands draw calls, that's probably one of the reasons.

The number of textures being used is another good metric to consider. If you're loading and unloading textures at run time, like we did when switching atlases, the number of textures in the stat window will let you check if they are being de-allocated properly or if they're still in memory. You can also see how much memory is being used by textures at any given time.

Staying under 30% of the available memory on the device is a good idea. But remember that there are other things in the scene that also use memory, besides the textures. Even without the pro version of Unity, you can get some useful information about the performance and memory usage of your game using the Stats window.

Second one is Profiler Window. The Unity Profiler Window helps you to optimize your game. It reports for you how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating or in your game logic. You can play your game in the Editor with Profiling on, and it will record performance data. The Profiler window then displays the data in a timeline, so you can see the frames or areas that spike (take more time) than others. By clicking anywhere in the timeline, the bottom section of the Profiler window will display detailed information for the selected frame. Let me tell you what you can measure with profiler. Before moving that part, you already might know that profilers also add some overhead on the performance. So when using profiling it is typical to consider only the ratio (or percentage) of time spent in certain areas.

The CPU Usage Profiler displays where time is spent in your game. When it is selected, the lower pane displays hierarchical time data for the selected frame. See documentation on the Profiler Window to learn more about the information on the Profiler timeline.

The Rendering Profiler displays rendering statistics. The timeline displays the number of Batches, SetPass Calls, Triangles and Vertices rendered. The lower pane displays more rendering statistics, which closely match the ones shown in the Stats Window.

The Memory Profiler shows a simple overview how memory is used throughout Unity in real-time on a per-frame basis. And also allows you take a snapshot of the current state. After taking a sample, the Profiler window is updated with a tree view where you can explore memory usage.

The Audio Profiler monitors significant performance meters about the audio system, such as total load and voice counts. When you highlight the pane, the lower part of the window changes into a detailed view about various parts of the audio system not covered by the graphs.

The Physics Profiler shows the following statistics like the numbers of Active and Sleeping Rigidbodies, Static and Dynamic Colliders.

The GPU Profiler is similar to the CPU Profiler, with various contributions to rendering time shown as a hierarchy in the lower panel. Select an item from the hierarchy to see a break-down of contributions in the right-hand panel.

For more information about Unity Profiler please refer to official Unity documentation.

One last thing is there is a new very low level memory profiler API. It can tell you which objects got blamed for how much c++ memory allocations. It will also give you a dump of the entire c# heap, as well as c# type descriptions. This API is too low level for most people to benefit from. The intention is to write a much nicer UI window on the top of this API that will actually be readily useful for many users, in helping them figure out which objects are loaded, which objects take a lot of memory, and most important, why that object is in memory. This repository is that nicer UI window, very much in progress of being built. Actually it is an open source project by Unity.

Xcode Instruments

There is an official Unity post about how to use Xcode as profiler. Officially Unity team also suggesting to use Xcode Instruments. Even if you don't have any performance problem, still it would give you a lot of details about how Unity is working under the hood. Because profiler will not just profile and show your code, but also internal codes of Unity.

Xcode Instruments can see the things that Unity Profiler can't see such as application startup time. In the Time Profiler you can see what makes your app waits while showing splash screen. Most of the time spent in the internal Unity codes, but there are two points that your code impacts this time.

If you look at the image you will see PlayerLoadGlobalManagers which is responsible to index your Resources. So if you have too many items in this folder it will directly impact your apps startup time. In the beginning we were putting all our resources into this folder even it is not needed to load it dynamically. After learning this fact, we just leave only the dynamic images in the folder and gain around 5.4% startup time decrease.

Second item is the Awake functions of game object attached in the first scene (consider that we have only one scene). All Awake functions will be called during the splash screen. We have calculated that 19.2% of startup time is because of these functions. When we investigate deeply we understand that almost all of this time is being spent while calculated dependency graph by StrangeIoC. We didn't do anything to reduce this time yet.

On the other hand while running game, you can profile the update loop of UnityEngine. And you can see the internal code on each frame as well as your code executed on Update, FixedUpdate and LateUpdate functions. And again your code executed on DelayedCallManager which is there for your Coroutines. And you may also see some extra time on CanvasManager which is responsible for all Unity's UI system like calculations of text sizes and rendering of texts etc..

Another very handy instruments of Xcode is Memory Leaks, Xcode will show you the memory leaks of your code (sometimes it is internal code), but sometimes it gives you a good idea to handle or get rid of this leak.

Actually other than memory leaks, you might still have memory issues. Especially the most common one is Memory Fragmentation. Unity has automatic memory management which is cool. But if your game creates a lot of temporary object while executing your code, this automatic memory allocations by Unity will end up memory fragmentation. Don't forget in Unity, the heap only expands, never shrinks. So it is very very important to avoid temporary objects. To avoid them you have to know when they are created by Unity. Here it is the most commonly used ones:

Use simple for loops instead of foreach loops. The reason is that a foreach loop internally creates a new enumerator instance.
Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type.
String Concatenation also creates temporary string objects, instead String Builder can be used.
All Unity APIs that return arrays (CreateScriptingArray) will allocate new copies of arrays. Minimize calls to these methods.
Linq usage will create extreme amount of temporary objects so examine the time lost to creating and discarding Linq queries; consider replacing hotspots with manually optimized methods.

So I think this is all I want to mention about optimizing the mobile Unity game. Actually I was planning write a few lines about optimizing the size of the binaries (on iOS and Android) but I guess it is part of another topic let's see.

I am almost done with this Unity related blog posts. A few of them left. Just hang in there :)

Debugging in Unity3D

noreply@blogger.com (Hakan Saglam) — Fri, 16 Sep 2016 12:38:00 +0000

Now it is time to Debug

It has been four posts so far.

1. Why do we move to Unity3D?
2. Power of Unity3D Editor
3. Coding in Unity3D
4. Testing in Unity3D

Another important topic is debugging, which is an essential point in software engineering. As a developer we read codes, even more than we write code. While reading the code, having good debugging skills and tools is quite important. It makes your life much easier. With Unity you have different kinds of debugging tools as well as very basic debugging approaches.

MonoDevelop

I have already write about Mono Develop, the default IDE of Unity. It has built-in debugger, which is integrated with Unity. So you can attach to Unity process inside the IDE, and put a breakpoint in the code base and run the editor. You will see that it will stop on the selected line, and you will have the usual actions like pause, continue, run step by step, step inside etc... And also you can see the usual information like stack trace, value of local and global variables etc...

It sounds like a proper debugger, right?

Yes in theory, it is a proper debugger which has almost every expected feature from a regular debugger.

But unfortunately in practice it is not like that. It is almost certain that it will crash either Unity or MonoDevelop in each one of two debug try. So it is literally useless, unless you want to live some kind of excitement and believe me it is not that pleasant to restart Unity (or MonoDevelop) in the middle of coding.

So the old way is the best way. Plain old regular logging. That is it. Put Debug.Log() in every corner of the code base and learn how it is running. And find what you are looking for. Yes it is not that fancy but it is some how enough, and it is the only way of debugging your scripts. So I suggest you to get used to it.

Editor Debugging

In one of previous posts, I have mentioned about Unity Editor. Here it is another very handy feature. Unity will actually let you change the value of a script’s variables on inspector window while the game is running. This is very useful for seeing the effects of changes directly without having to stop and restart. When gameplay ends, the values of the variables will be reset to whatever they were before you pressed Play. This ensures that you are free to tweak your object’s settings without fear of doing any permanent damage.

When you pause the game you can see all your game objects' properties and states. It is a kind of debugger right, even it has step by step option :) actually it is a little different of course. Each step is not a new line in your code, each step is the next frame. That is why it is called "frame by frame" :)

You can see the scene and also all the state of the scene when you pause the game or when you go frame by frame. Actually there is even better option that you can change everything in the scene. Enable / Disable game objects, change their location or scale or color. What ever you change, you will see the change instantly. Then when you hit play again it will resume with this new states. Actually you can do this without pausing the game at all.

This is very powerful feature that you can leverage to debug the scene and game objects, and also you can use this feature to tweak some fine adjustment on the scene like 1 pixel left, 1 pixel right :)

To make it clear, let me give you an example from our games. As you already know we have a card game Gin Rummy Plus. According to rules of this card game you can finish the round when all your cards sorted for certain rules. And to finish the round you have to throw one last card to pile. And it should not be same as throwing a regular card, it should be more impressive and it should give the feeling that you won the round.

To be able to give that feeling we should have try different options. We have created three different bezier path. One for player's last card throw, one for opponent's last card throw and one for regular card throw. And instead of hard coding these bezier paths, we just use editor window to tweak and find the best way of these throw paths.

And one more tip is you can also pause the game programatically. Just type Debug.Break() in your code and stop the world according to a condition. And you don't need to worry about it later, because it will do nothing in production. It has one more significant advantage over manual pausing and stepping forward. It can pause your game in the middle of an execution frame. This means that part of your object may be still waiting for the Update() call and the other part has already been updated. This is really useful for situations when you’re dealing with a bug that appears randomly.

Frame Debugger

The Frame Debugger lets you freeze playback for a running game on a particular frame and view the individual draw calls that are used to render that frame. As well as listing the drawcalls, the debugger also lets you step through them one-by-one so you can see in great detail how the Scene is constructed from its graphical elements.

The Frame Debugger window shows the drawcall information and lets you control the “playback” of the frame under construction. The main list shows the sequence of drawcalls in the form of a hierarchy that identifies where they originated from. The panel to the right of the list gives further information about the drawcall such as the geometry details and the shader used for rendering.

Clicking on an item from the list will show the Scene (in the Game view) as it appears up to and including that drawcall. The left and right arrow buttons in the toolbar move forward and backward in the list by a single step and you can also use the arrow keys to the same effect. Additionally, the slider at the top of the window lets you “scrub” rapidly through the drawcalls to locate an item of interest quickly. Where a drawcall corresponds to the geometry of a GameObject, that object will be highlighted in the main Hierarchy panel to assist identification.

To reduce the drawcalls, frame debugger is the key tool that we are using in our games. As you can see in the screenshots above, we still have some work to do. Our game's lobby screen has 55 drawcalls which is not a problem mid and high end devices, but might be a problem for some low end devices. That is why our target is to reduce it to at least less then 50 drawcalls.

Debug on Device

In general you will not need to make a lot of debugging on devices. According to our experience with Unity, most of the time you will see actual device behaviour inside the editor. And most of the time it is not changing according to device type. But for some rare cases and also for some native calls you might need to debug on device.

Debugging on device is more difficult and primitive. In theory you can have breakpoints in the code especially on iOS environment, but you cannot see the actual code, because it will be converted to native binary files. That means it is not useful at all. So only option is to put logs in your code and tail this logs to see how your code is behaving. Adding logs is not different than the one that I have already mentioned. But to see that log while running on device is a little different.

To see the logs while playing game on device you are going to have different ways on iOS and Android.

First iOS. Before everything make sure that you are on a MacOS system, and Xcode has been successfully installed.

The iOS application build process is a two step process. When you build the Unity iOS game an Xcode project is generated. It is generated with all the required libraries, precompiled .NET code and serialized assets. This project is required to sign, compile and prepare your game for distribution and/or run on the actual device.

When you first run the game on device via Xcode project you are going to notice that it will take minutes to start running. After that you will see the logs in the console view of Xcode. Unfortunately it takes ages to see the logs on device.

One tip, if you want to see the logs on an iOS device without running the application via Xcode. Choose Window -> Devices from the Xcode menu. Then choose the device in the left column. Click the up-triangle at the bottom left of the right hand panel to show the device console.

Another tip, use incremental build when you build iOS app from Unity to quicken to run on Xcode. The C++ code generated by the IL2CPP scripting backend can be updated incrementally, allowing incremental C++ build systems to compile only the changes source files. This can significantly lower iteration times with the IL2CPP scripting backend. To use incremental builds, choose the “Append” option after selecting “Build” from the “Build Settings” dialog. The “Replace” option will perform a clean build.

Second Android. Before everything make sure that Android SDK has been successfully installed. And integrated with Unity.

You can build an Android application and install it to device is just one step. And it is much more faster according to iOS build. After installing and running the app on device you just need to open command line tool and type "adb logcat -s Unity" you will see all the logs related with Unity and your game.

Thanks for reading :) please go on with this post if you wonder how to make performance optimization in Unity3d for mobile games.

Testing in Unity3D

noreply@blogger.com (Hakan Saglam) — Wed, 14 Sep 2016 10:11:00 +0000

We have chosen Unity for cross platform mobile game development,
we see how powerful Unity Editor is,
we learn how to attach scripts to our game scene,
now it is time to test our code and scene.

I am not talking about QA testing or user acceptance testing. I am talking about the tests that we as software engineers are responsible while development is on going. I am talking about automated tests. There are different kinds of automated tests like Unit Tests, Integration Tests, Functional Tests etc...

I will not discuss these concepts, their scope or why they are needed. Instead I will tell you what we are doing in our Unity games.

Unit Tests

Unity does not have build-in support for unit testing. But there is a package in Unity Asset Store called Unity Test Tools created by Unity itself. Actually it is an open source project that you can also contribute. If you integrate that tools into your project, you would have the ability to write unit tests in your project. These tools are based on NUnit library, a well-known unit testing library for .Net languages. More information about NUnit can be found on http://www.nunit.org/.

Your unit tests should be placed under Editor folder (it is a special folder in Unity projects). The runner will scan the assemblies (including external assemblies included in the project that reference nunit.framework library) and generate a list with tests that were located. The tests are executed in the editor, in non-play mode, all in one frame. It is not possible to skip a frame and/or execute an API that requires skipping frames.

The code you execute via the test runner will directly affect your currently opened scene. For example, if you instantiate a GameObject, it will be persisted on the scene. Most of the times such behaviour is undesired. Unity prevents to have unit tests on attached scripts (MonoBehaviour scripts). That is why having a Dependency Injection (DI) or Inversion of Control (IoC) framework makes our code decoupled and testable. Having clear separation on game logic and game scene (views) is helping us a lot to have enough test coverage. Our unit testing strategy is try to cover all game logic, and complex logic calculations, not the views and screens.

Integration Tests

Unit Tests are there to check your individual units are working correctly. But you still have to test if these individually tested units can work together. Unfortunately you can not just test your custom units together, you have to involve internal UnityEngine functions. So we are using Integration Test Framework inside the Unity Test Tools.

The Integration Tests are designed to run on a separate scene. You can consider the scene where you place your tests as a test suite. One test scene can contain multiple tests. Unity suggests not to put your tests on your production scenes. Instead, create a separate scene for them.

There are two ways of creating integration tests. Manually by creating a test scene and adding some assertion script on this scene. Or dynamically (from code) by marking a MonoBehaviour with an attribute that make it loaded by the test runner. For more information please refer to official documentation.

We are using dynamic approach to be able to create our integration tests programatically. Because we don't want to create a separate scene for testing purposes. It is very important to be able to test actual production scene with actual user behaviours. We just want to simulate a user playing the game and make assertions while the real play is ongoing in the real game scene.

Although this framework is not designed to use actual game scene, we could manage to make it happen. And we could manage to simulate user actions like button touches or card throws etc... It opens us whole new possibilities. And we gradually improve our integration test suite, here it is the evolution steps:

First we started to write integration test for critical user scenarios like login process, or playing a regular game play. In the beginning it was not easy to create one integration test.

So to be able to make it easier we started to create the integration tests based on log files. What I mean is, we just play the scenario in the editor and record every action and every package exchange between client and server in a log file. And give that log file to our integration tests to parse and simulate all the recorded actions and server messages. And we added other important scenarios like reconnect, or some edge cases on the game play.

Afterwards we wanted to create integration tests from real users' play records. We just improved our log system and adapt integration tests to parse the real user actions from log files. To be able to get the log files we attached them to user feedbacks and also crash reports. So that we could re-produce the real scenarios of real players. And add some of them to our integration test suite.

Instead of running this integration tests in the editor we started to use batch mode (unity command line tools) to be able integrate it to our continuous integration (CI) system (don't worry I will have one separate post about CI). And schedule it to run twice a day to inform us everything is good and working as expected with all changes.

Since these integration tests are real play scenarios, to run all of them took around 20 minutes on average. It might be fine for CI, because it is running automatically and informing us when it is finished. But it is not fine, if you want to run these tests in your local environment. It is not acceptable to wait 20 minutes while you are coding. So we tried to find a way. And end up using Time Manager feature of Unity. We just make the time scale 10 times faster, while running the integration tests, and decrease the total amount of time to 2 minutes. Which is fairly acceptable time for entire integration test suite.

Editor Tests

There is another test a developer should do after (or during) every development. Actually this is not an automated test. Yes, I am talking about manual testing. You should not just rely on automated tests especially during the development. You should absolutely, without any doubt, test what you are coding. I think we all agree on that.

Manual testing is testing what you are doing like you are the user of that feature. And sometimes you are developing something (implementing a feature or fixing a bug) deep inside the the game. Let's say your are developing the result popup that is presented at the end of a card game. And there isn't one single mode of that result popup. It can change according to game type (solo or regular), game result (win or lost) etc...

According to my experience you have to play the actual game and see the result for every main scenario especially after you are certain that development is finished. But during the development you should not always play the game, you have to find a better way. Because you are an engineer, you have to find a more practical way of testing.

The first thing that came to mind is, just write a temporary test code to create that popup with given result model. And try it over and over again. And change the model and run it again to see how it is behaving with this model. It is not a bad approach. You can see some commented code pieces just for testing purposes (most of the case they are out dated) in almost all software projects.

But with Unity Editor there is a better way. You can create a custom editor specific to your needs. By doing that you can test all cases with a single run, and also you don't need to change the real production code with temporary codes. So you don't need to comment out that test code, which means it will live with the project and always up to date. So it can be usable whenever you needed.

So these are the main testing practices that we are using during Unity game development. If you have any comments or additions do not hesitate to comment on this post. Because now I am moving to debugging in Unity.

Coding in Unity3D

noreply@blogger.com (Hakan Saglam) — Sun, 11 Sep 2016 08:06:00 +0000

Now it is time to write some real code :)

I have mentioned why do we move to Unity and how we use the power of Unity Editor so far. And in this section I will explain how to write code in Unity3D.

By default MonoDevelop is the integrated development environment (IDE) supplied with Unity. An IDE combines the familiar operation of a text editor with additional features for debugging and other project management tasks.

If you are using Unity on Windows, Visual Studio (with ReSharper) might be a better choice instead of MonoDevelop. If you are working on MacOS like me, then for now MonoDevelop is the best option. I have tried other simple editors like Sublime Text or Visual Studio Code but unfortunately just editor is not enough for long time development, you need a real IDE. I am looking forward to use Rider (A cross-platform C# IDE based on the IntelliJ platform and ReSharper) soon. It is still in beta. So for now MonoDevelop is the answer.

Me when I code

Coding part is called Scripting in Unity documentation. It is an essential part of a game, even the simplest game needs scripts to respond to input from the player and arrange for events in the gameplay to happen when they should. Beyond that, scripts can be used to create graphical effects, control the physical behaviour of objects or even implement a custom AI system for characters in the game.

I will mention a few key points of scripting in Unity.

Event Functions

Although Unity uses an implementation of the standard Mono runtime for scripting, it still has its own practices and techniques for accessing the Unity game engine from scripts.

A script in Unity is not like the traditional idea of a program where the code runs continuously in a loop until it completes its task. Instead, Unity passes control to a script intermittently by calling certain functions that are declared within it. Once a function has finished executing, control is passed back to Unity. These functions are known as event functions since they are activated by Unity in response to events that occur during gameplay. Unity uses a naming scheme to identify which function to call for a particular event. For example, the Update function (called before a frame update occurs) and the Start function (called just before the object’s first frame update). Many more event functions are available in Unity; the full list can be found in the script reference page.

Strange IoC

These scripts are special kind of code pieces to integrate your code with UnityEngine. That doesn't mean that all of your code should consist of these kind of scripts. You can have your own software architecture behind the scene and use these special script codes to connect to game objects in the game scene. Actually I strongly recommend to do so, by doing that you could have testable clean code apart from scripts.

We move a step further in our games and create our own architecture based on DI (Dependency Injection). I think I don't need to explain what is DI and why it is needed. It is one of the key patterns of software engineering. We are using StrangeIoC as our DI framework. StrangeIoC is a super-lightweight and highly extensible Inversion-of-Control framework, written specifically for C# and Unity.

Actually we are not using StrangeIoC just for DI, and also to have consistent, modular and clear software design in our code base. Main idea is decouple all our class dependencies and write cleaner, modular code with a highly optimized Reflection/Injection system. Additionally it helps us to have Signals-and-Slots style Signals dispatcher for type-safe communication. View mediation allows us to have clean separation of Views from Controllers and Models with no loss of capability. Strange's architecture is based on the popular Robotlegs micro-framework. This architecture is well founded, highly proven, and lightly urges responsible development that works great for individuals or teams.

Component Driven Architecture

There are plenty of discussion on what is Component Driven Architecture and how should be implemented. If you are coming strong background of OOP development like me you will need quite amount of time to adapt and fully leverage this concept. I know they are not opposite to each other, on the contrary they can be used together very smoothly. OOP is a way to build a logical hierarchy of classes, while components is a way of aggregating the different behaviour of an objects.

Unity is by design a component driven product. And it forces you to use it even if you are not comfortable with this concept. Every functionality (or behaviour in Unity jargon) that you will add to your game objects is already a component.

Let me give you an example from our games. We have quite amount of popups in our games. Not directly the board/main area of the game, but other parts like rooms, lobby, inbox, campaigns have a lot of popups, and the coordination of these popups is not an easy problem to solve. Sometimes you have to queue them and show them one by one, sometimes you need to show them immediately, sometimes you have to clear them, sometimes you have to convert them from popup to inbox message etc...

Instead of creating a popup class hierarchy, and having popup functions and fields in various types of classes. We choose to define popup functions as a set of behaviours. If a game object needs to have popup functions (in whole life cycle or for a certain period of time) it can attach and enable this component and can be treated as a popup by the rest of the code. Besides we define popup functions with an IPopup protocol to be able to give all the management to a manager object that will deal with different implementations of this interface.

Everything can be a popup

By doing that we can enrich popup definitions with different implementations (and believe me we are going to need various types of popups in our games) and also we make sure that any game object what ever it's original purpose is, can be treated and behave like a popup.

Coroutines

One important most used technic in Unity is coroutines. Let's go with an example; when you call a function, it runs to completion before returning. This effectively means that any action taking place in a function must happen within a single frame update; a function call can’t be used to contain a procedural animation or a sequence of events over time. As an example, consider the task of gradually reducing an object’s alpha (opacity) value until it becomes completely invisible.

As it stands, the Fade function will not have the effect you might expect. In order for the fading to be visible, the alpha must be reduced over a sequence of frames to show the intermediate values being rendered. However, the function will execute in its entirety within a single frame update. The intermediate values will never be seen and the object will disappear instantly.

It is possible to handle situations like this by adding code to the Update function that executes the fade on a frame-by-frame basis. However, it is often more convenient to use a coroutine for this kind of task.

A coroutine is like a function that has the ability to pause execution and return control to Unity but then to continue where it left off on the following frame. It is essentially a function declared with a return type of IEnumerator and with the yield return statement included somewhere in the body. The yield return line is the point at which execution will pause and be resumed the following frame.

Screen Management

One last topic I want to share is screen management. Unity has game scenes, and transition from one scene to other is not a trivial thing from performance point of view. It needs to load everything inside the scene and then show the scene and this takes a lot of time in most of the cases.

While loading the scene game freezes, there might be some Unity games without these scene loading glitches but as a producer or as a consumer I didn't see so far.

We do not want to face these glitches in our games. So decided use one giant scene. It has different drawbacks of course, but so far so good. We could manage to handle all the drawbacks and create a smooth screen transitions between the different sections of the game.

Board games like us does not need levels or very different atmospheres in the game area, focus is different. And we change this difference as an advantage. As I say our entire game is in one big scene, but from player point of view, we still need to create a navigation / transition from one section to other. It is a very basic problem (not a problem actually) in a native iOS or Android mobile game/app. They have build-in mechanism and solutions. But here we need to find a way to make that simple transition.

So we use similar concept of iOS ViewController transition states like ViewWillAppear, ViewDidAppear, ViewWillDisappear, ViewDidDisappear. And in addition to that we add some camera moves on screen transitions. In above movie, please give attention inside the scene view and camera moves.

There are much more things that we can talk about, but may be in future posts. Now we are going to concentrate on testing our code.

Power of Unity3D Editor

noreply@blogger.com (Hakan Saglam) — Thu, 08 Sep 2016 11:08:00 +0000

I have already written about the decision on moving to Unity3D in this post. Now it is time to go over all the main items of mobile game development with Unity. There are plenty of documentation, tutorials on how to make game development, I strongly recommend to take a look if you want to learn details of this beast. Here I am going to summarise our experience on creating real-time multiplayer board games on Unity.

As you can understand from the title, first point will be the Editor of Unity. It is very powerful by default and highly customizable. Which means it can even be more powerful in your hands.

I will not tell you about the details of the editor’s basic features. But I can easily say that, you will do almost everything (except coding) inside the editor. Configuring the game scene(s), attaching your codebase to game objects (characters, items, ui elements etc...), creating animations and setting input triggers, choosing preferences, integrating with version control system, preparing your project for a build. As I said almost everything :)

Gin Rummy Plus under the hood :)

The most common and useful windows are shown in my custom (not the default) positions above. This is the arrangement that I am using, it gives me practical access to the the most common windows. Actually I am not sure if there is a best practice on this, because even in our team almost each one of us using different arrangements. I guess we are going to find sweet spots soon :)

The Scene View allows you to visually navigate and edit your scene. The scene view can show a 3D or 2D perspective, depending on the type of project you are working on. Find out more about the Scene View. Actually I am using this section with The Console Window, because while running the game, I am looking either the scene or the logs.

The Game View is rendered from the Camera(s) in your game. It is representative of your final, published game. You will need to use one or more Cameras to control what the player actually sees when they are playing your game. Find out more about the Game View. Similarly I am sharing this section with The Animator Window.

The Hierarchy Window is a hierarchical text representation of every object in the scene. Each item in the scene has an entry in the hierarchy, so the two windows are inherently linked. The hierarchy reveals the structure of how objects are attached to one another. Find out more about the Hierarchy Window.

The Inspector Window allows you to view and edit all the properties of the currently selected object. Because different types of objects have different sets of properties, the layout and contents of the inspector window will vary. Find out more about the Inspector Window. I have another custom window (MockMessenger) here to replicate server socket messages to the game on runtime. I will tell more about custom windows soon.

The Project Window displays your library of assets that are available to use in your project. When you import assets into your project, they appear here. Find out more about the Project Window. And of course I am sharing this section with Unit Test Runner Window. (I will have a separate test section / post.)

The other very important thing about Editor is extending the editor. It is quite easy to customize the editor, and can be very useful. Unity lets you extend the editor with your own custom inspectors and editor windows and you can define how properties are displayed in the inspector. There are various types of customization that we have used in our games. I will give you a few simple ones:

Custom Menu Items

We have created a few functionality and put them under custom Peak Games menu item. That enables us to run those functionalities during runtime and/or development time. To show you how useful they are, let me tell you about three of them: Reconnect, Disconnect, Send To Background functions.

Since we are making realtime synchronous mobile games, it is very frequent to have connection drops, very quick reconnections or sending game to background because of a phone call or something. So it is inevitable to face these issues during the game play. Like other games, we have our own solutions, catch mechanism in different situations like this. But having the solution is not enough, it should be consistent and available on every part of the game. With these custom menu items we can simulate these issues on our games whenever we want on different scenarios and different parts of the game during the runtime (kind of a monkey test).

Custom Windows

Next is custom windows, you can create any number of custom editor windows for your game. These behave just like the Inspector, Scene or any other built-in ones. This is a great way to add a user interface to a sub-system for your game.

Again I will give a real example from our games. We have created a custom window MockMessenger, it is not that sophisticated but to the point. The purpose is replicate server socket messages to the game on runtime.

Like any other software project, we divide the projects into smaller features, and even more smaller tiny tasks. So while we are developing a feature or fixing a bug, we are working on a specific part of the game. And in our case, most of the time that part is highly integrated with server side. Instead of configuring a specific development server or a local server, we are using this window to send server messages to our game. With this window and the function underneath we can send a single message to our game like it is coming from the connected server.

Like sending a single message, we can send multiple messages at once and save that scenario to a file and replay it over and over again. Even we can configure the exact receive times of those messages , so that we can mimic weird socket packages' receive times. As you know sometimes you can get multiple packages in a few milliseconds and wait for the next ones more than ten seconds.

Since socket connection is the fundamental part of our games, it is very crucial for us to replicate these situations very quickly and without big efforts. As you can guess we are using this window very frequently not just developing a new feature, but also simulating or reproducing a real issue. So with this simple window we gain a lot of time and effort.

Customize Hierarchy Window

Other customization that we have done is to show additional information in the hierarchy window. It makes things easier to track during the game play. I guess you already got that we really love card games :)

In a card game, Card (class) is the main character of the game along with Hand, Deck and Pile of course. And it is very important for us to track a card object is enabled or disabled in the game play scene or the conceptual and physical location of the card like is it in the Hand, or is it in the Deck or Pile.

While playing the game, cards are moving between Deck, Hand and Pile. It would be very useful tracking the cards in the editor hierarchy window. For example, by looking at the hierarchy window I want to see the number of active cards which are children of deck or pile or hand. Actually my colleague has already explained this customization in detail.

These are very simple examples just to show you the main idea. You can create much more sophisticated customizations, for instance once we had developed a level editor inside the Unity for an experimental endless runner game.

As last word, it is your imagination and needs that would lead you to make editor customizations. The main idea is to ease and quicken the development of a Unity game.

Now let's write some code...

Why do we move to Unity3D?

noreply@blogger.com (Hakan Saglam) — Tue, 06 Sep 2016 11:47:00 +0000

As I explained in my previous post, I am starting a series of Unity related posts. The idea is create every section of my talk on voxxed days belgrade as a separate blog post. So here it is the first one. Enjoy :)

Before diving into the reasons behind this decision. Let me give you a little background about Peak Games and mobile team.

Peak Games founded at 2010 to create social games on social platforms especially on Facebook. A bunch of very successful games has been developed and published on Turkish market. After one and half years, Peak Games was one of the companies realise that mobile will be the platform for social / casual free-to-play games. And we have established a mobile team. Back then it was very hard to find mobile game developers, even it was very hard to find experienced mobile developers. Actually myself was a senior backend java developer who wants to be mobile developer. So we were aware that it would be a very tough learning process for us.

Our first mission as mobile team was to create ios and android platforms for our existing titles. With a lot of discussions we had decided to move native on these platforms. And we had tried different technologies like cocos-2d and uikit for ios platforms, and c++ (with custom engine) and libgdx for android platforms. I will not go deep on these technologies and decisions that we had. But I can easily say that after two years, we were very happy and comfortable with UIKit (for ios) and libGDX (for android). We had created 10+ games using these technologies, and created 20+ reusable libraries common on these games. With all these efforts and experience we had reduced the time of developing a similar game to one third according to first game that we had build. And I don't want to be humble about these games, they are not mediocre games, they are very very successful games not just in Turkish market, but also in US market. Today hundreds of thousands players are playing these games.

In short, we were happy with the technology, we had the experience, and common libraries for future games. And also we are happy with the end result (I mean the games as whole). We had no doubt that we could build even better games with these technologies. So I guess you wonder, what makes us to think to change the technology behind these games, libraries and experience.

The main reason was the nature of free-to-play games. You have to improve your free-to-play game continuously. Otherwise it would die very soon. We are still adding very big features, or making very big changes on our first titles that we had build more than two years ago. With this reason we have to code our games very clean and readable. We have to use common patterns to solve the problems. This is another topic that I can speak forever :)

My point is having multiple codebases for the same game (ios or android) causes some issues. First of all it make things slow in overall. Since it has different codebases, both of them have different issues. And they have different solutions for same problems. It makes the release planning and enabling/disabling features very hard. Most importantly we want both platforms exactly same as much as possible. But with different platforms, technologies, codebases and different developers it is not possible to get the same results in ios and android. So we have three main reasons:

We want to be quicker on the initial development of the game.
And also we want to be quicker and consistent while improving the game continuously.
We want to have one single codebase for two platforms.

That is why we have decided to go cross platform development for our new games. We were going to keep the existing games in their existing technologies, but we were going to build new games in selected cross platform solution. And also we would not touch our canvas platforms (which is written in AS3 action script technologies). Because even ios and android are different platforms, they are both mobile and we need to give same user experience on these platforms. But canvas is totally different and has to have different user experience.

So let's come to our options for cross platform development. I know that there more than these options to consider but I just list the ones that are in our short list :)

Haxe with custom game engine
Unity3D with C# Language
Cocos2d-x
LibGDX with RoboVM

Haxe (with custom game engine)

Positive points :)

Run Time Performance is real good. Let me give you a real example from one of our games: We had a path finding algorithm written in AS3 and wanted to optimize the performance. By just converting the code to Haxe the performance was increased around 10 times, which is a shocking great result.
Dynamic typing languages are very efficient to hacking things or creating quick and dirty projects. But if you are creating a long living game to be able to maintain it for years. Than you should definitely have static typed language to be able add new features, make bug fixes without breaking other parts.
If you have experienced AS3 engineers, that means adaptation would be very quick and seamless. We all know that the de facto technology of games for canvas is AS3. Most of the social/online gaming companies has very experienced and valuable AS3 engineers. To adapt that experience especially to mobile platforms is very important.
Theoretically with Haxe, you can re-use the code not just in client technologies but also in server side. This is very important especially if you are building multiplayer real-time synchronous games like us. That means you need to have same game rules / game logic both in client and server.
With Haxe you can use different game engine underneath, you don’t need to stick with the same game engine technology for all kinds of your games. Think about that you are building different games in different genres. With Haxe you can have same language but different game engines for different game genres. (I agree that this is something that you need to avoid as much as possible, but having the ability is always good ☺).

Negative points :(

Since it is not a popular language/technology, it will be very difficult to find someone experienced on Haxe. And also it will not be easy to convince good talents to learn and give commitment on Haxe.
There are couple of initiatives for pure Haxe IDE (like HIDE) and also some plugins for existing popular IDEs (like IntelliJ Idea). But it seems to be a pain to establish a fully functional development environment with unit testing support, quick and robust simulator/emulator support, automated UI testing support and CI support.
The documentation is quite weak. Actually Haxe is not that young, it is almost 10 years old. So I would expect better and much more rich documentation. And when it is compared to alternatives, the community is not that big. So with Haxe you will by your own hand, it might be very difficult to get support in emergent cases.
We couldn’t find any very successful top grossing game projects written with Haxe (except the ones in the site). So I guess, it is a very important indicator that it has not enough support or belief on technology.
As far as understand it is not that easy to use Haxe for prototyping a new game idea. That means you need to have another technology/solution for prototyping.

Unity3D (with C# Language)

Positive points :)

Prototyping is very fast and it gives the nearly real feeling of the game play before the production.
With all integrated components (editor, animator, debugger...) you can base your entire game production pipeline over Unity. What I mean is your product managers, level editors, visual designers, sound and animation experts can work on Unity. So that integration of all these parts can easily be done.
With very powerful editor, simulator and debugger, as a developer creating game scenes and tweaking tiny details is very handy.
With the power of language C#, you can leverage most of the C# libraries and community. And also it enables you to create best practice game architecture in means of engineering. And entity/component driven architecture helps to build robust and flexible games.
It has arguably good support and community options. There are a lot of engineers (from indie world to very big game companies), who works on Unity, creates games and develops the community.
It has very great asset store, it is not always the case to use those assets as it is, but it gives really good starting point.
Back then it was one third of all top grossing mobile games were build with Unity3D, nowadays it is almost half of it.

Negative points :(

Right now there is very limited canvas support (with Unity plugin or WebGL) but I believe it will change soon.
Optimizing the performance is very difficult, and out of the box it is not performant. You will always need to make some optimization for performance issues.
Prototyping very fast but finalizing as a complete product and polishing it, is not that easy. You have to be ready to spend a lot of time for just polishing the game.
It is not easy to work Unity as a team. No problem with C# source code but for the other components (like prefabs, scenes) cannot be worked collaboratively by its nature.
As I mentioned C# is great and powerful language. But you should always keep in mind that running the C# code on Mono Runtime has some limitations. And also Mono Develop itself is one of the downside of Unity.

Cocos2d-x

Positive points :)

Open source and highly contributed game development framework and game engine.
It is a library based platform on top of powerful language C++
Since it is based on a very low level language of our days, performance would be very satisfying.
Creating a game with it is very satisfying from engineering point of view.
Optimised for 2D games.

Negative points :(

For me the main negative point is again the language C++. It is very difficult to find someone who knows C++ or who wants to learn C++ :( at least it is the case in Turkiye.
It doesn't have a good game scene or animation editor etc... You have to use different 3rd party tools for this purposes and find ways to integrate with cocos-2dx. It is possible but not easy.
In long term it might be a good decision, but in short or mid term, it requires a lot of effort to create a game. Even create a prototype.

LibGDX with RoboVM

Before pros and cons I want to mention that, we had produced and published a successful game with this option. And you will see that all the good points come from libGDX, and all bad points from RoboVM.

Positive points :)

Half of the mobile team (Android team) is already using libGDX as the primary technology for our native Android games.
There are quite amount of reusable components and libraries based on libGDX. We are already using them in production, so they are mature enough.
Both RoboVM and libGDX is open source. And there are many contributors especially for libGDX, it is always getting better.
libGDX has very robust and quick simulator support, especially when you compare to emulator on Android Studio.
Optimized for 2D games which is important for us.

Negative points :(

RoboVM was an ongoing project and it was changing a lot and frequently.
There were very limited support from community to RoboVM
Since it was kind of beta versions, it has very limited documentation.
We were spending a lot of effort and time to understand and integrate RoboVM.
Bindings from Java to Objetive-C was very painful and very very limited.
One last point project is stopped. It is acquired by Xamarin. And Xamarin aquired by Microsoft. And they decided to stop the project. It is open source but there are no real contribution any more.

Conclusion

After all these positive / negative points it was very difficult to foresee the future of these technologies. So what we have decided is to give a try on Unity3D at least for a few games. And then we could discuss further with real game development experience. And we had developed multiple games with Unity3D, we are happy with the result so far. I think we will stick with this decision especially after we see that it is becoming de facto technology both for indie developers and bigger game studios like EA Games, Blizzard etc...

So first section is done, I hope you enjoyed it. Now I will move to next sections that I am going to tell you about the experience on game development with Unity3D.

Voxxed Days - Istanbul & Belgrad

noreply@blogger.com (Hakan Saglam) — Fri, 15 Jul 2016 10:33:00 +0000

Antwerp / Belcika

Java Dunyasinda Devoxx onemli bir organizasyondur. Dunyanin her yerinden cok onemli konusmacilar ve katilimcilar bu etkinlikte bulusurlar. Yeni teknolojileri ogrenir, tartisir ve fikir alis verisinde bulunurlar. Ben de Sony yillarimda bir kez bu etkinlige katilma sansi bulmustum.

Devoxx 2010'da aldigim notlara soyle hizlica goz gezdirince, mobil teknolojiler, cloud sistemler ve big-data kavramlarinin en trend teknolojiler oldugunu soyleyebilirim.

Voxxed Days ise Devoxx'un cesitli ulke ve sehirlerdeki lokal versiyonudur diyebiliriz. Hatta Istanbul da bu sehirler arasinda. Voxxed Days Istanbul kodcu.com'un gayretleri ile son iki senedir basarili bir sekilde gerceklestiriliyor. Buradan kendilerine tesekkur ediyorum. Ayni sekilde Peak Games olarak biz de bu organizasyona hem ana sponsor olarak, hem de konusmacilar ile katkida bulunmaya calisiyoruz.

Voxxed Days Istanbul 2015 konusmacilarindan birisi de bendim. Peak Games'te mobil takim olarak cok onem verdigimiz "Code Review" uzerine bir konusma yapmistim. Youtube linkini ve yaptigim sunumu paylasiyorum.

Bu sene ise (Voxxed Days Istanbul 2016'da) calisma arkadasim Serdar Sahin, Peak Games'in Big Data evrimini cok guzel bir sunum ile anlatti, izlemenizi tavsiye ederim.

Simdi gelelim asil haber vermek istedigim noktaya :)

Bu sene kisisel olarak kedime, (daha bir cok hedefin yaninda) ikisi yurtici, birisi yurtdisinda olmak uzere toplam uc (sirket disi) sunum hedefi koymustum. Bunlarin yurtici olanlarini ITU ve Bilkent Universitelerinde yaptigim sunumlarla tamamladim. Icim rahat :)

Yurtdisi icin once 360 | iDev Organizasyonuna, aklimda olan bir konu ile basvuruda bulundum, ama malesef kabul ettiremedim, belki onumuzdeki yillarda tekrar denerim. Sonrasinda ise Voxxed Days Belgrad icin baska bir konu ile basvuruda bulundum ve (mutlu haber) kabul edildim. 28-30 Eylul 2016 tarihlerinde Unity ile oyun gelistirmeye giris konulu bir sunum yapacagim. Haydi hayirlisi...

Bu sunumun calismalarina yavas yavas basladim. Kafamda ara konu basliklarini cikariyorum, hangi konu icin ne ornekler verecegimi planlamaya calisiyorum. Benim icin gercekten zorlayici bir tecrube olacagi kesin, iyi hazirlanmak ve ici dolu birseyler sunmak istiyorum. Onumde 11 hafta gibi yeterli bir sure var gibi gorunuyor.

Bu calismalar kapsaminda, aklimda soyle bir plan var. Sunum genelinde toplam 6 - 10 arasi onemli noktadan bahsetmek istiyorum. Bu konulara tek tek hazirlanirken, her birisi icin ayri bir blog yazisi olusturmayi dusunuyorum. Boylelikle hem hazirlanmis olacagim, hem de bu hazirlik kapsaminda yapacagim calismayi burada paylasarak, (pek de ilgilenemedigim) blogumu canlandirmis olacagim. Isallah...

Tabii soylememe gerek yok ama sunum Ingilizce olacak ve dolayisiyla bu calisma kapsamindaki blog yazilarim da Ingilizce olacak.

Gerek bu konu ile ilgili, gerekse diger yazilarimla ilgili yorumlariniz, benim daha iyi bir calisma ortaya koyabilmem icin cok onemli. O yuzden yorum yapin, cekinmeyin...

Bilkent CTIS Lunch Time Seminar

noreply@blogger.com (Hakan Saglam) — Wed, 27 Apr 2016 03:13:00 +0000

Dun Peak Games'ten 5 arkadas, Bilkent Universitesi CTIS bolumunun daveti ile sabahin ilk saatlerinde Ankara yollarina dustuk. Yollarda yasadiklarimizi, taksici ve trafik maceralerimizi bir kenara birakiyorum. Biraz yorucu ama ayni zamanda hem zevkli, hem de yararli oldugunu dusundugum bir ziyaret oldu.

bu pattern'ler bizden sorulur

Amacimiz hem ogrencilere faydali olacak konulardan bahsetmek, hem de Bilkent Univertistesi ile iliskilerimizi artirmak. Cunku bu universitelerden yetisen kisilerle oyunlarimizi gelistiriyoruz. Is hayatinda karsilastigimiz sikintilarimizi, her gun cozmek zorunda oldugumuz sorunlarimizi onlarla paylasmak ogrenciler acisindan ileride onlari nasil bir is hayati bekliyor konusunda yararli oluyor. Ayrica bizim acimizdan ise ogrencilerin okullarda neler ogrendiklerini, oyun sektoru ile ilgilerinin ne derecede oldugunu gormemizi sagliyor.

Is arkadasim Ilkin ile birlikte ne hazirlayabiliriz diye biraz kafa yorduktan sonra hem yaptigimiz is ile alakali olsun, hem yararli olsun, hem oyun dunyasindan birseyler icersin diye karar verdik. Bir saatlik bir sunumda konulari derinlemesine inceleyemiyorsun malesef. O yuzden de, icinde ogrencilere fikir verebilecek, ilgi uyandirabilecek, ilerisi icin baslangic olabilecek bazi noktalar barindiran, tecrubelerimizden ornekler de koydugumuz asagidaki sunumu hazirladik.

Daha once de bir cok kereler bu tarz organizasyonlarla, Turkiye'nin onde gelen universiteleri ile bulusmalar, soylesiler, sunumlar gerceklestirdik. Sahsim adina ve Peak Games olarak bu sekilde devam etmeyi dusunuyoruz. Umarim ogrenciler acisindan da yararli oluyordur.

Ayrica universite ortaminda olmak, o havayi solumak, kantinde bir cay icmek beni tekrar ogrencilik zamanlarima goturdu. Kantinde birseyler yerken, herkes kendi okul yillarina gitti, guzel sohbetler oldu, tam bir gunun bonusu oldu.

Tekrardan daveti icin Bilkent Universitesi CTIS bolumune ve Dr. Erkan Ucar 'a cok tesekkur ederiz.

Hepimiz Yaslanacagiz

noreply@blogger.com (Hakan Saglam) — Sat, 07 Mar 2015 15:25:00 +0000

Sarp'la ara ara parka gidiyoruz, orada kosturmayi, kumlarla oynamayi, salincaga, kaydiraga binmeyi falan cok seviyor. Sevmek ne kelime kendinden geciyor desek daha dogru olur. Neyse evet, bunlari anlatmayacagim, aslinda sadece bir animdan bahsedecegim. Her aklima geldiginde icimi burkan bir animdan bahsedecegim.

Olay kisaca su sekilde. Sarp ile parka gittik. Sarp her tarafa kosturup duruyor ben de arkasindan onu takip ediyorum surekli. Hava biraz serin ama gunesli, montlarimiz var ustumuzde, aylardan Ekim veya Kasim olmasi lazim. O sirada parkin banklarinda oturan yaslica bir nine de bizi izliyor tebessum ederek. Oynadik kosturduk falan ben biraz yorulunca gittim, ninenin bulundugu bankin yanindaki banka kendimi attim. Sarp mi? O hala kosturuyor :)

Biraz bu sekilde uzaktan izledikten sonra, Sarp'a haydi gidiyoruz diye seslendim. Yasli nine, "evladim gidiyor musunuz?" dedi. Ve sonrasinda "Gitmeden sizden birsey rica edebilir miyim?" diye sordu. Tum diyalogu ve benim durumu kavrayana kadar gecen sureyi atliyorum. Ricasi su idi, evde televizyon kumandasinin yanlis yerlerine bastigi icin, tekrar istedigi kanallari acamadigini soyledi. Kendisine yardim edecek cocuklari da tatile gittikleri icin sabahtan beri parkta oturup birisinden yardim istemek icin bekledigini soyledi. Durumu tam olarak anladigimda icimde nasil bir seyin koptugunu anlatamam. Yardim ettim ama cok uzuldum, gunlerce aklima geldi. Ve hatta dedigim gibi ne zaman parka gitsem, icimde bir burukluk oluyor.

hepimiz yaslanacagiz

Simdi, kumandayi kullanmakta ne var diyeceksiniz ama iste olmayinca olmuyor malesef, biz de yaslandigimizda cikan teknolojiler sayesinde bu sekilde caresiz kalabiliriz. (Hatta ben yavas yavas bazi seyleri yerli yerine oturtamiyorum, mesela su snapchat garip, bir turlu kullanamiyorum arkadasim. Benim gibi dusunen bir cok yasli da varmis hatta :))

Ama iste bunun olmasini engelleyebiliriz. Benim nacizane iki onerim var (size degil, kendime :))

Esiniz, sevgiliniz, aileniz en yakin dostlariniz olabilir. Bunlarin disinda da her dakika gormek zorunda olmadiginiz dostlariniz da olmali. Bu konuyu daha once ele almistim tekrar tekrar yazmiyorum :)

Digeri ise, televizyon gibi edilgin olmadiginiz, her daim sizin yaninizda olacak hobilerinizin olmasi. Bu hobileri yaslaninca gelistiremezsiniz (yani bana oyle geliyor). O yuzden henuz gencken, dincken ve boyle hobilere cok fazla zamaniniz yokkken, ne yapip edip tum is ve hayat stresinden sizi uzaklastiracak hobiler edinmeniz cok onemli.

Simdi bunlar isin bir tarafi...

Diger taraftan ise, siz siz olun anneninizi, babanizi, dedenizi, ninenizi bu durumda birakmayin. Her zaman savunmusumdur, Turk aile yapisi bir cok kulture gore cok daha dogru geliyor bana. Kucuklerin ailelerinin himayesinde olmasi, yaslilarin ise cocuklarinin guvencesinde olmasi asla vazgecmememiz gereken prensiplerimizden bence. Bu yaklasimin yeni nesil icin ozguven eksikligine neden olabileceginin farkindayim. Benim savundugum, ozguveni olusturmak icin farkli farkli yontemler varken, bu kadar ozel bir adetimizden vazgecmememiz gerektigi.

Ve evet bayramlarda tatil koyleri yerine aile ziyaretinin cok daha huzur verici, cok daha dinlendirici ve cok daha insani bir durum oldugunu dusunuyorum.

Kristal Piksel Video Oyun Odulleri

noreply@blogger.com (Hakan Saglam) — Thu, 13 Nov 2014 22:30:00 +0000

Yine ben :)

Surekli yaziyormus izlenimi...

Ve Yilmaz Ozdil tarzi bir yaklasim :))

Neyse konuya gireyim. Gecen haftasonu (09.11.2014) Oyun Gelistiricileri Dernegi'nin katkilari ile ucuncusu gerceklesen Kristal Piksel Video Oyun Odulleri toreninde Peak Games calisani olarak juri uyesi ve davetli konusmaci :) olarak bulundum.

Guzel bir organizasyon ve toren ile aday olarak gosterilen 60 tane halis muhlis Turk yapimi oyunu inceledik. Ve once finalistleri sonra da finalistler arasindan 8 farkli kategoride kazananlari (dogal olarak) zorlu ve tartismali bir surec sonunda sectik. Bu surecteki tartismalardan ve juri uyelerinden bahsetmem dogru olmaz diye dusunuyorum.

Ama odul toreninden, kendi konusmamdan ve panellerden bahsedebilirim.

Yilin Oyunu: Incredible Toys

Oncelikle odul toreni, simdi Turkiye'de oyun sektorunun daha emekleme asamasinda oldugu gercegini hesaba katarsak, finalistler ve kazananlar gayet guzel produksiyonlar. Ama global olcekte baktigimizda gercekten gerilerdeyiz :( Tum finalistleri ve kazananlari buradan gorebilirsiniz, bazi oyunlari ozellikle Egg Fight'i cok cok begendim.

Bununla birlikte oyun yapan, ugrasan herkese tebriklerimi iletmek isterim. Cunku bu isin ne kadar zor ve cetrefilli bir surec oldugunu bizzat tecrube ediyorum. Iste bu zor surecte, bu tarz organizasyonlarin temel amaci oyun ekosistemini gelistirmek, insanlari tanistirmak, manevi destek olmak seklinde dusunebilirsiniz. Kristal Piksel Video Oyun Odulleri de bu parallelde bir organizasyon, tum emek verenlere tekrardan cok tesekkurler.

Peki benim konusmam nasildi derseniz. Ben pek begen(e)medim aslinda. Cok kisa zamanda hazirlanmam gereketiginden, uzerinde cok fazla dusunemeden "Mobil Oyunlar" uzerine konusmaya karar verdim. Genis bir konu oldugunu biliyorum evet, biraz daha spesifik bir konu secseydim daha iyi olabilirdi. Bir daha ki sefere artik. Bu genis konu uzerinde edindigim tecrubelerden, bazi istatistiklerden ve bagimsiz oyun gelistiriciler icin bazi ipuclarindan boyle hap gibi bahsettim. Dedigim gibi bunun yerine daha spesifik bir konu uzerinde daha genis konusmak sanki biraz daha iyi olurdu.

Konusmam kaydedildi ama nerede yayinlanacak, veya yayinlanacak mi bilmiyorum. Gerci onun haricinde TurkNet.com'dan Figen hanimla bir video roportaj yaptik, galiba o yayinlanacak, en kotu onu buraya eklerim. Ama buyrunuz yaptigim sunum, afiyet olsun:

Mobile Games from Hakan Saglam

Gelelim panellere, ilk panelde kendi oyun sirketlerini kurmus, bir sekilde hayatlarina devam eden girisimciler (Ergun Güvenç, Erkan Bayol, Hakan Tüzün) vardi. Cok faydali bilgiler verdiler. Cok kisa ozeti buyuk hayalleriniz olabilir ama kucuk kucuk aksiyonlarla ilerleyin, bir cok deneme yapin, tecrube edin, yilmayin, birbirinize yardim edin ve en onemlisi size uygun degilse girisimci olmayin :) bu noktada eski yazilarimdan bir tanesi aklima geldi, tavsiye ederim.

Diger panelde ise, Turkiye'deki oyun sektorunun onde gelen basin insanlari (Tuğbek Ölek, Levent Pekcan, Gökhan Yılmaz) vardi. Yine kisa ozet gececek olursam soyledikleri sey suydu. Basinin sizi desteklemesini istiyorsaniz bu is icin zaman ve enerji harcayin. Sadece oyunun teknik tarafini bitirip simdi bizi basinda yayin diyemezsiniz, pazarlama ve tanitim icin de ugrasmalisiniz, mumkunse isi bu olan bir yardimciniz olsun tavsiyesinde bulundular.

Konuyla ilgili (TeknoSeyir ekibinden Levent Pekcan ve Murat Gamsiz'in hazirladigi) cok aciklayici bir videoyu buradan izleyebilirsiniz.

Iste boyle, benim icin degisik ve guzel bir tecrube oldu. Guvenen, cagiran, yardim eden, dinleyen ve tabiki bu yaziyi okuyan herkese tesekkur ederim.

Saglicakla....

Dostluk Uzerine Bir Film

noreply@blogger.com (Hakan Saglam) — Thu, 26 Dec 2013 08:11:00 +0000

Gecen gun, gecenin bir yarisi uyanan, ve uyanmakla kalmayip ustune oyun oynamak isteyen Sarp'i tekrar uykulu haline getirmek icin cok ugrastim. Tabii bu arada benim uyku da kacmis oldu. Yakiniyorum zannetmeyin, ben her halini seviyorum keratanin, anlatmak istedigim baska seyler :)

Neyse madem gecenin bir vakti ayaktayim, soyle televizyonda ne var diye bakarken, daha onceden bir ucak yolculugunda izleyip cok begendigim "Stand Up Guys" filmine rastladim. Ve tereddutsuz tekrar izlemeye koyuldum. Super super bir film, IMDB'de neden 6.5 yildiz almis anlamadim. Suprizli , vurdulu, kirdili olmadigi icin belki de... Neyse ben neden cok sevdim derseniz, kisaca ozetleyecegim izninizle...

Bu arada bastan soyleyeyim, filmden bazi seyler (spoiler alert) analtacagim. Sonra problem olmasin. Gerci bu tutumu da anlayabilmis degilim, bir filmi sadece sonu icin mi izliyorsunuz, arada gecen olaylar, muzikler, oyunculuk, karakterlerin gelisimi hic onemli degil mi. Neyse benim gibi dusunenler ve daha once izlemis olanlar icin gelsin bu yazim.

Film Val'in (Al Pacino) bilmem kac yil sonra hapishaneden cikmasi ile basliyor. Onu karsilamaya gelen kadim dostu Doc (Christopher Walken) ise icinde bir sikinti veya ikircikli bir halde... Ve daha sonra bir bakim evinden kaciracaklari ucuncu dostlari ve ayni zamanda da yillar once yaptiklari islerde driver olan Hirsch (Alan Arkin) ile cete tamamlaniyor. Bu uclu sadece 1 gun geciriyorlar, yani film sadece 1 gunu anlatiyor. Doc'in sorunu ne, Val ne istiyor, Hirsch nasil oluyor, hepsini bir gecede goruyoruz :) Bazi kisimlari gercekten uzak, abarti buldum. Sonunu pek begenmedim. Ama ozellikle (genelde yardimci rollerde oynayan) Christopher Walken'in muthis oyunculugu ve cool tavirlari superdi.

Peki, bu filmi neden bu kadar cok sevdin derseniz. Oncelikle yillar suren boyle bir dostlugu kim istemez. Aralarinda ne bir cekisme, ne de bir catisma var. Tum sirlarin hic cekinmeden, rahatca soylenebilmesi hatta soylenmesine bile gerek olmadan anlasilmasi. Oyle buyuk sevgi gosterileri olmaksizin, iclerindeki sevgiyi hissettirebilmeleri. Yani beni asil etkileyen ve uzerine yazi yazdiran filmin senaryosu, sonu, muzigi, oyunculuklarindan ziyade, hissettirdigi o dostluk havasi... Tamam, tamam o hava az once bahsettigim unsurlar bir araya geldigi icin olusmus ama resmen icimde yer etti bu film.

Dostluk nedir, tarifi varmidir. Sozluk anlamindan bahsetmiyorum, bir arkadasin ne zaman dostun olmaya baslar. Nasil olcersin, olcmeye gerek var mi ki... Birisine dost olmaya calisamazsin, ya da sokaklarda dost arayamazsin heralde... Bir insanin hayatta kac tane dostu olabilir, senin kac tane dostum diyebilecegin kisi var cevrende. Yani zor bulunur, tam olarak tanimlayamadigin icin de arayamadigin, kendiliginden olan, icten gelen bir durum galiba... (Simdi aklima geldi de, Ingilzce'de bunun karsiligi var mi mesela, buddy falan tam olarak yerini tutmuyor sanki...)

Ne diyeyim, umarim dostlarimizi tez zamanda buluruz ya da bulduklarimizin kiymetini biliriz. Ve kurdugumuz dostluklar da bu filmdeki kadar uzun soluklu, karsiliksiz ve saf olur... Amin...

eTohum Oyun Gelistiricileri Zirvesi'ndeydim

noreply@blogger.com (Hakan Saglam) — Mon, 09 Dec 2013 09:51:00 +0000

Aslinda 2013'teki basarimdan(!) dolayi kendimi kutlamak istiyorum. Suana kadar sadece 3 tane yazi yazmisim koca yilda... Umarim bu basarim 2014'te devam etmez.

Her neyse asil konuma donecek olursam. Bildiginiz uzere (benim icin ciddi) bir kariyer degisikligi ile Peak Games'le birlikte oyun ve mobil dunyaya giris yapmistim. Kendi adima daha henuz emekleme asamasinda olmama ragmen Burak Buyukdemir tarafindan eTohum Oyun Gelistiricileri Zirvesinde oyunlari nasil yaptigimizla ilgili bir sunum yapma teklifi aldim.

Once heyecanla soyle 45 dakika - 1 saatlik bir sunum hazirliklarina basladim, cunku anlatacak cok sey vardi. Aralarindan daha heyecanli (yani biz developer dunyasi icin heyecanli) olanlarini sectim falan guzel bir sablon olusturdum. Hatta sunumun yarisini da hazirlamisken, zirvenin ajandasi aciklandi ve konusmaci coklugundan dolayi herkesin 20'ser dakika konusmasina yetecek kadar zaman oldugu ortaya cikti. Neyse oyleydi boyleydi derken ben sunumu kirptim da kirptim :) Isterseniz soyle bir goz gezdirin.

Mobile Board Game Development Lifecycle from Hakan Saglam

Benim zirveden cikardigim sonuc, Turkiye'de oyun dunyasi (ayni benim gibi) daha yolun en basinda, ogrenmesi ve tecrube etmesi gereken yuzlerce konu var. Tabii bu ogrenmek ve tecrube dedigimiz seyler zaman, efor ve para gerektiriyor.

Gordugum kadariyla zaman konusunda bir sikintimiz yok. Ama efor konusunda ciddi sorunlar var, herkes kolay yoldan biseyler yapmak pesinde, yargilamiyorum ama isin dogru yolu bu degil bence. Cikis noktamiz kesinlikle para olmamali, dunyayi sallayacak isler cikarmak istiyorsak cok calismak zorundayiz, kolay yoldan cok calismak diye bisey de ben bilmiyorum :)) Para konusunda ise daha ciddi sorunlar var, oyle veya boyle bir turlu kaynak bulunamiyor. O yuzden de bu ise girisenlerin ilk yaptigi oyunun basarili olmamasi ikinci oyun icin nefeslerinin yetmemesine neden oluyor. Ve az da olsa elde edilen tecrube ve bilgi boylelikle dagilmis, kaybolmus oluyor.

Bunlarin isiginda cok rahat diyebilirim ki, Turkiye'de oyun dunyasinda basarili olmak istiyorsaniz; fazla maceraya girmeden oncelikle kendinize amiral gemisi niteliginde oyunlar cikarmaniz lazim. Peak Games'in stratejisi bu noktada cok dogru, board oyunlari uzerinden kendisine finans, kullanici ve itibar saglayip daha baska maceralar icin imkan olusturmus oluyor. Sonucta anladigim kadariyla board oyunlari (Okey, Tavla...) Turkiye'de en cok oynanan oyunlar, bu konuda uzman sayilmam ama gorunen koy de klavuz istemez.

Bu arada yeri gelmisken bir konudan bahsetmeden gecemeyecegim. Zirve'de Tart Games ve Startup Kitchen'dan Emrah Olgun da bir sunum yapti. Uzun zamandir calistiklari, ve basariya ulasan ama bir turlu para kazandiramayan Kixel isimli oyunlarindan ve yasadiklari guzel tecrubelerden bahsetti. Kendisine tesekkur etmek istiyorum. Bunun yaninda sunumunda bir kac kere ustune basarak soyledigi "nedense Tavla veya Okey yapmadik" cumlesiyle, zaten yolun daha basinda olan Turk Oyun Dunyasini anti-cesaretlendirici tavirlara girmemek gerektigini dusunuyorum...

Bunlar haricinde Zirve gercekten guzeldi. Organizasyon icin eTohum'a ve beni davet ettigi icin Burak'a cok tesekkur ediyorum. Benim nacizane bir onerim bu tur zirvelerde daha teknik konular konusulmali, sadece surecler, tecrubelerden ziyade hands-on sunumlar daha cok olmali diyerek bu yilki 4. yazimi da bitirmis oluyorum, ne mutlu bana...

Girisimci mi, Girisken mi?

noreply@blogger.com (Hakan Saglam) — Thu, 01 Aug 2013 08:15:00 +0000

Bir kac ay once bitirdigim bir kitaptan aldigim bazi notlari paylasmak istiyorum. Ve startup bir sirket kurmanin, veya super oldugunu dusundugunuz bir fikrinizin hayata gecmesi icin gereken bazi puf noktalari listelemek istiyorum. (Yazinin basliginin anlami asagida :)

Okudugum kitap "Founders at Work", "Gisirimciler Is Basinda" seklinde Turkce'ye cevrilebilir heralde :) Neyse sahsen kendim, boyle bir startup veya girisimde bulunmadigim icin ancak iste bu kitaptan okudugum ve anladigim kadariyla sizinle paylasiyor olacagim.

Apple nasil kuruldu merak ediyorsaniz ama bu sefer Steve Wozniak'in agzindan :). Ya da Yahoo'nun, Hotmail'i iyi bir business olarak gormedigini ve Microsoft'a kaptirdigini ogrenmek isterseniz. Adobe'nin (Flash''in sahibi olan sirketin) kurulus hikayesinde Apple'in nasil onemli bir rol aldigi, PayPal'in neden bu kadar yaygin oldugu, Gmail'in nasil ortaya ciktigi, Flickr nasil oldu da bir oyun parcasindan 100binlerce kullanicisi olan sosyal image paylasim sitesi haline geldigi sekilinde devam eden yaklasik 20-25 civarinda cok unlu sirketin kurucu veya kurucularinin baslangic hikayelerinden olusuyor kitap.

Bu milyon dolarlik sirketlerin kurulusunda izlenen yollar cok degiskendi.

Kimisi hizli ama bug'li versiyonla hayata atilirken, kimisi yavas ama saglam adimlarla kurmus sirketini / urununu...
Bazi kurucular elindeki tum parayi, ya da tum yatirimci parasini bu ise adarken, diger kisim cok az para harcama dusturunu benimsemis.
Yatirimcilarla calismasaydik basarili olamazdik diyen var, yatirimcilari hic yanimiza yaklastirmadik ancak oyle basarili olduk diyen de var.
Kimisi en basindan bir is plani cikarip ona gore ilerlemis, kimisi ise is planini surekli degistirmis hatta hic is plani olmayan bile var.
Bazi fikirler / urunler cok orjinal, dunyada bir benzeri yokken, bazilari ise bir suru ornegi olan siradan bir firkir / urunle basariya ulasmis.

Bu liste boyle uzayip gider. Hepsinin degisik, ilginc hikayeleri var. Hepsinde katilacaginiz veya katilmayacaginiz yorumlar var. Ama bence asil onemli olan hepsinde ortak olan 4 nokta var benim cikardigim. Bu noktalar tabiki yoruma acik noktalar ama benim okudugum kadariyla hepsinde var ve bence anahtarda bu noktalarda...

Tutku (Passion) - Tartismasiz en one cikan madde bu bence... Hepsi yaptigi ise inanmis, zorluklara, elestirilere ancak bu sekilde karsi durmus. "Bu da belki tutar" demek yerine fikrinin/urununun dunyayi degistirecegini kendisini inandirmis. Yani demem o ki, yapacaginiz urun ne olursa olsun, once kendinizi bu is icin adamaniz gerekir, bu da ancak ve ancak o urune gercekten inanirsaniz olur.

Cok Calismak (Hardworking) - Istisnasiz her hikayede sabahlara kadar calismalardan bahsediliyor. Hani vardir ya, "Google iste" yapiyor adamlar. Heralde yatarak yapmiyorlar islerini, eminim (ve icerdeki kaynaklardan da teyitli olarak soyleyebilirim ki) cok calismadan, geceni gunduzune katmadan herhangi bir konuda basarili olmak malesef mumkun degil. Aklinizdaki "super bir fikir bulucam, sonra gelsin paralar" dusuncesini okur gibiyim, cikarin su fikri aklinizdan artik. Cikarin cunku o fikir icin cok calismak zorundasiniz.

A Kalite Insanlar - Hepsinde ortak olan diger nokta ise, falanca kisi olmasaydi basaramazdim, isin sirri takimda gibi ifadelerdi. Yani demem o ki, basari icin olmazsa olmaz isini iyi yapabilmek icin cabalayan insanlarla calismak. (A Kalite insan derken, insanlik, iyilik gibi ulvi vasiflardan ziyade is bitiren, yarim is birakmayan, kaliteli is cikaran insanlardan bahsediyorum :)). Siradan ortaklarla veya takimla bu tarz dunya capinda isler cikarmak bence imkansiz.

Sans - Evet en son madde sans :) hikayeleri okuyunca sansa bak su adama rastlamis, o sirada bu olay patlak vermis falan demediginiz bir tane hikaye yok. Sansiniz yaver gitmezse ne yaparsaniz yapin basariya ulasmaniz neredeyse imkansiz (tabiki burada basarinin tanimi cok onemli, benim demek istedigim dunya capinda is cikarmak). Gerci ben kisaca sans dedim ama isterseniz siz kader deyin, tesadufler silsilesi deyin ne derseniz deyin. Ama asil ifade etmek istedigim nokta, isin bir kismi da sizin ellerinizde degil... Gerisi icin dua mi edersiniz, fal mi baktirirsiniz, caput mu baglarsiniz bilmiyorum artik...

Yanliz son olarak ozellikle dikkatinizi cekmek istedigim bir nokta var: orjinal fikir bu 4'lu arasinda degil...

Fikirler, fikirler, fikirler

Eveeet, bunlar kitaptan gelen bilgilerdi. Simdi birazda kendi tecrubelerimden bahsetmek istiyorum. (Eee burasi benim blogum sonucta, biraz da kendimden bahsedeyim oyle degil mi) Yazinin basinda dedigim gibi, oyle buyuk capli bir girisimim olmadi henuz ama her yazilim muhendisi gibi benim de, kendi capimda, yirtma projelerim oldu. Henuz tam olarak istedigim seviyeye gelemediler. Kimisinde tek basimaydim, kimisinde ise bir veya daha fazla arkadasla beraberdim. Bir arkadasimin ifadesi ile girisimci degil de, girisken (yaa, anladin simdi basligi) olarak hayatima devam ederken size verebilecegim gercekler bu sekilde:

Eger "side project" (gunluk isinize ek olarak) yapiyorsaniz, hergun vaktinizi ayirmazsaniz bu is olmaz. Yani en yogun oldugunuz zaman bile, en azindan bir saatinizi ayirmaniz gerekir.
Asla sadece zaman ve emeginize guvenmeyin, parasal olarak da yatirim yapin: tasarimci, reklam vs... Pamuk ellerinizi biraz cebinize atin kisaca :)
Yapmak istediginiz sey ne durumda olursa olsun, versiyon 1.0'i kesinlikle cikin. Yani projeyi yarim, tozlu bir GIT repository'sinde birakmayin. Onun da yasamaya, kosmaya hakki var.
Focus'unuzu oyle ota boka dagitmayin, ayni anda en fazla bir, bilemedin iki proje ile ilgilenin. Daha fazlasi demek daha fazla yarim projeniz olacak demek.
Sabahlari ise gideyim, aksam da bu fikrimi hayata gecireyim mantigi ancak ufak tefek isler icin olur, daha buyuk isler tum zamaninizi ve enerjinizi alir.
Son madde olarak, daha kisisel bir gercek: Sadece tek basima (ortaksiz) giristigim projeler hayata gecti. Artik bu da benim sansim mi, yoksa pek takim calismasina uygun degil miyim ya da tek basima dunyalara bedel miyim bilemiyorum.

Neyse benden bu kadar, sizlerin de dusunce ve tecrubelerinizi duymak / okumak isterim.

WWDC 2013

noreply@blogger.com (Hakan Saglam) — Tue, 09 Jul 2013 09:32:00 +0000

Bu sene ilk defa yasadigim bir tecrubeyi sizinle paylasmak istiyorum. Apple'in dunyaca unlu konferansina katilma sansini buldum ve tecrubelerimi sizinle paylasmak istiyorum. Nasil oldu, ne alaka diyorsaniz eger: Yine acayip degisiklikler oldu hayatimda ve kendimi bir anda mobil oyun sektorunde buldum. Ozellikle sosyal oyun pazarinda Turkiye'nin ve dunyanin sayili sirketlerinden Peak Games 'te Head of Mobile Development olarak calismaya basladim. Buraya nasil geldim bir ara yazarim (belki!!!)...

Neyse gelelim asil konuya, WWDC 2013...

katildim evet :)

Hikaye aslinda WWDC sayfasindan bilet almaya calisirken basladi. Belli tarih ve saatte biletlerin satisa sunulacagini ogrenince, elimizde kredi karti gectik bilgisayar basina ama biletler daha sistem acilir acilmaz tukendi. Apple yetkililerine gore tam olarak 71 saniye icinde tukenmis. Inanilmaz, zannetmiyorum hic bir konser bileti, hic bir event bu kadar cabuk bitmemistir. Gercekten inanilmaz... Herneyse o anda oylece kala kaldim, bileti alabilenler arasina giremedim tabiki de, 71 saniye ne demek yahuu... Eee nasil oldu da, katildim. Orasini ben de tam bilmiyorum ama bir sekilde sevgili sirketim bilet ayarladi ve here I am (buradayim).

Biraz keynote'tan (ana sunum'dan) bahsedecegim (diger session'lardan bahsetmemem gerekiyormus), biraz da izlenimlerimden. Sevgili Tim basladi anlatmaya (bekledigim onca sirayi atliyorum artik). Iste aldigim notlar:

71 Saniye'de biten biletler icin tesekkuru haketmistik zaten :)
Su anda Apple elinde bulundurdugu 575 milyon kullanici yani 575 milyon kredi karti bilgisi ile degme online satis sitelerinden cok daha fazla potansiyele sahip
Su ana kadar, tum developer'lara 10 milyar dolar dagitmis adamlar, inanilmaz bir miktar ama bir de isin diger tarafini dusunun %30'unun hep Apple'a gittigini..
Mobile uygulama pazarindaki gelirin %75'ini ellerinde bulundurduklarini soyluyor.
Anki drive diye bir AI (Yapay Zeka) sistemini gosterdiler ama tam anlam veremedim ne alakasi vardi acaba... Ustelik bu tur girisimler dunyanin her yerinde hatta benim universite yillarimda bile ITU 'de biseyler yapiliyordu.

Sonra biraz yeni Mac OS X Mavericks

Finder Tabs - Bildigin sekmeler iste...
File Tags - Artik dosyalarinizi tag'leyebiliyorsunuz. (Pek kullanacagimi sanmam)
Map, Notification Center ve iBooks artik hem iOS, hem de MacOS'de calisir hale getirilmis.
iCloud Key Chain ile tum sifreler falan filan tum cihazlariniz arasinda paylasilabilicek
iWork - Google Docs/Drive benzeri biseyler yapilmaya calisilmis
Multiple Display (benim de hosuma giden bir degisiklik)
Performance Enhancements
Battery Life Enhancements

Safari'de guzel degisikliker var. Ve guzel karsilastirmalar gosterildi Chrome, Firefox, IE ve Safari arasinda (biraz yanli olabilir bu karsilastirmalar:))

Yeni makinalar gosterildi

New Mac Air - Pilinin 1 gun gittigini idda ettiler ki, eger dogruysa cok iyi degil mi sizce de...
Mac Pro - Cok guclu bir makinaymis, yuvarlak, silindir seklindeymis falan falan, ben cok etkilenmedim ama guzel son teknoloji gibi gorunuyor :)

Ve tabiki iOS

Once biraz rakiplerden nasil daha iyi olduklarindan bahsetti. Ozellikle Android'ten tabiki.
Android'teki OS fragmentation'ina karsilik, iOS kullanicilarinin %95'ten fazlasinin hali hazirda iOS6'yi kullandigini altini cizerek belirtti.
Sonra da yeni iOS 7 'i acikladi, suana kada iOS'teki en buyuk degisiklik olarak nitelendirdi ki, kesinlikle dogru..
Yepyeni interface, cok daha minimalist bir yaklasim, gercekten etkileyici bir degisiklik olmus. Resmen butun uygulamalar degismis, cok guzel olmus.
Control Center ile bazi ayarlara aninda ulasip, istediginiz degisikligi yapabiliyorsunuz.
Multitasking ve background'ta calisma olayini biraz daha gelistirmisler, bu konuda teknik bir post atabilirim ilerde...
Safari, resmen chrome olmus :) (kusura bakmayin Apple'cilar)
Mac'lerde de olan AirDrop (hizli dosya paylasimi) iOS cihazlarina da geldi
Photos uygulamasi, cok daha akilli bir sekilde kategorizasyon yapabilir hale getirilmis
AppStore uygulamasi, cevremde en cok indirilen uygulamayi gosteriyor artik, bayagi hosuma gitti benim bu ozellik
Arti AppStore artik uygulamari (eger isterseniz) otomatik olarak guncelleyebiliyor.
Ve tabiki iTunes Radio tanitildi. Pandora, Last FM tarzi bir radyo uygulamasi Suan icin sadece Amerika'da calisiyor ama cesitli numaralarla Turkiye'de de dinlyebilirsiniz.
Biraz daha teknik bir konu olarak SpriteKit ve UIDynamics ile Apple oyun gelistiricilere cozumu disarilarda degil iOS'in icinde arayin diye mesaj verdi. Bu konu ile ilgili kesin bir post hazirlayacagim.

Ve 500'den fazla yeni ozelligin gelistiriciler icin sunuldugunu acikladi. Bunlarin bir kismini orada dinledim cok etkileyici guzel seyler oldugu gibi cok kiytirik seyler de vardi. Simdilik bunlari soyleyemiyorum.

Yazacak daha cok sey var belki ama son olarak Apple'in uygulama gelistirmeye bakisini (en azindan benim anladigim kadariyla) iki madde ile ozetlemem gerekirse;

Son derece tasarim odaklilar, UI (kullanici arayuzu) ve UX (kullanici tecrubesi) onlar icin en en en onemli sey. 45 dakikalik sunumun, 15 dakikasini sadece bir ikon nasil olmalidir konusuna ayirabiliyorlar.
Yaptiklari herhangi bir seyi en mukemmel yapmak icin cok fazla ugrasiyorlar. Ortaya cikan seyi begenirsin veya begenmezsin o ayri ama asla "ya bu konuyu da biraz sallamislar sanki uzerinde pek dusunmeden yapmislar" diyemezsin.

Dedigim gibi, daha anlatacak bir suru konu var ama kimine zorunlu olgudum icin giremedim, kimine ise baska zamana erteledigim icin giremedim. Simdilik bu kadarla idare edeceksiniz artik.

Saglicakla kaliniz....

I Love My Job - Product Owner

noreply@blogger.com (Hakan Saglam) — Sun, 27 Jan 2013 18:40:00 +0000

Evet ben isimi seviyorum, tamam her gunum super, mukemmel veya herkese gulucukler sacarak gecmiyor, bazen yorucu veya sinir bozucu olabiliyor ama genele baktigimizda ben mutluyum :) Iste ondandir ki, "I love my job" basligi altinda suana kadar is hayatimdaki tum rollerde neler yaptim, nasil yaptim ayri bir sunumla paylasmayi dusunuyorum. Oyle hemen kisa zamanda olmaz biliyorum ama zamanla tamamlarim umarim. Aslinda olay soyle basladi.

Bir arkadasimin on ayak olmasi uzerine 8 Kasim'da Agile Turkey'in Agile Bulusmalar adli etkinliklerinden bir tanesine katildim. Yaklasik 2 saat suren gayet keyifli, gayet bilgilendirici, rahat bir ortam buldum. Benim 2 yil kadar PO (Product Owner) rolunde calistigimi ogrenen etkinlik organizatorleri bir dahaki bulusmanin konusunun Scrum'da PO rolu uzerine olmasini ve soyleyisiyi benim yonetmem seklinde oneride bulundular. Ben de elimden geldigince biseyler yapmaya calisacagimi soyledim.

Aradan zamanlar gecti, degisimler yasandi :) ve PO Rolunu konusacagimiz etkinligin tarihi ve yeri belli oldu. Oyle bir yazdimki sanki bu bulusma olmadi, iste artik o da benim kendimi ifade edememem diyelim :) bulusma oldu, hatta bulusma ile ilgili gayet guzel bir ozet de Lemi bey tarafindan yayinlandi.

Iste tam o sirada aklima geldi. Soyle guzel bir "I love my job" serisi yapayim ilki de Product Owner'lik uzerine olsun... Etkinlik icin hazirladigim notlarim ve tabiki 2 yil boyunca edindigim tecrubelerime dayanarak ufak bir sunum hazirladim ve slideshare alanimda yayinladim, afiyet olsun efendim.

Product Owner from Hakan Saglam

Dosya Backup Stratejilerim

noreply@blogger.com (Hakan Saglam) — Sat, 22 Dec 2012 11:54:00 +0000

Bir onceki yazimda bahsettigim gibi simdi de dosya backup stratejilerimi anlatmak istiyorum. Backup konusunda sync kadar anlatacak sey yok aslinda. Daha once de dedigim gibi uzerinde calismadiginiz ve artik degisiklik yapmadiginiz ve kaybolmasini istemediginiz dosyalarinizin backup'ini almalisiniz.

Fotograf ve videolar'in backup'i olarak Picasa Web kullaniyorum. Google+ mobil uygulamasi sayesinde cekilen her fotograf otomatik olarak picasa'ya aktariliyor. Diger cihazlardan veya baskalarindan aldiklarimi manuel olarak upload ediyorum. Boylelikle cekilen hic bir fotografi kaybetmemis oluyorum. Hatta iki yerde birden saklamis oluyorum ki size biraz abarti gelebilir ama backup budur :)

Biraz Picasa Web'ten bahsedeyim. Google Drive ile ayni alani kullandiklari icin 5GB free alana sahipsiniz direkt olarak. Ustelik upload ettiginiz resim 1MB'den kucukse onu kotanizi kullanmadan sakliyor. Bu da guzel bir ozellik :)

Diger dosyalar icin ise tahmin ettiginiz uzere Google Drive'i kullaniyorum. 100GB'lik bir program satin aldim. Dropbox'a gore cok daha ucuz bir cozum ama henuz Dropbox kadar fonksiyonel ve olgun degil ama arkasinda Google olmasi uzun vadede daha iyi olacagini ve fiyatinin da her zaman daha iyi olacagini dusunuyorum acikcasi, aralarinda cok buyuk bir rekabet oldugunu buradan anlayabilirsiniz.

Drive vs Dropbox

Mac tabanli bilgisayarlarda sectigim dizinlerin otomatik olarak Time Machine ile lokal olarak yedeklenmesini sagliyorum. Daha sonrada bu yedekleri 5 - 6 ayda bir manuel olarak Google Drive'a upload ediyorum.

Windows tabanli bilgisayarlarda (is bilgisayarinda) ise yine ayni mantikla belirledigim dosyalari ekstra bir program kullanmadan zip'liyorum ve ara ara (2-3 ayda bir) manuel olarak Google Drive'a upload ediyorum.

Dosya Senkronizasyon Stratejilerim

noreply@blogger.com (Hakan Saglam) — Wed, 19 Dec 2012 19:24:00 +0000

Evet gecen gun farkettim ki, aslinda bir backup ve senkronizasyon (sync) stratejim yok kendi kisisel dokumanlarim, resimlerim, muziklerim icin falan... Hasbel-kader kullandigim bazi uygulamalar zaten cloud (bulut) tabanli oldugu icin oto sync/backup yapiyor ama yinede kaybedersem cok uzulecegim seyler var bilgisayarlarimda (evdekiler ve isyerindeki), telefonlarimda (kisisel, is telefonu ve esimin telefonu) veya tablette veya kindle'da veya diger yerlerde... Ozellikle baba olduktan sonra cekilen hicbir fotografi kaybetmek istemem dogal olarak. O zaman dedim zamani gelmis soyle guzel bir backup/sync stratejisi oturtmanin. Simdi sizinle bu stratejiyi paylasacagim ama oncesinde bu kavramlara bir aciklik getirmek istiyorum.

Backup - Kaybolmasini istemediginiz her turlu dosyanizi (resim, word dokumani, programlar, kod parcaciklari gibi...) baska bir yerde daha tutmak. Yani, ayni dosyayi baska bir yere daha kopyalamak. Herhangi bir sekilde orjinalleri kaybederseniz, bu sakladiginiz dosyalari orjinal yerine kopyalayip hayatiniza devam edebilirsiniz.

Sync - Senkronizasyonun kisaltmasi olan bu kavram ise herhangi bir dosyanizi iki veya daha fazla farkli lokasyondan kullanmaniz gerektiginde, yaptiginiz degisikligin aninda diger lokasyonlara da yansimasini istediginiz zamanlarda kullanilan bir kavramdir.

Durumu daha da netlestirmek icin ikisi arasindaki en onemli farklar soyle, cok sik degismeyen dosyalarin backup'ini alin, sik degisenleri sync et. Degisik lokasyonlardan ulasmak istediginiz dosyalari sync edin, kaybolmasindan, yanlislikla silinmesinden korktugunuz dosyalarin backup'ini alin.

Tamam simdi bu kavramlari iyice ogrendigimize gore :) ben ne icin neler yapiyorum onu anlatayim. Bu yazimda sadece senkronizasyon (sync) stratejilerimden bahsedecegim, bir sonraki yazimda da backup stratejilerimden. Haydi bakalim...

Oncelikle uzerinde calistigim dosyalar, ki bu dosyalar genelde calistigim bilgisayarin desktop'inda oluyorlar. Iste bu dosyalari tum bilgisayarlarimda sync ederek kullaniyorum. Boylelikle isyeri bilgisayarimda (Vaio - Windows) uzerinde calistigim bir dosyaya, cep telefonumdan (Sony - Android) veya tabletten (iPad - iOS) veya evdeki bilgisayarlarimdan (Mac Air ve Mac Mini - MacOS) ulasabiliyor ve calismaya devam edebiliyorum. Peki bunu nasil sagliyorum. Dropbox 'dan aldigim bir free account hal-i hazirda uzerinde calistigim tum dosyalar icin gayet yeterli ve hiztmetten de cok memnunum.

Eveet ben bir yazilimci olduguma gore cogu zaman (kendim icin veya isyeri icin) giderek azalan bir trendde de olsa hala kod yaziyorum. Bu demek oluyor ki, bu yazdigim kodlar bir sekilde versiyonlanarak saklanmalilar, yoksa el emegi goz nuru olan sanat eserlerim (bu konu ile ilgili bir yazim olucak unutturmayin) kaybolur falan, hic olacak is degil. Bunun icin ise Github, Bitbucket, XP Svn ve tabiki sirketin private GIT versiyon kontrol sistemini kullaniyorum.

Fotograf ve videolar en sıkıntılısı, neden mi, cunku binbir turlu yerden fotograf cekilebiliyor ozellikle de Sarp'in fotograflari :) Simdi evdeki Mac Mini direk olarak her daim televizyona bagli durumda dolayisiyla ailecek film, dizi izledigimiz veya fotograflara baktigimiz medya merkezimiz olur kendisi. Iste bu sebepten butun cekilen fotograf ve videolarin bir sekilde ona aktarilmasi en mantiklisi. iOS tabanli oldugu icin esimin iPhone'undan cekilen medyalar ve iPad'ten cekilenler Photo Stream ozelligi ile aninda Mac Mini'ye aktariliyor. Ama fotograf makinasi ile cekilenler ve kendi telefonumdan cektiklerim malesef ancak manuel olarak aktarilmak durumunda :( belki ilerde bu konuda biseyler yaparsam sizinle de paylasirim.

Diger onemli dosya tipi ise muzik dosyalari, onlarin da bir sekilde tum aletler arasinda sync olmasi gerekiyor. Onu da tum muzik arsivimi daha once bahsettigim Google Music'e upload ederek gerceklestiriyorum. 20.000 sarki upload etmek bedava, adamlar daha ne yapsin degil mi?

e-Kitap'larimi ise Kindle uzerinden yonettigim icin kindle uygulamasinin kurulabildigi her aletten kaldigim yerden okumaya devam edebiliyorum. Ve bu kadar aletin icinde en cok sevdigimdir Kindle, herkese cok ama cok tavsiye ederim, e-kitap dunyasina girmek isteyenler icin bu yazi bicilmis kaftan.

Son olarak todo listemi rememberthemilk uzerinde (ucretli hesabim olan mecralardan birisidir), aklima gelen hemen her turlu seyi yani notlarimi ise evernote uzerinde tutarak her an her yerden ulasilabilir kiliyorum.

Iste boyle, backup stratejilerimi de ~~daha sonra paylasacagim~~ bu yazimda paylastim. Takipte olunuz.

Baba Oldum ve Digerleri

noreply@blogger.com (Hakan Saglam) — Tue, 18 Dec 2012 12:49:00 +0000

Uzun zamandir (Agustos'tan beri) blogumla cok ilgilenemedim ama hayatim devam etti tabiki, hem de cok ciddi degisikliklerle devam etti. Sizlerden uzak oldugum zamanlarda bazi yurtdisi gezileri yaptim ve (bana gore) cok ilginc gozlemlerde bulundum ve sizinle paylasmak istedim ama yapamadim. Aklima yazacak onca sey geldi ama toparlamaya zaman bulamadim derken bu gunlere kadar geldik.

Neyse geleyim hayatimdaki ciddi degisikliklere;

Ilki yaklasik 5 yildir calistigim sirketimde, bazi arkadaslarimin kariyerlerine Amerika'da devam etmek istemeleri uzerine yeni bir role (Principal Software Engineer) gectim. Ve bu rolde cok sevdigim arkadasim Lemi ile birlikte, son zamanlarda unuttugum bir his olan, zevkle calismanin, ise severek ve isteyerek gelmenin hazzini tekrar yasadim. Bu benim icin (is yerinde) tekrar hands-on koda geri donmek demekti ve cok guzeldi :)

Coding is Good

Guzeldi diyorum cunku bu da degisti. Belki hatirlarsiniz, aylar once onemli bir is icin Londra'ya gittigimi sizlerle paylasmistim. Iste o onemli is aslinda calistigim sirketteki cok ciddi bir rolun is gorusmesi idi. Ve gorusmeyi o zamanlar yapmis olmamiza ragmen, arada gecen degisik olaylar sonunda sonuclari yeni aciklandi ve yukarida bahsettigim rolde (her ne kadar cok hosuma gitse de) cok uzun kalamadim, ve hep istedigim "Solution Architect" rolune gectim. Rolun tanimi ve icerigi ile sizleri cok sıkmak istemiyorum ama kisaca avrupa genelinde yazilim kararlarini alip, cozumler ureterek bilisim anlaminda sirketin dogrultusunu belirleyen ciddi ve kapsamli bir rol.

Let's go in this way

Son ve en onemli degisiklik ise, basliktan da anlayacaginiz uzere, 20.Mart.2012'de ilk haberini aldigim zamandan 26.Kasim.2012 tarihine kadar heyecanla bekledigim biricik oglumuza kavusmamiz oldu. Ozellikle yaz aylari hep onun hazirligi ile gecti diyebilirim. Calisma odamizi, arka odaya tasiyarak, bebek odasina cevirmeyle basladi hersey. Duvar kagidi, mobilyalar, bebek giysileri, oyuncaklar, biberonlar, alet edavat ve daha sayamadigim en az 100 farkli kalem derken oda tamamen baska bir havaya burundu. Git gide siklasan ve herbirisinde bebegin yuzunu gorememeyle sonuclanan doktor ziyaretlerinde, bebegin gayet saglikli (masallah) bir sekilde gelisimini tamamliyor oldugunu bilmek yeterliydi bizim icin... Bunlarin ustune de hamilelik ve bebek uzerine bolca kitap okuyarak gecirdik bu heycanli bekleyisimizi... Ve bir de son zamanlara Walking Dead sezonlarini da araya sıkıstırdık :)

En nihayetinde zaman geldi ve saglikli bir sekilde 26.Kasim.2012'de aramiza katildi "Sarp" bebek, Allah kendisine uzun, saglikli ve mutlu bir hayat nasip etsin isallah (amin)...

Sarp Bebek

Panik yapmayin, yeni hayat maceralarimi yine buradan paylasiyor olacagim...

Hayati Kolaylastiran Uygulamalar - 2

noreply@blogger.com (Hakan Saglam) — Thu, 09 Aug 2012 12:13:00 +0000

Uzun zaman once ilk kismini yazdigim yazimin devamini getirmek istedim. Gunluk kosusturmada hayatimi kolaylastiran bu minik! uygulamalar, birakin sizinkini de kolaylastirsin ;)

Cloud (Bulut) Uygulamalarindan bahsetmismiydim hatirlayamadim ama Dropbox'tan bahsetmeden bu is tamamlanmis sayilmaz degil mi?

Dropbox - Evraklarinizi, sifrelerinizi, herseylerinizi saklayabileceginiz sizin icin dunyanin bir yerlerinde acilmis bir harici disk olarak dusunebilirsiniz onu. Tabii hal boyle olunca, bir kullanici ismi ve sifresi ile hem isten, hem evden, hem de misafirlikten ve hatta cep telefonunuzdan dosyalariniza istediginiz zaman ulasabiliyorsunuz.

browser wars

Eee artik internetsiz ve browser'siz (bu alanda da Chrome'u tek geciyorum, hala kullanmiyorsaniz kesin bir deneyin derim) bir hayat olmadigina gore soyle en cok kullandigim browser eklentilerinden ve sitelerinden de bahsedeyim...

Gmail - Sirket mailim haricinde kullandigim public mail adresim, tum maillerimi, adres defterimi burada tutuyorum. Maillerdeki thread mantigi ve sade yapisi hemen her isimi halletmemi sagliyor, ayri bir mail client'ina falan ihtiyac duymuyorum. Sadece search fonksiyonunu biraz daha gelistirmeliler bence, duy sesimi Google...

Clearly - Evernote takimindan cikan yine cok yararli bir browser eklentisi. Bilgisayar ekraninizdan bir sey okumak istediginiz de, genelde yaninda kosesinde yanip sonen reklamlar, ordan burdan cikan pop-up ekranlar insanin canini sikabiliyor. Clearly de bu yaraya merhem oluyor. Istediginiz internet sayfasinda tam da okumak istediginiz alani cok guzel ve sizin istediginiz sekilde sunuyor.

Zargan - Yillardir temiz ve sakin arayuzu ile bir numarali ingilizce-turkce-ingilize sozlugum olarak hayatimda etkili bir yeri var.

Divxplanet - Hemen her filmin, dizinin alt yazisinin bulundugu guzide site, cevirmenlerin ellerine saglik diyorum. Gerci Boston Legal'in cevirisini bulamadigimdan ingilizce seyretmistim tum sezonlarini ama galiba simdi onu da cevirmisler.

Evdeki bilgisayarimda kullandigim uygulamarin bazilarindan bahsedeyim biraz da....

uTorrent - Ben indirmiyorum ama (!) torrent indiriyorsaniz bundan daha light olani bulamazsiniz, ustelik bir de android uygulamasi var ki, uzaktan kontrol imkani da veriyor size... Yalniz galiba yeni bir chrome add-on'u varmis o belki daha basit bile olabilir ama hic kullanmadim.

Calibre - Cok sevdigim e-kitap okuyucum Kindle'im icin ordan burdan aldigim, indirdigim kitaplari e-kitaplari dogru formata cevirmemi saglayan guzide uygulama, daha cok ozelligi var ama ben pek kullanmiyorum.

Adium - Tum protokolleri destekleyen cok guzel bir instant messaging uygulamasi. MSN, Gtalk, Yahoo Messenger, Facebook akliniza ne gelirse. Yalniz unutmayin sadece MacOS'ta calisiyor, Windows ortamlarinda denemeyiniz.

10100111000111000111.....

Mesleki acidan kullandigim uygulamalari da kisaca anlatayim. Sikilirsaniz buralari atlayabilirsiniz, anlayisla karsilarim.

Atlassian - Eger yazilim sektorundeyseniz ve hic bir atlassian aracini kullanmiyorsaniz kendinizi sorgulayin derim. Cunku siz isinizi yaparken ihtiyac duydugunuz cevresel ortamlari en iyi sekilde size sunuyor.

JetBrains - Uzak ara en iyi yazilim gelistirme ortamlarini (Java, Ruby, .NET, PHP...) saglayan firmadir kendisi... Hangi dilde isterseniz o dil icin en guzel ortami sagliyor.

XCode - iPhone uygulamari gelistirdigim ortam, cok fazla hayatimi kolaylastirdigini soyelemem ama mecburen kullanmak zorundayim :(

Putty Connection Manager - SSH ile o server'a bu server'a baglantimi sagladigim guzel bir uygulama ama gelistirilmesi durdurulmus durumda, uzucu yani. SSH nedir ilmiyorsaniz bosverin gitsin :)

Bitti, finito derdim ama aslinda simdi bakiyorum da, yeni newism akimi ile birlikte, ayni isi daha iyi veya daha yararli veya daha kolay veya daha farkli veya veya veya bir sekilde yapabilen uygulamalar surekli gelisecek ve hayatimizdaki yerini alacak. Yani kisaca bu yazilarin devami gelir...

Uzaktan Madonna'yi Gordum Sanki

noreply@blogger.com (Hakan Saglam) — Mon, 11 Jun 2012 11:14:00 +0000

Son bir kac gundur, kendimi surekli bu konserden bahsederken, veya bu konserle ilgili bir blog yazisi veyahut da onunla iligli bir haberi izlerken buluyorum. Sonra dedim ki, madem ben de gittim seyrettim bu konseri o zaman ben de eksik kalmayayim da biseyler anlatayim.

Bi kere biletleri boyle aylar oncesinden alinca insan konsere yeteri kadar hazilanamiyormus, onu anlamis olduk. Alacaksin son bir hafta kala, ezberleyeceksin sarkilari sonra gidip cosacaksin gonlunce... Ama dogal olarak biletleri Subat ayinda ciktiginin ikinci gunu almak zorunda kaldik biz. Neyse konsere gelecek olursak, isler yogun, zaman yok su bu derken, "setlist" elime cok gec ulasti, ve o an anladim, bu sarkilarin coguna eslik edemeyecektim. Neyse bari show ve ses iyi olsa diyerek ulastim Telekom Arenaya. (Bir Besiktas taraftari olarak, kabul etmeliyim ki, ulasimi kolay, girisi rahat, goruntusu mukemmel bir stad olmus. Hic mac seyretmedim orda ama guzel olsa gerek..) Ulasim falan rahatti ama organizasyonda ozellikle yiyecek-icecek konusunda ciddi eksiklikler vardi. Yani binlerce insanin gelecegi bu kadar asikarken neden yeteri kadar yiyecek yoktu anlamadim. Neyse gelelim konsere...

Muhtesem bir gorsel show'la basladi konser, agzim acik izledim diyebilirim. Ama seste bir bogukluk var bir turlu iyi bir sekilde alamiyoruz Madonna ablamizin sesini... Baktim duzelecek gibi degil, dedim gelin asagi inelim orda dinlyelim. Bir sekilde indik asagi, daha guzeldi ses ama yine de yeteri kadar guzel degildi bence, hersey guzel stadda ama orda konser olmaz yada tribunden olmaz o is, kulaginiza kupe olsun...

Dedigim gibi gorsel bir solenle acildi konser, ama zannetmeyin ki, sonrasinda devam etmedi. Klip izler gibi izledik konseri inanilmazdi, ben hayatim boyunca boyle bir gorsel konser (evet enteresan bir ifade oldu ama dogru) gormedim. Hele "Gang Bang" sarkisini soylerken izlediklerimiz, gercek bir klipten farksizdi bence, mukemmeldi... Sarki icin ayni seyleri soyleyemecegim malesef, bu konuya gelecegim birazdan.

50 kusur yasindaki, dunya stari hop orada, hop burada hatta ip ustunde, sahnenin altinda, ayakata, yerde heryerde inanilmaz bir enerji ile (paylaback olarak) soyledi sarkilarini... Bu kadar etkilenmemin sebebi sadece kendisi degil muhakkak. Iki onemli faktor var deginmek istedigim, birincisi yanindaki danscilardi, onlarda bu show icin bayagi ter doktuler, sahidim. Ikincisi ise hareketli ve ekranli konser standi ve duvarlari, sarkiya gore, ritme ve danslara gore degisim gostererek bizi kitledi resmen.

Bu kadar gorsel dedik, klip gibi dedik, hopladi zipladi dedik ama hosuma gitmeyen bazi noktalar da vardi elbet... Ozellikle MDNA albumunun turnesi olmasi sebebiyle yeni sarkilarini seslendirdi ablamiz, hem bu sarkilari bilmiyordu cogu insan, hem de bana sorarsaniz guzel de degil bu sarkilar arkadas, kimse kusura bakmasin lutfen. O yuzden kimse, yeteri kadar cosmadi insanlar falan filan demeyin, cosacak degil izlenecek bir konser hazirlamis Madonna hazretleri, tek bir sarki haric "Like A Prayer"...

Velhasil yine olsa yine giderim, ama bu sefer saha icinde olurum orasi kesin. Ve eger bir kere daha olacaksa, eski sarkilarla yada soyle soyleyeyim iyi sarkilarla olsun lutfen, bak nasil konser olur o zaman...

Bir SSH, Iki Port

noreply@blogger.com (Hakan Saglam) — Wed, 30 May 2012 08:31:00 +0000

Daha en basindan soyliyeyim, cogu insan icin bu yazi ciddi anlamda teknik bir yazidir, ama bu konudan anlayanlar icin can sıkıcı bir durumun cozumudur efendim, o bakimdan yazmak istedim.

Sıkıntımız söyle, bir mac'iniz var (Macbook Air, Macbook Pro vs...) ve uzerinde default kurulu gelen SSH Server ve Client'ini cesitli amaclar icin kullaniyorsunuz, simdi bu amaclardan bazilari default portu (22) kullanirken, bazilarinda ise baska bir port kullanmak zorundasiniz. Iste anlatacagim cozum de bu sorun icin: SSH uygulamalarinin ayni anda iki farkli portu birden kullanmasini nasil saglarsiniz?

MacOS icinde tum SSH ayarlari cesitli dosyalara dagilmis durumda (konfigurasyon ve esneklik adina yapilmis zaman icinde karmasikliga gitmis bir durum gibi geldi bana). Kesin daha baska dosyalar da vardir ama simdilik biz sadece ilk iki siradaki ile ilgileniyoruz...

Adim - 1: Ilk yapacagimiz is, ilk siradaki dosyayi (/etc/services) sudo ile acarak uzerinde asagidaki degisiklikleri yapmak. Bu degisikliklerle istedigimiz yeni port'lari eklemis oluyoruz. Bu arada yeni port eklemek degil de sadece port degisikligi yapmak istiyorsaniz, asagidaki eklemeyi yapmak yerine sadece "ssh" servisinin portlarini degistirip 3.adima gecebilirsiniz.

buyutmek icin resme tiklayiniz...

Adim - 2: Evet gorudugunuz uzere, yeni portlari "ssh2" dedigimiz yeni bir servis icin tanimlamis olduk. Simdi yapmamiz gereken son is bu yeni servisin tanimini ikinci siradaki dosyaya (/System/Library/LaunchDaemons/ssh.plist) eklemek. (Dosyayi yine admin olarak sudo ile acmaniz gerekir.)

buyutmek icin resme tiklayiniz...

Adim - 3: Son olarak asagidaki iki terminal komutu ile degisiklikleri yukleminiz yeterli olacaktir. Ama garanti olsun ben bunlarla ugrasamam derseniz, bilgisayariniz yeniden baslattiginiz da amaciniza ulasmis olacaksiniz.

Bitti bu kadar... Afiyet olsun...

Mutlulugu Satin Alin

noreply@blogger.com (Hakan Saglam) — Thu, 24 May 2012 11:08:00 +0000

Gecen gun okudugum bir makale / arastirma [ingilizce], mutluluk uzerine biraz dusunmeme neden oldu. Her ne kadar duygusal ve kurallari olmayan bir durum gibi gorunse de, bu arastirma bilimsel olarak mutlulugun satin alinabilecegini gosteriyor ve bunlari da bir kac baslik altinda topluyor. Ben sizin icin bir kac tanesini (8 taneden 6'sini) kisaca ozetledim, ama detaylar icin kesinlikle siz de okuyun derim.

* Herhangi bir sey satin almak yerine, tecrube satin alin

Gidip kendinize alacaginiz ekstra yeni ayakkabi yerine, hazirda olan ayakkabilarinizdan birisini ayaginiza gecirip annenizi de yaniniza alip sahilde bir gezinti yaptiktan sonra guzel bir cafede yemek yemeniz sizi ayni paraya daha mutlu edecektir. Bu konu ile ilgili daha ileriye gitmek isterseniz...

* Hep kendinize degil baskalarina da yardim edin

Bizler sosyal varliklariz. Sadece hep bana hep bana diyerek hayat gecmez. Tanidigiz veya tanimadiginiz diger insanlara kucuk kucuk yardimlar veya hediyeler almaniz, ve bunu aliskanlik haline getirmeniz sizi zannettiginizden cok daha mutlu bir birey yapacaktir.

* Bir anda toptan harcamak yerine kucuk kucuk harcayin

Insanoglunun en buyuk ozellikleinden birisi ortama ayak uydurmasidir. Hemen herseye alisabilmesi ve zamanla kaniksamasidir. (Bu konuda gayet hos bir film var: Das Experiment ve Hollywood hali: The Experiment) Para harcama konusunda da, ayni durum soz konusu. Tek bir seferde alacaginiz bir kac sey yerine, ayni seyleri pey der pey almak sizi daha mutlu kilacaktir.

* Simdi odeyin, sonra tuketin

Once tuketip sonra odeme yaptigimiz tamamen kredi kartlarina dayanmis su anki ekonomik duzenin aksine, insan onceden odedigi seyleri tuketirken daha mutlu oluyor(mus). Bunun on guzel ornegi yemek sektorunde, karniniz doyduktan sonra odeme yapmak yerine, gercekten acken odemek yapip sonra odeme yapmak insani daha mutlu kiliyor. Hatta bu konuyu Jerry Seinfeld bir bolumde islemisti ama ben bulamadim hangi bolum oldugunu..

* Karsilastirmali alisveristen mumkun mertebe sakinin

Gunumuzde ne alirsak alalim artik onu almadan once muadili baska markalarla (ozellikle internet araciligiyla) karsilastirma yapmadan pesini birakmiyoruz. Diger turlusunde icimiz rahat etmiyor... Evet, bu da yapilan yanlislardan, karsilastirmalar aslinda aldigimiz urunde hic kullanmayacagimiz ozellikler uzerine kurulmus durumda. Yanlis anlasilmasin gerektigi yerde kesinlikle urunleri karsilastirmak bilincli tuketimin kurallarindan ama sirf laf olsun diye yapmayin diyor arastirma :)

* Basina buyruk olmayin, suruyu takip edin

Kisaca soylemek istedigi, diger insanlar biseyleri ne kadar cok begendiyse, sizin de o seyi begeniyor olma ihtimaliniz o kadar coktur. Genelde aykiri olmak (yerine ve zamanina gore) iyidir yada oyle algilanir. Ama diger insanlardan aykiri satin almalarinizin, sizin dusundugunuz kadar sizi mutlu etmeyecegi arastirmalarla kanitlanmis.

Eveeet, iste boyle, ayni paraya daha mutlu olmanin yollari bunlarmis, artik gerisi size kalmis. Guzel bir cumle ile bitiriyorum: "Para sizi mutlu etmiyorsa, bilin ki onu dogru sekilde harcamiyorsunuz."