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

Jotaf

Members
  • Content count

    682
  • Joined

  • Last visited

Community Reputation

280 Neutral

About Jotaf

  • Rank
    Advanced Member
  1. Good advice, and always worth repeating since someone relatively new wasn't here the previous times to hear it :) BTW, there's one aspect of your journal that's a bit annoying: the text goes waaaay past the width of the screen, so every line I have to scroll left and right. The width of my screen is 1440 friggin pixels!! It's not a crummy netbook or anything. Lately, I either copy the text to Word to read it, or don't read the entry at all... I don't want to be rude, but if you could please try to work that out, I'd really appreciate it :)
  2. Impressive system :) Also, the quality of those screenshots is amazing! Congrats!
  3. Dude, this is freaking hilarious! It looks really fun :D
  4. Wow, that looks incredible! Somehow I never get tired of space shooters. A few days back I was on a spree and downloaded like 5 of them :P BTW the canyon there looks great, it really sets it apart from other shooters! And good tip on the low-res buffer for particles too :)
  5. Personally I like it, coloring the top part has a tendency of making it look like a little playhouse, like you're peeking up the top, while black is pretty discreet and can be interpreted as a shadow. The screenshot looks so cool! You really have to inject some simple gameplay there and release a very very early alpha :)
  6. This "presentation" reminded me of Krusty the Clown unveiling the new Itchy & Scratchy show... "1969: the Man lands on the Moon. 1970: the Man lands on the Moon again. Then for a while nothing else happened. Now we proudly present..." Looking forward to new juicy info on the upcoming game :D
  7. Good read, and your project sounds really interesting! The issues you pointed out in the first post are all true and it's refreshing to see someone approach the problem like that. May I suggest that you continue "diving in" to reach the first lab experience soon? I feel that it really helps with big projects like this :)
  8. I can already see it morphing into a Gundam!! Please, oh please give us a shiny new shooter to play, will ya? :) BTW how was the distorted map generated?
  9. Congrats on the new job, I hope you still make mad progress on the SENG prototype though :) Is it just me or the journals have been a bit quiet, in terms of comments? There was a time, one or two years back, when this thing was bubbling! Anyway just to say I always enjoyed your journal so I thought I'd drop by a few words :P
  10. Well, I'd love to show an example but it happens to be highly coupled with my game. In my other component designs I could show you the "add_component" function, and all that; but this system doesn't have any functions at all. What I described is really all there is to it. It's not something you code, it's more something... you just use. Like it was there all along :) Hm, it seems to me like you went a bit overboard with the design (I did it too in the first version). It's easy to define components for everything, but you should always think long and hard if breaking them down so much is really needed. Realistically, when are you going to need an object with position but no mass, or the other way around? If it's immovable, just assign a special value to the mass, or have a flag for that. Actually, I decided against having a position component. Since it's used so often, all objects have it. Yes, when an item is in the inventory its position is unused; but that shouldn't bother anyone. Don't be afraid to make decisions like that, or you'll over-complicate. For instance, there can be a component that means an object can be carried by the player, it can be empty or have values like weight and size; or a component that makes an object behave like a monster, with tons of AI functions. Would it be wise to break down the big AI component into different components? Maybe. But until I need to, I won't do that, or risk devolving my game into a huge, perfect, inter-connected, non-working system. (Until I need to.)
  11. Cool! Anyway, you need to make particles check for other particles nearby and have a "pressure" proportional to number of particles; randomly displace the particle proportionally to the pressure, that should do it. The problem is that many particles accumulate in the same spot. They could form a basin, fill up and eventually spill to another basin; the method I described could accomplish that with a couple lines of code :)
  12. My hair grew longer and I started riding horses shirtless in Scotland after I implemented my first components system. For the record, my latest system is lighter than all the others. It's in python. It goes like this. An object has a MAP of components. They're mapped by type. I ask an object for a component like this: if Health in object.components: object.components[Health].hp += 5. Type validation comes for free, and I didn't write a single function to handle it. Component base class (the only base class ever) defines default functions that some components might not need (for ease). One default property is a pointer to the owner object, so components can directly communicate with other components in the same object. Event dispatching is as simple as a list, like drop_notify. Add a listener: drop_notify.append(obj.listener_func) (bound methods are fun). Call all listeners: for func in drop_notify: func(). Again, I didn't write a single function for the system. That's it. I practically didn't write any code at all for it to start working!
  13. The image loaded fine here :P What do you mean the cogs didn't work out? Weren't they just some objects you were supposed to pick up and put in specific places? Just asking :)
  14. That progress image is like "spot the differences" times 10 :P Awesome job mate. My favorites are the last two, but I wasn't so critical on the others until your comments pointed out what you thought was wrong with them.
  15. Great to continue hearing progress :) BTW it's amazing what you pixel artists can do with MS Paint! Congrats!!