Dancin_Fool

Members
  • Content count

    510
  • Joined

  • Last visited

Community Reputation

785 Good

About Dancin_Fool

  • Rank
    Advanced Member

Personal Information

  • Interests
    Programming
  1. Idea for a GoogleMaps Strategy Game

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

    Screenshots from my costume development tool Armorsmith.
  4. 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.
  5. One Game A Month - Asteroid Alan

    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
  6. Vertex Shader Clamps 0-1... Need float!

    If you're using the color semantic, try switching it to TexCoord. On certain cards the color gets clamped from 0-1.
  7. Earth Cubed

    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.
  8. Blender vs Papercraft

    [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.
  9. Fun With Behaviour Trees

    Thank you, glad you liked it!
  10. Fun With Behaviour Trees

    Thanks for the tip, I was definitely planning on doing something like that when I get to that point. I guess saying that each ability is it's own tree isn't quite true. My plan is to evaluate a set of needs prior to trying to execute any requests which will work quite similar to what you laid out. My background is in rendering so it's been interesting reading up on all the AI stuff.
  11. Fun With Behaviour Trees

    This is a repost from my external blog http://codingintransit.blogspot.ca Hey readers, the last two weeks I've been working on game resource management and progressing on my job system. Job System My initial plan for the job system is essentially that every job has a set of abilities. These abilities can be learned by having that job assigned. The user can issue requests which need to be executed but not directly use the abilities. I iterate over all the character looking for a character that has an ability which can execute the request. Initially I implemented the abilities as a chain of actions. This worked good for my basic needs, my first ability being a build item ability, which consisted of an action chain with a move action and a build item action. This worked but then I started looking at resource management( like using resources to build something, not like in game assets ) and quickly realized that my simple chain of actions was not going to get the job done. Behaviour Trees What I decided to do was to make each ability it's own Behaviour Tree. This way I can define very detailed behaviour for how each ability will work. For example my initial flow for the build ability is: Check to see if character is holding construction resource If they are .....Check to see if character is in range of the item to build .....If they are .........Start using resources to build item ....If they aren't ........Move towards build area If they aren't ....Check to see if resources available on map ....If there is ........Check to see if character is in range of resource ........If they are ............Pick up as much resources as character can carry ........If they aren't ............Move towards closest resource pile ....If there isn't ........Fail out job can't be completed right now. If the job can't be completed it's unbound from the character ability and returned to the bottom of the command queue. Actions and Decisions The way I've gone about implementing this is to set up two templated classes, Action and Decision. They both take a templated type which has the implementation for that type of action or decision. Decisions are designed to be the logic which decides which path to take in the tree. Actions are designed to be small pieces of logic which are at the end of a chain of decisions. This is all then linked together with fast delegates. Every decision has a pass, and a fail delegate. Decisions and actions then have a function for get a delegate instance which can be hooked into the pass or the fail. Abilities These behaviour trees are then assigned to an ability. Currently the only implemented ability is the build ability. The idea is that every job has a number of abilities that can be used by the character that has that job equipped. For example the build ability is a part of the Handyman job. The user doesn't actually control these abilities. What they do is generate a request, so The user chooses a tile they want to build. They generate a build request. This request goes into a global request queue that the characters have access to. On the character update if they aren't already fulfilling a request they will check the request queue and see if any of their abilities can be used to perform a request. If an ability can be used, that ability is bound to the request and the character can start performing the request. When the request is completed or can no longer be executed the ability is unbound and the request is deleted. I have a video demoing the evaluation of the build ability. The blue tiles are spots where I've laid down a build request and the crate in the corner is a resource crate that contains some construction resources. Apologies for the frame rate. I recorded it on my mobile dev machine, a Toshiba Netbook, so the recording software taxed the system a bit. ?
  12. I Love This Bar

    This is a repost from my external blog http://codingintransit.blogspot.ca Holy smokes its been a long time since my last blog post. I've kind of switched gears in my codebase and I wanted to have something to show before I wrote up my next post. For the last year or so I've really been concentrating on getting a lot of the core components I needed to write a game at the level I'm used to from working on games professionally. After finishing most of the core front end code I finally felt like I had enough blocked out that I could start to write a game. So I pulled the trigger and got down to work. The game I'm working on takes a lot from simulation heavy games like towns or gnomoria which both draw a lot from dwarf fortress, a game which I've read a lot about but never played. This game I'm building differs a fair bit from those games though in that I'm not trying to simulate a medieval world, what I'm hoping to simulate is a bar/night club. I spent a lot of my youth bar hopping and I feel there's a lot of material that can be pulled from that environment and translated to a really fun game.The basic premise is that you start off with 4 characters and an empty lot and you have to assign jobs to your characters, build up a bar, get patrons, build up a regular clientel and just try to have the best bar in town. I've done some research into what's out there but most of what's already out there just feels like farmville in a bar environment. That is not what I want to build, what I want to build is something for more core gamers with lots of different jobs to master, experience building, stats to track. I want to create an environment that feels somewhat alive. So far I have a small lot working, with characters that respond to commands. Currently the only "job" I've implemented is "The Handyman" which will be responsible for construction in the game. The characters are able to build walls and that's about it. Over the course of the next year I'm hoping to crank out something that's a lot of fun to play and filled with lots of quirky humor. I'll try to be better about the weekly updates. In the mean time here's a few screenshots from my progress. Also all art is just placeholder.
  13. Game UI

    [quote name='6677' timestamp='1346448377' post='4975231'] Almost universally each engine provides its own GUI libraries so no game companies don't use 3rd part UI libraries. [/quote] Extremely untrue, a lot of companies use scaleform or their own flash interpreter for their UI. There are also a few other 3rd party frontend options out there.
  14. Which Animation software

    [quote name='Serapth' timestamp='1345606511' post='4972059'] You think Max's interface is good??????? Really? It's full of a decade of clutter and was kinda clunky back then! Of all the things to praise Max for, UI is certainly not one of them. [/quote] I couldn't disagree more. While it might be a bit cluttered I find everything is fairly easy to find and everything is where it would make sense. I've had to switch to Maya for a project and it just felt like everything was the opposite of what I would expect it to be. Now maybe that's because I'm used to Max but it seemed like if you didn't know the keyboard shortcut for something in Maya you were hooped.
  15. Quest for an Asset Viewer

    This is a repost from my external blog http://codingintransit.blogspot.ca Week 1 What a tough 2 week sprint! The first task to pick off was getting screen saving and loading working. This was actually really easy to get going because serialization was built into my sprocket system. So in order to save and load all I had to do was serialize out the sprocket data to xml and then for loading I just had to write some code to place the loaded data into the right containers. I also ported over the code for throwing up the save/load dialogs. I kinda cheated when I originally setup the save/load dialogs. I just call the default win32 dialogs rather than create my own dialogs. I neatly packaged it up in my platform code so it should be easy to abstract it out when I do eventually get the code running cross-platform. The next big thing was fixing the broken window drag functionality. I had a really tough time for this one for stupid reasons. It made for a really bad morning. Basically the problem was that all my mouse handling code was in local space. This works great for some things but when you're trying to move an object and the local space is changing everytime you move the object it creates some serious jitter! I didn't have a good way to expose the screen space deltas which is what I needed to move things properly. What I wound up having to do was calculate the delta based on the parent's coordinate space. I can't help but feel that's going to bite me down the road but for now the mouse drag is actually working better than before I started refactoring the UI system. Once drag was working I was able to hook up the scale and translate buttons in the gizmo I created for manipulating UI Elements. I decided to leave rotation alone for now. Currently my UIClickable sprocket doesn't take into account rotation. I don't imagine it'd be a tough change, I already have a transformation matrix, it's just that I'm only using the translation element of it. Still I know it's going to be a lot more complicated then just multiplying by a rotation matrix. I also spent some time just getting all the UI elements working with the UI Editor. While I was mucking around with that I needed to get arrays working with the protoform editor for certain create params. I managed to get them working the only problem is that they only work for simple types. So the problem is that I'm already using comma separated lists for the complicated types like Float3 which take multiple parameters for initialization and the way I'm parsing arrays is a comma separated list. This shouldn't be too tough to clean up in the future, just use brackets or something to separate items between commas. Another big thing for this week was building a better way of viewing loaded assets as well as providing a means to select what textures to use in a UI element. The old way to select a texture for an element was to open up the xml package, check what I had set the id for on that particular asset and then type that id into the texture field in the protoform editor. I was about to start laying out the components in code when I realized this was a perfect test case for the editor! I always find when I actually start using a tool I find all sorts of bugs and come up with new feature ideas. The first bug/problem I ran into was that objects sorted in the order that they were placed. This was no good, I needed to be able to control the layering. For a simple solution to this problem I decided to use the z value I had been ignoring up until this point to sort the objects. I wrote some code that does a sort whenever an objects z value changed. So once I had the sorting issue worked out I set about creating the asset entry ui element. This was easy, lay out a UISprite background, UISprite for a thumbnail placeholder and a UIText for the asset name and I was done. Then I realized that I had no way to load the object up and actually hook some code into it to replace the placeholder elements. I decided that the best thing to do was just start pounding out some code and see how it feels. I had the objects loaded into a UIContainer object and set up some code so I could clone that container so that I could create multiple objects using that template. I set up a UIAssetViewer class that held a bunch of these containers and did the logic for swapping out the placeholders. It works but I think it still needs some refinement. Week 2 In the second week I managed to get the asset panels loaded and populating a UI container. There was another big cleanup operation, I needed to get scroll bars fixed up and switch my window class to use the UIComponentContainer for storing all the objects parented to it. This wasn't too bad of a change it was mostly copy and paste with a few little fix ups. The scroll bar on the other hand..... I spent the majority of the week working on getting this damn scroll bar working. Funny thing is it's still not working properly. The big problem was that I was trying to debug something that was a few layers deep. Getting all the math working properly was just turning out to be a huge pain. I managed to get something kind of working and that's going to have to do for now. The way it works is that it's designed to just move the components in the container around. It seems easy enough but for some reason I just couldn't get the math right for the life of me. I think it's one of those silly things where if I sit down and draw it out on paper it's going to become painfully obvious where the problem is coming from. I also spent a little bit of time on cleanup. I cleaned up how I was calculating a lot of my element positions so that it's more data driven. This will make reskinning my UI elements a breeze. As it stood before I would had to have adjusted a lot of math but now it should just work. [font=inherit][/font] [size=2]WIP shot while I was getting the dragging working. [font=inherit][/font] [size=2]Showing off a few of the different UI elements. [font=inherit][/font] [size=2]First shot of the Asset Viewer working. [font=inherit][/font] [size=2] Adjusted the dimensions a bit to something that fit better on screen. [font=inherit][/font] [size=2] Showing off the scaled down UI. It makes better use of space but kind of loses the pixellated look I liked.