• 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

169 Neutral

About runonthespot

  • Rank
  1. "should games be considered art"  - your best bet is to narrow down the question.  If you mean "all games" then I'd argue no.  It's not difficult in fact, to argue that most games "contain" art, rather than are art themselves (is a gallery art?).  I liked the quote "Games will eventually subsume all other forms of media" - not sure I agree, but I think it hints as to what games ultimately are: A container.  A medium.  A medium in which certainly art can be produced, but ultimately a superset of what we might traditionally think of as art.   This is of course IMHO.  Your mileage may vary.
  2. I'm really into Unity, but I think this guy's talk goes quite a bit further.  Exposing properties in the inspector is one thing, but every time I update actual code, I find I have to restart.  A cursory google showed this http://forum.unity3d.com/threads/195537-Livity-The-Live-Coding-Tool-for-Unity which looks interesting :)    Anyway, a diversion now from your task- good luck finding the right idea!
  3. Maybe a little too specialist/tricky, but one area that is lacking in my view is the gulf between coding and stuff happening on a screen.   Take a look at this talk: https://vimeo.com/36579366   The leap between immediately seeing the results of what you're coding versus the current "make changes (based on your best internal understanding of a program) and iterate" is exactly where I think things should be heading.   I'm a reasonable coder so it's less of a barrier for me, but this sort of tool that facilitates creative without bogging it down in the technical details too much, is amazing.
  4. If you're in Unity (sounds like it), there's actually something that does this on the asset store that works pretty well   https://www.assetstore.unity3d.com/#/content/4341   At $10, it's a steal, works well, covers physics and even sound... 
  5. Depends on the game.  COD does have player colliders.  Some MMOs (like warcraft) have absolutely no player collisions, so multiple people can occupy the same space. In the former it allegedly creates tactical play (blocking a doorway), and the latter prevents griefing (big groups of people making the market place unreachable because they crowd around the entrance).   In terms of implementation, typically you have separate collider geometry that goes along with your player geometry.  Usually it's less complex because it's only to detect if something is colliding with it, which doesn't need to be as detailed as the geometry that shows the wrinkles in your player's clothing.  This would usually all be handled by a physics engine- Bullet/Havok/Physx etc.   In a demo fps from a game engine, it could be as simple as a capsule shape representing the player.  The more complex the geometry, the harder/slower it is for the game engine to use it, so it's typically a mix of primitive shapes to cover the main areas of the body, probably more detailed geometry on the scene itself, usually excluding stuff like plants. 
  6. There's always Unity (noting that the next version out in a month or two includes native 2d tools).   Nice thing about Unity is that you can run your game on just about anything.
  7. Grab free Unity3d (www.unity3d.com), and start in unityscript / js (move to c# when you feel more confident).  Hang around the unity forums and use their questions and answers to answer your initial questions, and start following devs on twitter. :)
  8. +1 Unity3d.  Also a programmer background (12+ years), language independent.  Scene view is almost optional, but mostly it just spares you the grind of managing basic views. I love it most because of the documentation.  Every part of the API has a page and a good C# example of how to use it.  That factor alone makes it programmer easy-mode.
  9. Okay, let me qualify:   1 to 1 scene translation from Max to some game engine cannot be achieved naively.  You have to understand all the ins and outs of the shaders, and basically design the scene in Max with the game in mind and with a thorough understanding of the rendering engine's capabilities to a deep level.  The op's difficulty in getting something to look the same in Unity as in Max highlights this disjunct.   Maybe not 10 people, but a beginner, one person expecting to achieve CryEngine rendering fidelity- is obviously not very realistic.   I think asking the question is great though, as it opens up the debate and helps establish the sort of work involved.
  10. Right, so, your problem stated is "My model doesn't look as nice in free game engines as it does in my modeller".   The solution to this is not to write your own rendering engine, it's to get to know the tools better.   Unity for example can look every bit as good as any other engine.  It's all about understanding the tool.   A default shader on an object dropped into the scene in Unity is not going to look that great.  To make a model look good, you need   -Pick a model that is appropriately set up for a game (taking into account number of polys, and setting up good default textures, spec maps, bump maps etc. -Pick the right shader (Maybe cryengine chooses a prettier default shader... which doesn't necessarily make it the better choice.) -Adjust textures to be appropriately sized and not too compressed -Employ antialiasing (again, in Unity, probably not on by default) -Light it properly.   In my view, work with any of those free tools, compose a complete scene, look at it objectively and get feedback on how you can improve it and basically iterate your skills.  It's not ever going to be a 1 to 1 translation from 3ds Max or Maya.  Also, think practically about how likely it is that one person will produce cryengine quality rendering, when it's taken a team of 10+ 4 or 5 years of full time work to reach that level.   By all means though, build your own rendering engine as a means to improve your understanding of the existing ones, or just as a learning exercise, because the more you know, the better use you can make of the ample resources out there.   Good luck mate
  11. Call me cynical, but to make money in the game industry it appears that you're either an indie and get lucky, or you run a studio, pay those sorts of low wages, and get lucky with a more complex title.  This seems in line with the risk/reward.  To be able to afford to hire someone and provide a stable income to them, the company owner assumes a lot of risk (especially in game dev which is so hit-driven) and to some extent shields the employee from that risk.  Subsequently, the reward is generally skewed towards the person who has their cash on the line.  Typically the employee risks losing their job (not great, but you can always get another job) whereas the business owner risks their invested capital. It sucks, but that's how it works.   I think finance (esp if you're a mathematically inclined, capable of becoming a quant) is usually the best paid, and from what I've seen, the hours aren't as bad as game development can be.  "Crunch" doesn't really exist- although the core hours can be longer than non-finance tech jobs.  The flip side is that the work is not that interesting compared to how working on a game can be.     Regarding UK and labour laws, it's pretty easy to get someone to agree to waive the 50 hour work week. It's voluntary, ofc, but try get away with fewer hours than your colleagues and you'll know it's never easy and seldom works out well for you in the long term.
  12. Oh, and in terms of your experience base, Unity is a great place to start learning. The good thing with engines is they're not bottom-up, they're top down. By that I mean, you get to start with a bunch of functional bits, and then start delving deeper into them as you learn more. So in a more traditional environment or building your own engine, you'd have to learn how meshes are organised, how to draw them on the GPU, how to write shaders, how all that basic stuff works, long before you can even draw a basic cube. This way round, you get to draw a cube (drag and drop practically) and then via c# and the Unity API, you can start looking deeper into it- playing with the array of vertices, tweak existing shaders. More importantly, you don't have to worry as much about the low-level stuff (if you don't want to), and can get straight on with the higher level stuff of actually writing games.
  13. I picked it up about 2 years ago, coming from a c# programming background. If you know C#, then Unity is really easy, user friendly and a lot of fun. In terms of producing a full blown indy game- you can absolutely do it in Unity free. Things only "obviously look like" unity because of the splash screen You do eventually find yourself wanting the pro features- I think the one feature that eventually pushed me over the edge into pro was the very detailed profiling tool that pro comes with- you can literally see which methods are eating the most cycles, etc. Unity tends to favour component based rather than object oriented architecture- basically it makes things a lot easier when developing games and is fairly broadly adopted methodology in gamedev. The community though is what really sets Unity apart- both in terms of helpful people on the Unity forums, Unity answers, and Twitter etc. Have fun! Mike @runonthespot
  14. Unity

    [quote name='6677' timestamp='1348501636' post='4983250']Right now I would play with unity basic on PC not android. Reason being that your spending $400 on the license without one crucial piece of information, will unity play nicely with the ouya. [/quote] Unity are actually a launch partner for Ouya, a bigger risk is whether Ouya makes it or not and that looks okay at the moment. [url="http://ouyagamer.blogspot.co.uk/2012/07/what-developers-have-said-about-ouya.html"]http://ouyagamer.blogspot.co.uk/2012/07/what-developers-have-said-about-ouya.html[/url] Mike @runonthespot
  15. Unity

    Build in Unity basic until you hit a limit, then look at options regarding pro. In my experience basic will do 99% of what you want. Missing features are: -Rendertextures (which are probably in most cases too heavy for regular mobile use) -Ability to Load scenes asynchronously (this mostly means you have to live with "waiting to load" screens between scenes -Splash screen- you have to live with Unity's -Shadows. (Which will only work on mobile from Unity 4 anyway). -Profiling. IMHO, Profiling is the hardest thing to live without, but you can always go old school and Debug.Log, do breakpoints for debugging, and time stuff yourself. Oh, and it's not a better renderer on pro - it's the same one. They just disable certain low level features like rendertextures, raw GL access (opening that up in Unity 4), being able to add reverb to sound, that sort of thing. The sort of stuff you're mostly only going to need if you're a pro, looking to implement special features. Good luck with it. Mike @runonthespot