• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

ZeRaW

Members
  • Content count

    212
  • Joined

  • Last visited

Community Reputation

384 Neutral

About ZeRaW

  • Rank
    Member
  1. For a new game, 500$ is not great, it is amazing. You need to work on your user acquisition and retention.   In terms of acquisition, now that you are making 500$, you should put some of that into marketing. There are several channels and facebook native app install is still one of the most successful (but expensive) ones. You can send it for blogs and reviewers for more exposure.   For retention, measure everything, check where and when the users are exiting the game and if there is a way to fix that.     Now to be realistic, assuming you will live and pay your rent from your first game, is not really that feasible. Maybe when you reach your 10-15th game, but it seems the game is on the way of becoming a hit.   Good luck.
  2. A very interesting and inspiring story.   I can relate to some stuff even though I live on the other side of the globe in a messed up little country in the middle east.
  3. Talking about game industry and not desktop or web applications.   If you are writing a game engine, it would be wiser to go as low-level as you can so you can optimize where you can.   But if you are doing a game, you have a different set of requirements and for me: - Language should be high-level enough to make sure you do not spend every minute re-inventing the wheel. - Language should have minimum compile time     The way I see it, taking Unity as an example, the engine itself will always be written in C/C++. In recent years, every one wants to be a game developer, meaning making games not writing engines. Unity offers several flavors for scripting, C# is the best one as it is high level, fast compile time and actually you can understand what you are writing.   I am not aware that anything has changed, it is all the same, the target audience changed.
  4. You are trying to solve a very rare case: - If the user moves from iOS to Android (or vice versa) will he lose his purchas-ables   The short answer: Yes, check top ranking games (Clash royale, ...) They save all user items and score locally. If you sign in with Google Play/Game Center you can save them in case you need to change device (same device type).   The purchasable are re-verified from apple or google side (in case they are non-consumables) and will let you know if you need to give the user these purchases.     So I would say ignore this very rare case.
  5.  The API relies on void* as a way to pass generic structures. Is there a better alternative/pattern? Typedef it to something readable if it going to be used as an API  How to ensure classes that inherit from IApp can only be instantiated through IApp::create<type>() and not directly through the constructor Make the constructor private
  6. Check libgdx: https://libgdx.badlogicgames.com/
  7. If you want to dive into the gameplay and implementation aspect without having to worry about what is going on under the hood I advise you to start with something like Unity.   They already have a lot of video tutorials (here is one: http://unity3d.com/learn/tutorials/projects/survival-shooter-project)   That will make you familiar with what it takes to develop a game when you have a game engine and all the tools. 
  8. Send ACK packets to mark if a client is connected or disconnected.
  9. One of the very few complete articles for UDP. I wish I had access to such resource when I was starting out with networking. It was mainly about a lot of trial and error. Definitely worth the 20$.
  10. Hello,   The ROI for such investment is very low. Unless your game is selling for 10$, then 2500 downloads is a relatively low number.
  11. The stack seems highly scalable. I am not familiar with aws, but could you give some idea about cost? Let's say an estimation if you were to have a very small number of active users (***vs a large number. What would this configuration cost for a 50 daily active users vs 1000 daily active users. I know it might be implementation and API usage dependent but a rough estimate will give a better view for the people interested.       On another note; in my opinion, I have built a lot of cross platform mobile games and apps. At the end of the day, you will be handling iOS and Android API calls in a different matter. My pref. is to go native. If you want a bit of a higher abstraction layer for graphics, use Cocos2D. But still go native. If you are doing the game, the only true cross platform calls are the openGL and game logic ones. That could be built into some kind of re-usable framework. Going native allows to optimise and to adopt new SDK features in an efficient matter. The fear (at least the one I had) of duplicating code or extra time spent "adapting" to another platform will not matter after the first project is done. 
  12. Scaling could be handled if you are connecting to a domain (not by direct IP). You would then change the domain A record if you decide to get another host. Downtime is minimal until DNS refreshes.   Anyways, if you have a large audience and you are actually monitizing well, you should not worry about scaling.   @jwezorek: what iOS game size limit? you mean android. APK size is limited to 50MB! iOS is 2GB.
  13. I am assuming you are sending small packets over TCP. So in time, TCP would be stacking the packets until enough data is available. You should set TCP_NODELAY.   In the last network engine I worked on (general purpose), I had thread dedicated for socket polling, getting the data and transmitting the data message to the game thread.   If you have a turn based game, TCP is fine, but if you need to have a realtime game, you need to consider UDP (http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
  14. The last time i did any socket programming was 5 years ago, but your code would block if there is no data on the socket (freeze) as you said you are using blocking sockets. Ideally you should poll (with select) and wait for data before calling recv.
  15. [quote]2. It depends. What organization, making what, and in what country? How do you think an organization might be hurt by crediting the creators of a game?[/quote] I think it is only fair if I make a small intro about the studio so you can understand my question better. - We are opening a new "studio" inside a well established communication agency in the middle east. We had web development, cgi and design departments that were all merged into one. Of course we did more hiring, interviews, etc. This past year we have been building our teams and so far we have the following, in dev. depart.: - Core Team that has extensive knowledge in several area: Web development, Game Dev., Mobile Development. - Specialized iOS Team for native iOS applications. - .Net team building a publishing platform [media, etc..] I am leading the dev. department due to my experience in technically managing dev. teams across different behaviors. I am afraid that when we start rolling out our products, we would have the same Atari/Activision. This is not only a concern for the team, but also a personal concern. So my suggestion was to actually credit people, until we do have a more "financial" crediting system available. As we are still new the "financial" rewards are still being discovered. The reply from management is that "crediting" individuals would lead to favoring "individuals" over favoring teams, so we should promote team work instead. what do you think?