• 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

104 Neutral

About mauriciocinelli

  • Rank

Personal Information

  • Location
    Santa Catarina, Brasil
  1. [quote name='T e c h l o r d' timestamp='1312217019' post='4843167'] Nope, I don't mean just a in-game UI. I'm developing [i]Tool Games[/i] [i](TOGs)[/i][i], [/i]possibly a new game genre. I wanted to make games not editors! I found a way that I enjoy doing both. Its about presentation and delivery. Nothing written in stone commanding Tools to only be serious. I'm simply blurring the lines a little, is it a Toolbox full of Toys or a Toy-box full of Tools? [/quote] I'm sorry, but I'm not getting what is a Tool Game.... can you please explain in more detail and clearly? [img]http://public.gamedev.net/public/style_emoticons/default/mellow.gif[/img] But if you just invented a new game genre, congratulations!
  2. [quote name='Radikalizm' timestamp='1311940596' post='4842101'] I stand by my point that tools shouldn't have all kinds of whistles and bells which they really don't need [/quote] That's what i think too. Tools need to look and perform professionally. [quote name='T e c h l o r d' timestamp='1311963732' post='4842261'] [quote]I stand by my point that tools shouldn't have all kinds of whistles and bells which they really don't need [/quote] I'm not developing Game Tools, I'm developing [i]Tool Games[/i] [i](TOGs), [/i]featuring a `Bells & Whistles` Toggle Switch. Sometimes we game developers have to think outside-the-(tool)box, LOL. [/quote] Oh, you mean "in-game UI", which is anoooother thing. [img]http://public.gamedev.net/public/style_emoticons/default/laugh.gif[/img] Sure, in-game UI need to be more "fun", as what the users want with a game is indeed having fun or having a UI that matches the game theme
  3. [quote name='EJH' timestamp='1311798454' post='4841283'] [quote name='kunos' timestamp='1311614450' post='4840071']I don't have experience in WPF... every time I tried to use it, it felt slow, cumbersome and unispiring... I just fail to see the point behind it. Forms feels faster and more similar to the way RAD software has been for the last 15 years.. so I stick with Forms...[/quote] ^ Totally agreed on this and I do have WPF experience. WinForms is superior in almost every way imho. Not sure what the point of WPF is either. Is it supposed to be some kind of hybrid WinForms/Flash? In WPF the fonts are not as crisp (not even with ClearType), most of the widgets have less intuitive and/or missing functionality compared to WinForms (even basics like TreeView, ListBox, ComboBox), the widgets are slow with a lot of data, the rendering and responsiveness of WPF is substantially slower, and to me at least, XAML is pretty useless. I have the experience of implementing the exact same graphing/diagramming tool set in both WinForms and WPF. We tried WPF for the latest version just because it was newer and maybe "better". If I could go back I would have never wasted time with WPF. Luckily its only tools and customers will never see them. [/quote] The part about missing functionality is, unfortunately, true. Also integration is a little bit more "annoying" using WPF, for example with XNA, which is what I was trying to do. Then after some days of errors and more errors, i decided to make it with Forms, and things are going, slowly, but going. And i never tried to fill the WPF widgets with data to see its performance.... so at this part I can't say anything
  4. And also Unity has a option to deploy to Web, and the user has only to install the Unity Web Player
  5. [quote name='RobTheBloke' timestamp='1311761848' post='4841037'] [quote name='Mauricio Cinelli' timestamp='1311721654' post='4840870'] By your point of view, yes tools programmers can fuck everything up more than engine guys, but if the engine guys don't make their job right, tools programmers also won't, and probably the engine guys will make the tools guys fix what's wrong..... (not by experience thought, but it's more obvious) [/quote] A good toolset allows quick iteration of gameplay and design concepts. Quick iteration helps you determine the capbilities (and flaws) of the engine underpinning the project. If an art team knows the limits of the tech, they can, and will, design within those limits. (To an extent) it doesn't really matter if the backend is good or not, the designers will still have the tools to make the game fun to play. If the backend is shoddy, you might have slow loading times, the shaders may not be 100% optimal, the maths library could be faster, the models might have to stay relatively low poly, but the game will still be fun to play - and ultimately that is the only metric to determine whether you have succeeded or not. The old adage of 'dont let perfect get in the way of good' applies in spades here.... [/quote] If it can be used, though not 100% optimal, you can revisit later on and tweak. However, if the backend is broken... then no one can work, and the game fails. The best tools/engines are the ones that continuously evolved and still continues to evolve. look at the unreal engine version 1, it didn't have all the capabilities of the current version, but the games were very playable and very enjoying.
  6. [quote name='RobTheBloke' timestamp='1311691673' post='4840560'] I've seen more tools teams fsk up than engine guys. The big problem with tools is that some people assume it *must* be an easier task than the engine, and so the less experienced members of the team are often assigned the task (it's just some buttons right???). The net result is a buggy toolset, that interfaces badly with the engine, is a touch crashtastic, and ultimately affects the art teams productivity. But yeah, it *should* be the tools guys that write the wrappers. It's just an additional sanity check to make sure the engine interface is straightforward to understand and use. If it requires 'that engine' guy to write the wrapper, then I'd start looking very closely at 'that engine' guy, to see if he's actually up to the job at hand. [/quote] Generally when your boss or client come and say "It's just a button there, can you put it there for us?".... [img]http://public.gamedev.net/public/style_emoticons/default/dry.gif[/img] Tools programming jobs are generally overlook by the UIs that are done, which have a very complex code under the hood... By your point of view, yes tools programmers can fuck everything up more than engine guys, but if the engine guys don't make their job right, tools programmers also won't, and probably the engine guys will make the tools guys fix what's wrong..... (not by experience thought, but it's more obvious)
  7. Unity

    Thanks for the resources mate! Also 3DBuzz has some awesome training on Unity 3, and also a MMORPG class that focus on the building of a MMORPG using Unity, however, the latter is for subscribers....
  8. [quote name='Exorph' timestamp='1311695002' post='4840594'] [quote name='Mauricio Cinelli' timestamp='1311691099' post='4840555'] Nice, just make sure you have another flag or something that says that you have already cleared that room, so the trap won't "execute" again, if you die or something.... [/quote] Am I missing something? As far as I can tell, by doing it my way a trap room is only going to execute if you haven't already cleared it. Enter room -> trap is reset and executes -> kill enemies -> doors are opened -> trap flag is removed -> enter again -> room is no longer a trap and nothing happens Enter room -> trap is reset and executes -> die -> return -> trap is reset and executes [/quote] Oh, i see. Your way is fine... i didn't understand you were to REMOVE the flag from the room. guess this way it'll work fine. SOrry for my confusion
  9. [quote name='TTT_Dutch' timestamp='1311691202' post='4840556'] Ok well I can't do the other two because I only have older laptops. Umm what do you mean by software renderer? Ok so I was trying to do this on windows with VC++ and it starts up then says: "Error Missing GL Version". [/quote] guess you found the error.... About the software rendering [url="http://en.wikipedia.org/wiki/Software_rendering"]http://en.wikipedia.org/wiki/Software_rendering[/url]
  10. [quote name='Exorph' timestamp='1311690504' post='4840548'] I think I've come up with a solution that works for me. I use a isTrap-flag for the room. Upon entering such a room, all doors are opened and the triggers are reset. Upon clearing a trap room, the isTrapFlag is set to false, so nothing is reset the next time you enter. So I guess it closely resembles the database idea. Thanks people! [/quote] Nice, just make sure you have another flag or something that says that you have already cleared that room, so the trap won't "execute" again, if you die or something.... Good luck. Hope we could help you.
  11. [quote name='Radikalizm' timestamp='1311642171' post='4840316'] I can agree with this Just to clear things up, this is all purely hypothetical, I'm not facing any of these issues personally, mainly because I'm a lone wolf in the projects I'm working on when it comes to programming, which means all programming work will eventually be done by me (so if I fuck up it'll be just me who has to deal with it ) [/quote] Same here.... I work with web, and only do my "hardcore" programming in my spare time, and alone... [img]http://public.gamedev.net/public/style_emoticons/default/tongue.gif[/img]
  12. if you have a organized team, at least you can blame [s]someone[/s]! the other team if they screw up hehe, just kidding
  13. [quote name='ApochPiQ' timestamp='1311642108' post='4840315'] And of course all of those things can be tested for trivially. Dutch insists, however, that he's already testing for every possible error, so... [/quote] Oh I see, so really there's nothing we can do, if he said this.... hope he finds out what it is
  14. [quote name='ApochPiQ' timestamp='1311641789' post='4840309'] [quote name='TTT_Dutch' timestamp='1311641300' post='4840304'] Ok well I can not do anymore error checking within my program because every single thing that could go wrong is being checked. Is there any other error checking outside of the program that I can do?[/quote] I have a tremendously hard time believing this. Of course, since you refuse to provide any code, I'm not in any position to objectively dispute your claim, so... [/quote] Only things that can be happening is: Not loading libraries Debian with old libraries Code referencing wrong libraries Or some other issue in the code that is perfectly legal in Windows but not in linux EDIT 1 So... test some sample apps and see if you can get GL running. if you can, your code is wrong in the big project, if it's not loading, then you're loading it the wrong way Good luck[img]http://public.gamedev.net/public/style_emoticons/default/laugh.gif[/img]
  15. do you have any way to check if the libraries are loading properly? for example, like using a debugger If you can't, try to make a really simple app that loads are use a tiny feature of it, so you can test if loading is ok or not The black screen keeps black? or it closes?