• 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

785 Good

About Dancin_Fool

  • Rank
    Advanced Member

Personal Information

  • Location
  1. I don't think you'll have much luck using google maps for this. Take a look at Open Street Maps instead: https://www.openstreetmap.org/about  I love the idea of games that use real world maps, best of luck to you!
  2. Hey Everyone! I haven't posted a blog entry in a long long time. I've been so busy with work and the kids at home that it's hard to find the time these days to write up an entry. I have been busy though, building costumes, fun projects with my 3d printer like a jukebox and an arcade cabinet. I've also been hard at work on a new programming project, and that project is a tool to aid in the building and designing of costumes. Something like this exists already called Pepakura Designer, but it's more aimed at paper craft models and not so much at actually building costumes and the development was fairly stale with not much for updates to the core functionality. I decided it was time to do something about this and build a new tool myself. I'm using my own c++ framework that I've been developing for the last few years and Awesomium to handle the frontend. Using something like Awesomium for the frontend is great, there's so many samples out there for html that it was pretty easy to cobble together an interface. It will also make it easier if in the future I decide to bring on an artist for UI design, as they won't have to learn a new technology. So my initial attempt was fairly simple, just get a PDO file( the format that pepakura uses ) loading and rendering. I wanted to add the ability to import PDO's as there's a wealth of them available out there and a large community behind them. It was crucial that I have that capability in the tool. So here was my first attempt, just a 3d model( my own Iron Man Mark 3 chest ) and some line rendering for the unfolded patterns. [sharedmedia=gallery:images:6437] The next step was start to add some functional tools. The first ones I implemented were Translate, Rotate, and Cut/Join for the 2d patterns. [sharedmedia=gallery:images:6436] Now that I had some tools in place I wanted to get my own basic unfold algorithm in place so that a user could load up a 3d model and generate their own unfolded patterns from it without needing any external tool. This took me a while to get all the bugs out of it. Even now there's a few lingering things I need to fix up with it. [sharedmedia=gallery:images:6440] Next I did some work on the actual rendering of the 2d patterns. I added a mesh for the geometry, numbers for the edge Ids, and tabs for where the edges need to be glued together. [sharedmedia=gallery:images:6435] Now I was starting to get somewhere. I wanted to get the tool out to people so I could start getting feedback on what people thought. I spent a few months cleaning everything up. I added undo/redo functionality. I hooked up print functionality so users could print out their costumes. I created a file format for saving and loading. I also did a big overhaul to the front end. [sharedmedia=gallery:images:6434] To get ready for the first alpha release I put together a video demoing most of the features I had in the first alpha build. [media][/media] I released the first early alpha last month, and quickly found out that not all versions of Windows are created equal. It crashed on all versions except Windows 7. It took me a while to figure it out but I was trying to access some memory before it had been allocated because of an early resize message from Windows. For whatever reason it seems that on Windows 7 accessing that memory doesn't cause a crash ( though one would think that it should ) and on all other versions of windows it crashes. From trying to figure out that crash I discovered this awesome Microsoft site that has free virtual machines of all the different OS's for testing purposes. http://dev.modern.ie/tools/vms/ So now here I am, here's the two latest screens from the tool. I just added support for textured models, which really bring things to life. I'm working on getting a scalable dummy in the tool that you can mount costume parts on to make scaling easier. Nothing worst than printing out a piece, building it, and finding out it needed to be 5% smaller or bigger. I'm hoping to get another stable alpha build out before the end of the month. [sharedmedia=gallery:images:6438] [sharedmedia=gallery:images:6439] You can find out more about the tool, like download links at the discussion page. https://www.facebook.com/groups/381730342034863/ As well you can follow me on Facebook to see all my latest projects, https://www.facebook.com/TheArmoredGarage I'll try to post more regularly as I continue to develop this tool. Thanks for reading!
  3. From the album Armorsmith

  4. From the album Armorsmith

  5. Yeah I find when a project is getting too complex it's time to take a step back and take a look at the bigger picture.
  6. This is a repost from my external blog http://codingintransit.blogspot.ca Hey Readers, So I mentioned at the end of my last post that I was going to give this One Game a Month thing a go as a sort of New Years resolution to complete more projects. www.onegameamonth.com So here I sit at the end of the month with my first finished project, Asteroid Alan. I present you with a bit of a post mortem on the first project in this series. Premise It's a mash-up of Dig Dug and Asteroids. The idea is to maneouver your ship in behind the asteroids and latch on to mine gems and minerals from the mines. Once you latch on you tap the space bar and the asteroid blows up, leaving a bunch of gems floating? to collect and splitting the asteroid into smaller pieces. You can also fire the latch at the asteroids from in front but it splits the asteroid immediately, doesn't leave any gems, and you don't get as many points so it's in your benefit to manouever behind the asteroid but still leaves you with options if there's an asteroid barreling down on you. Plan of Attack I knew immediately that this idea wasn't going to succeed without some kind of planning. I broke up my schedule into 4 weeks of 5 days since I only work on my projects while I'm on transit. I allocated 2 weeks for coding features, 1 week for art and sound, and 1 week for polish and bug fixing. What Went Right A whole lot went right. Having a schedule for all the pieces that needed to go into the game I knew exactly whether or not I was on track to finish. This helped me on a day by day basis by letting me know if I had the time to spend fleshing out a feature that extra little bit. I'm also really happy with how much this furthered my engine. I've now got the start of a great particle system as well as a basic approach to laying out post process effects. It's also a great feeling to actually finish a project from start to finish. What Went Wrong Not a ton of things went wrong, I'm quite happy with the end result. However there were a few things I wish I had of gotten to. The first and most obvious being the lack of sound in the game. I managed to integrate sound playback into the engine but I didn't leave enough time to scour the internet for sound effects to put into the game. I think on the next go I'll do more research into sound, maybe try out some of those sound generation programs they have for generating 8-bit sounding effects. Another thing that could have gone better is actually sticking closer to the schedule. While the schedule was great for helping me to keep track of where I was, after the second week I kind of started jumping around the schedule I had layed out. As a result my front end kind of fell to the wayside because rather than working on frontend when it was scheduled I just blocked in the flow and moved on to other tasks. This wasn't necessarily a bad thing though, I can't say for certain that I would have gotten everything going as well as it is if I had of dedicated more time to fleshing out the frontend. One last thing that didn't necessarily go wrong but I hadn't accounted for were bugs in my engine. It's funny how many times you hear, "Make games, not engines." it's actually quite true. I had built this complex engine with a bunch of tech demos but when it came time to turn the chunks of code into a real game I ran into quite a few use cases that I just hadn't accounted for. What Needs To Change One thing that I really need to change is how I have my engine layed out. It's currently all in a single visual studio project along with all the source code for all my projects. I have a launcher menu that lets me select what game/tool I want to launch into. As I've been developing this has been great because it allows me to quickly jump between different projects, making sure I don't break anything along the way. This was annoying though when I was trying to get this game ready to release because I had to comment out a ton of the launcher stuff and a few other items that were slowing down the launch. It's also a real pain when I make a low level change because all of the source is in this one project and on my little netbook I can waste a whole commute just compiling. Moving forward I think I'd like to separate out the engine into it's own library and move all my projects into their own project files. This should help with compile times since I'll only be building the code that I'm working on at that time. The Game So I present to you, Asteroid Alan. I think the only requirements are DirectX 9 and a graphics card capable of shader model 3.0. https://www.dropbox.com/s/iub06bqbvppt0hs/AsteroidAlan.zip Controls are: W for thrusters A,D to maneouver left and right Spacebar to fire latch
  7. If you're using the color semantic, try switching it to TexCoord. On certain cards the color gets clamped from 0-1.
  8. This is a repost from my blog http://codingintransit.blogspot.com It's been a long time since my last post! Life has been so busy the last couple of months I just haven't been able to find the time to post. I took a break from the bar game over the month of December. As you readers have probably noticed my attention span for a project usually lasts about a month before I need a change of pace. So as a change I decided to spend some more time on my voxel earth project. Kind of took a step back and decided to get a voxel globe rendering first rather than getting all the height maps loading properly. It should be fairly easy to drop in the height maps though. I've got a nice chunked lod working so each tile subdivides as the camera gets closer and closer to the surface down to about 100 meters. There's a lot of depth issues I need to resolve at that resolution but I'll revisit that down the road. I spent some time on the rendering as well. The atmosphere rendering in particular. I used Sean O'Neils implementation of atmospheric scattering as a starting point and made a few modifications to get more of it running in the pixel shader rather than the vertex shader which gave a smoother result. The big thing that's still missing is to render in HDR and apply some kind of tonemapping. I'd get much better results that way. For now I'm just applying some tonemapping to the end pixel result so that I get a nicer visual range of values. Now that I've got the rendering working there's going to be quite a bit of work on my post processing tool that splits up the DEM's into bite sized chunks to map onto the surface. The work is fairly straight forward but it will take some time to switch everything around. Probably more time than I really want to invest at the moment. Not to worry though, I always come back to projects. Moving forward for the new year I'll be taking a break from these big projects and giving the one game a month competition a try. More to come about that in my next post.
  9. [quote name='CatmanFS' timestamp='1355295048'] I love the idea of papercraft models, maybe someone could write a program for printing 3d models into papercraft format, and vice versa. [/quote] There's a program out there already that does this, it's called Pepakura Designer. It allows a user to import a 3d model of various formats and then unfolds it and generates tabs and edge numbers to aid in construction.
  10. Thank you, glad you liked it!