sdc Pluto
A little busy the past two weeks (Diablo 3 and a lot to do at work), but here?s what I had time to do:
Didn’t get too much done this week, but I cleaned up the minimap:
I also added a dungeon level indicator:
And finally I switched the non-player character to use the same AI engine as the zombies (AngryAnt’s Behave), though with a different behavior tree. So far this just means that the non-player character actually attacks enemies. Woo!
Hopefully I’ll have time to make the inventory management more complete and do a dev diary this weekend. We’ll see.
Not too much time this week: I added a second (simultaneous) character and some more rudimentary UI.
This week I added some rudimentary dungeon generation code to DungeonFodder. You can see what it looks like on YouTube.
EDIT: Eventually I expect to have a certain chance that a level will be a “special” level that’s been made by hand instead of randomly generated. Same for rooms - some of them will be “special” rooms.
There’re a lot of improvements that can be made to this approach - and so far it doesn’t add much content to the rooms, just the infrastructure. Here’s a quick explanation of how it currently works!
Rooms are created as regular 3D Unity GameObjects, complete with scripts and all. Then, the dungeon generation script takes each of these objects, converts their dimensions to a 2D tile-based system and determines where the room has openings for corridors.
Rooms are split into “large” and “small” rooms, so that the engine can produce many small rooms and a couple of large ones, depending on what feel the level should have.
The script then chooses a random number of rooms of each size, based on a range for the level. For each room it wants to place, it picks a random rotation (n * 90°), and places it at a random location in the world. If the location is taken by another room, it starts searching for a free spot outwards from the initial random location.
Large rooms are placed before small rooms, to prevent the fragmentation from getting out of hand. A random “large” room is picked to be the “spawn” room.
Each level has a configured range of “monsters per tile”, like [0.1, 0.4]. For each room, it picks a random number in that range, and multiplies that number with the “square tileage” of the room. It skips the “spawn” room.
Currently, the spawn algorithm is very naïve. There’s also no loot being spawned.
Then, each “opening” in a room is connected by the shortest path to a neighboring room (using an implementation of the A* algorithm), but if a room has more than one “opening” then they are connected to different rooms. We tell our A* to count unpathed tiles as a bit more expensive than pathed tiles, so that paths will get reused.
Finally, each room is connected to the spawn room to ensure that we don’t have any disjoint “sub-dungeons” that aren’t connected to the rest of them. This time we configure our A* to count unpathed tiles as much more (currently 20x) expensive than pathed tiles, to encourage it to not create unneccessary paths.
Feel free to contact me on jorgenpt@gmail.com or ask me here. :-)
This week I’ve been deep in non-visible changes land, working on a dungeon generator. While there’s not any good visible output yet, here’s the other stuff I had time to do this week:
Basic inventory, supports drag, still missing drop (and on-hover descriptions) ^_^
Initial minimap - should probably not render lighting etc, but it works!
Dungeon Fodder update: Not too much time this Sunday, but I added some very rudimentary loot support: Boots of speed +50%!
My aunt Frances passed away recently, more about that here. Frances was a founding member of the Glasnevin Musical Society and many of her great friends are also members. Frances left specific instructions for her mass, and one of the Society friends took over and organized the whole thing, including liaising with the church folks. She was awesome! They sang at the service on Saturday and they were beautiful! I captured some of the sound on my iphone.
Second video of Dungeon Fodder: Path finding, HUD, health, and player death.
EDIT: Found a way to get audio using Soundflower & sox.
EDIT 2: RTP+SDP was somehow garbling the output, new and improved script now uses FIFOs!
Turns out that livecasting your desktop in OS X is surprisingly hard. I found two ways online, none of which satisfied me, so I hunted for my own.
This method, described by Mike Chambers, relied on three separate GUI tools (one of which was required the Adobe Flash Media Live Encoder), consumed all my CPU, and refused to support my 16:10 aspect ratio. Yikes.
One simple app to do everything, but sadly it only supports streaming to Ucast, downscales to somewhere near the resolution of a feature-phone from 2000, and still constantly complains that I don’t have enough bandwidth. You can get the “Pro” version for $200 which gives you “HD Broadcasting” - but no thanks.
So, based on Tyler’s Linux approach, I tried getting something similar working on OS X. It only used ffmpeg, and seemed to work pretty well.
Surprisingly, my researched ended up with the following results:
1. ffmpeg doesn’t support screen grabbing on OS X
1. ffmpeg doesn’t have a single audio input that can read an audio device on OS X (see OpenAL section below)
1. ffmpeg can’t record a web cam on OS X (this would allow me to use CamTwist as an input source)
1. VLC doesn’t support streaming to an RTMP server
1. VLC can’t record from an audio device
1. The only other app that’d stream audio live from an audio device to a fifo or pipe was sox.
Any of these statements might be wrong, so please tell me if you know a way :)
So, the best I could do was have VLC stream the screen over a FIFO to ffmpeg, redirect audio through Soundflower, then use sox to pipe audio to ffmpeg.
Finally, ffmpeg recodes all that data and sends it to the justin.tv RTMP server. Not very simple, but at least it works.
Turns out that this works best if you do no work in VLC other than spew to a FIFO: no encoding or encapsulating. Even using MPEG-TS had issues in this context. Raw video in a dummy mux is passed over the FIFO to ffmpeg, and ffmpeg is allowed to do all the encoding.
In any case, I figured I should share this with the rest of you.
Here’s a modified version of Tyler’s script:
ffmpeg can theoretically record input devices on OS X using OpenAL - which ships with OS X by default. I spent some time trying to get homebrew to build it (patch here), but when I finally got it building I realized it was completely broken. Yay!
In theory, the following two lines should give you audio recording for the ffmpeg command (given your ffmpeg has OpenAL support), but it just crashes the whole thing:
-f openal -i ''
I?ve started sharing some of the generally applicable code I?ve developed for Dungeon Fodder on GitHub. So far: PathMoveable, a path walker (using Unity?s CharacterController) that uses AngryAnt?s Path for pathfinding.
First video of gameplay from my alpha game, Dungeon Fodder.
So far: Very rudimentary AI, health, gibs, zombies and magic missile.
Each of these apps makes transit more efficient or convenient. Together, they can do something almost magical: make transit attractive to urbanites who previously saw owning a car as a necessity.
These apps try to find the best way to reach your destination by combining timetables from multiple transit agencies:
Google Maps[Learn more] shows your current location along with walking, transit, or driving directions. In the iPhone app, you can double-tap the locator button to align the map with the iPhone's compass.
HopStop[iOS | Android] lets you specify whether you prefer trains or buses, and whether you prefer walking or waiting for a transfer. It shows a zoomed-in map for each transfer.
Reroute.it lets you quickly compare modes of transportation before getting directions.
Routesy, Nextime, and Nextbus use real-time transit data to help you make quick decisions on familiar routes. For example, you'll know when to walk to your stop, when to run, and when to wait inside.
A location-based alarm, such as Get Off Now or GPSAlarms, can allow you to nap, read, or work without worrying about missing your stop.
These apps can run in the background and have surprisingly little effect on battery life. They use power-hungry GPS only when cell/wifi location data indicates that you are somewhat close.
One of the biggest advantages of public transportation is being able to get things done while in transit. Some people check email, watch TV shows, or even order from Chipotle using their phones.
I often use time on the train to read articles. Whenever I find myself with too many Wikipedia tabs open, I send them to my phone using the Instapaper or Spool bookmarklet. Sometimes I read books on my phone using the Amazon Kindle app.
The Zipcar app lets you borrow cars from Zipcar locations, while Getaround lets you borrow cars from awesome neighbors.
Or you can pay for a ride using Taxi Magic or Uber.
Some transit authorities recommend apps for their cities: San Francisco, New York, Chicago, Seattle, and Portland, Oregon.
In my next posts, I'll list my ideas for new transit apps and explain how platforms could better support location-aware apps.
To better reflect the content, I am moving all my poker-related work to http://www.pokercentric.com, and you can check that out for all your poker-related needs. This site will be taken down at the end of April then relaunched as a video gaming and tech blog for my own amusement sometime in May. In the meantime, this site will redirect to Pokercentric. Hope you enjoy the new layout!
About a week ago I started playing around with Unity3D, trying to learn the ropes of the engine so that I could start making a game with it. This is that game: Dungeon Fodder.
Dungeon Fodder will be a dungeon crawler, inspired by great games like Nethack, Gauntlet and Cannon Fodder (!). While it’ll be a learning project, I’ll also focus on having my mechanics playable and fun as soon and often as possible.
It’ll be in the third person, hopefully feature a small group of adventurers (like Cannon Fodder), fast paced and action-oriented.
First up: Simple dungeon rendering, camera & control. :-)
