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

Zervoxe

Members
  • Content count

    54
  • Joined

  • Last visited

Community Reputation

1263 Excellent

About Zervoxe

  1. I do not think he ruled out Cryengine,Unreal and Unity, he simply said that he wasn't asking from a AAA perspective. which tend to use these engines but does not exclude them from being mentioned) Also from what I gathered he wasn't asking for an engine to use, he just wants to know what people are using and why/what they find attractive with them.
  2. He is still doing updates for all platforms he supports, thing is now that the platform support have matured it isn't as much hazzle for him anymore, latest updates are actually quite noticable for both desktop platform and mobiles. dated? you mean the editor or the visuals? as has been the case for a while EE lacks somewhat in the shader department still(when it comes to visuals) the extended source pricing back then was quite expensive compared to the new licensing, so yeah that is no longer an issue(although the new one is recurring, it is paid once a year) but still compared to the 1.0 source access cost and 2.0 extended source access costs I'd say it is more than ok. Let's see 2013..that was initial EE2.0 if I remember correctly? if so yes there has been changes around the editor. the pricing model is available on the website.(full source access is available as a subscription as well as the non source) I do not consider the prices to be too steep(it's possible to download the editor and run it for free, although it is a bit limited(not in features but in limitations in things you can have, max object count in your project), a bit too limited according to some people, although I would say it should be enough to test alot of things still).
  3. I am a fellow user from way back, Still using it personally, I love it due to its stability. the latest updates has had quite some optimization passes. Couldn't tell you much directly about the editor as I tend to limit my usage of it quite alot(my projects are mostly based on my own handling so I do not mess around with it) mostly I just do asset import through the editor and thats it.
  4. you use in-game units to calculate bulletspread, using screen would mean you are firing from your eyes instead of the gun. crosshair is just a representation of where the player is aiming, where size of crosshair doesn't affect the spread, it just shows/scales from your accuracy based on values from the gun's current values there is tons of tutorials regarding this matter and I think even if it is a different language and engine you should be able to learn from  them. :)
  5. http://support.lenovo.com/no/en/products/Laptops-and-netbooks/Flex-Series/Flex-10-Notebook-Lenovo?tabName=Downloads&linkTrack=Mast:SubNav:Support:Drivers%20and%20Software|Drivers%20and%20Software&beta=false I see there are Bios updates available(try specifically the 64bit one)(strictly speaking the Bios lacks something).   https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/Special_Interest_Linux/thread-id/6206/page/4
  6. No such thing as 32bit mobo. Depending on the install medium this might have something to do with it, lack of proper drivers.
  7. https://www.community.arm.com/graphics/b/blog/posts/dynamic-soft-shadows-based-on-local-cubemap https://www.assetstore.unity3d.com/en/#!/content/61640   I am curious if this is somewhat related.
  8. I assume you know there is quite a bit of a difference between portals like in the games like Portal and Prey, and Portal Rendering system which is used for a quite different purpose? This does not exclude one from the other to be combined.(or as you rather grossly(I use grossly because I can't think of any scene management system which doesn't allow for this to happen) described it worlds within worlds).
  9. So, first you made the only comparison on how you clipped the scenery according to the portal, now you require it to prove light and shadow as well? you are aware it was impossible for them to develop something which was flat out impossible for hardware to calculate at the time as it was not hardware accelerated(eg it did not benefit from having an insanely powerful GPU?)
  10. the first portal rendering usage in games, didn't even have dared to try using render to texture, that means even something like mirrors was impossible had it not been for the original portal rendering technique used back then. Duke Nukem 3D from 1996 used it. then you also have Marathon from 1994.
  11. Then why not just post this as a personal journal post about you implementing portal rendering? as I see absolutely nothing groundbreaking not already done in lots of other engines or titles.   the reason I have to say its not groundbreaking, is because you seem to think you invented something which looks and acts exactly like a traditional portal rendering engine does. :mellow: We already know it is.  :blink:
  12. you mean like how portals is supposed to work?
  13. Vague topic title made sound important with "!", vague description of a system, mentions an idea and a non described acronym. This makes it very hard to even wonder what this topic is about. :mellow:
  14. This of course is all my subjective opinions, so feel free to disregard it if you will. "I'm not so much experienced programmer on gaming but just know Python well and some C# and JS knowledge. " Just because you know a programming language does not mean you know programming, that being said I do not know your how much experience in actual programming you have.   "please don't advice me game engines'  -Godot- game developing video tutorials what are not theoretical to teach you general logic on game programming most of them show how to clone existing game or teach you how to clone video instructor's game"   Why wouldn't you follow these tutorials? a lot of people would actually suggest you learn by making your own clone of chess,tic tac toe, snakes, tetris or similar games to build up the basic knowledge needed to continue on.   "-don't give me the fish but teach me to fish -" why not have both? Developing a clone is not easy, is it easier as you know what to copy, probably, but you learn ALOT of an engine by seeing the process. after seeing actually code, you can look up their functions and learn what they do and more importantly, why they did it.   It isn't only the code specifically you should look at, but the functions they use, when,how and why. Very important things to learn when learning an engine.(and you will probably trip over and pick up some bad habits and look at your code even possible the next day and facepalm yourself for writing such code)   "Game Engines like Unity, Unreal, Duality, Löve and most last Godot. I'm sure now that gonna continue with Godot and not to change it." This is what most people trying to learn game development do wrong, can't learn one engine, next!, can't learn that, next! and so on. That cycle will continue until you learn to buckle down and try see the similarities instead of the differences of each engine. afterall many engines does things in very similar manners even if their languages differ. Learn by looking at examples of scripts, tiny sample games, alter them, play with them,"taste" them, read the documentation of the functions/classes so that you have a better grasp of all their functions/methods.   I would suggest like Kirlim's suggestion reading about design patterns and programming paradigms.
  15. I am curious, has there been any update regarding this?   I am referring to this some months ago, it would be a well appreciated addition.  http://www.gamedev.net/topic/680460-delayed-calls/