• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

782 Good

About Xanather

  • Rank

Personal Information

  1.   Thanks for the reply,   I came to the realization that the Play Store is very competitive before I released this game, it was a learning experience all around and next time I will be more critical of what I develop.   In regards to feedback, I just wanted peoples general thoughts on the game & some changes I can make before I started working on my next one. Some idea's I got from my reddit post were "offset the player to be above the touch position" and "improve contrasting colors". Maybe I should've named the title of this thread differently however.   BTW I took maxeuwe's post somewhat lightly, he seems to use a separate account based on his post history.
  2.   It took you two months, and the best you could is make a mouse cursor collecting pluses, with some simple physics added? Sorry, but this is a work of of two days, not two months. There are a few hundred thousands other games at Google Play about adventures of color squares/dots/circles/whatever other geometry figures drawn in MS Paint, and all of them look exactly like your game. Do you really expect somebody to notice and play your game in this ocean of other cheap MS Paint games?   Sorry if my comments sound harsh, but they are honest. You won't go anywhere with projects like these. Maybe for your next project you should make something that won't look like a game for Commodore 64, but at least will be comparable to SNES games quality, maybe. Not sure why I even bother typing this. I know people will keep dumping thousands of these MS Paint games on the Internet and then wonder why nobody plays them. Whatever.     Thanks for the reply.   For starters, I had never developed for Android before, and I used OpenGL directly as a learning experience (I haven't used an engine, excluding JBox2D).   Secondary, your right, it did take me too long for such a simple game (thought I wasn't working on it straight for 2 months, just when I started). Much of the time I spent in the level editor tool since many levels are 2000+ tiles long in height.
  3. Been working on this android game the last 2 months. Just released it today.   It has a basic idea in regards to game-play, and I am looking for feedback.   Check it out :) Google Play: https://play.google.com/store/apps/details?id=com.vironsoftware.sidestep   Youtube Trailer: https://www.youtube.com/watch?v=tqBwpFWRu0o   Thanks.
  4. I remember when I used to work on XNA that I also gave up with trying to have dynamic resizing. I've sinced moved onto SharpDX which has allowed me to customize resizing the way I want. I recommend learning the raw API's once you feel comfortable enough with XNA, they're not as scary to use as it seems.
  5. Thanks Hodgman, considering the limited amounts of Matrix multiplation for 2D spriting I think that may be the best solution.
  6. I am developing a simple 2D spriting engine. I was wondering if it would be a better idea to include matrix modelviewproj transformation data within the vertices themselves (will add an additional parameter to the vertex layout from CPU to GPU vertex shader) or simply use a constant buffer and change that constant buffer for each sprite.   From learning about Direct3D11 I find that you should try to minimze the calls to the GPU. If this is the case wouldn't packing the matrix data for each frame within the vertices themselves be a better idea? or would the extra bandwidth (matrix's cost alot of memory) for the extra parameter be too expensive?
  7.   I just wanted to say thanks for mentioning this! I didn't know such a feature existed within the fxc tool. I had so many questions about the output of shaders and I just answered them all myself (was going to write a long question on gamedev.net).   Goes to show it's sometimes quicker testing things out yourself than asking.   Edit: For others who don't know what I am talking about, it's the /Fc command in fxc.exe.
  8. Thanks for the reply.   I think the default value for the DepthStencilState (even when it's initially null) is to have DepthEnable enabled https://msdn.microsoft.com/en-us/library/windows/desktop/ff476110%28v=vs.85%29.aspx, so maybe I should just create a state object for that and set it to false there too just incase.
  9. Its simple, try and minimize Draw calls, constant buffer updates and vertex/index buffer submissions. I feel like most 2D games are reliant on CPU's these days however since almost every frame you'll need to wait for the CPU to order some sprites for the GPU to draw.   I also feel like for a basic 2D game there only needs to be one constant buffer with one item inside it - which is the Matrix transformation used to render the quad (this would be inside the vertex buffer). The pixel shader needs the texture2d shader resource used for texturing the quads.   Edit: Also try to minimize how often you change the pixel shader's texture2d shader resource - i.e. create a texture alas and/or try to draw quads that use the same texture together.
  10. I was wondering if a depth/stencil buffer is required for Direct3D11 to function correctly - it seems pretty integrated into the pipeline. I will be developing a personal 2D game engine soon and I really have no use for a depth/stencil buffer. I will be using the painters algorithm and multiple render targets to draw everything well enough.   I made a quick test and noticed Direct3D11 seems to run alright without a depth/stencil buffer. Other than not setting up a depth-stencil Texture2D, DepthStencilView and specificing null when assigning rendertargets to the swap chain is there anything else I should inform the state machine about?   Thanks, Xanather
  11. Usually in .net a call to read from the network will block the thread until either the connection dies or data is received. Instead of blocking just check the network buffers each tick to see if anything exists then read from it. (This applies for TCP, but I'm sure you could do it for UDP aswell). I don't feel its necessary to create multiple threads for reading/writing to and from TCP network buffers.
  12. Yeah, thanks, I will probably go down that route, it sounds like a good idea. Never thought about runtime compilation.
  13. Well, primary the ability to create additional NPC's, add items, add spells/abilities, adding tiles, nothing too big that would require large modifications.       I don't want a open source game.   A thought: could runtime code be generated on the spot depending on several XML files containing information about new spells/abilities, etc...? My only issue there would be both sides (client + server) would need to interpret both files differently.
  14. I am developing a 2D sidescroller similar to terraria and starbound, after 3 months I have written my own hard coded "engine" for the game that features lighting, tile management, world management, entity management, networking, input, user interface management, rendering, and some others...   My question is how would a modding API be developed, I have a feeling I am too far down the track for such an easy implementation. I am using C# 5.0 (.net 4.5) with MonoGame. This is also the first time of me having a shot at developing a real game, I still would consider myself "newbie". Since its C# I am leaning towards reflection and importing local libraries, this seems like it would be a security issue however. I do not have much experience with reflection but I am sure I could easily pick it up.   Some technical aspects of that game are: 1. The game is completely server-based, hence at the moment there is no singleplayer mode since start of development has been for multiplayer. 2. Uses TCP for networking. 3. The client and server will be obfuscated, eliminating easy .net decompiled modding. 4. Some part of the game can already be modded only server-side to see client-side effects (even though the client executable was not touched). 5. The server has all authority.   Thoughts?
  15. MonoGame development is very active, Ive completed dropped XNA and am now using solely MonoGame for development. Source: I've commited to the MonoGame github once in a while.