Jabber

Skype

Steam

Location

Interests

Biography

Location

Interests

Occupation

Favorite Games

Announcing the latest Dan And Ben game: Lair Of The Clockwork God. We just announced at Rezzed and it was very exciting!
Pleeeease wishlist it on Steam if you have a sec, it really helps.
Announcement trailer:
Exclusive Eurogamer reveal article here: https://www.eurogamer.net/articles/2019-04-03-swindle-devs-ben-and-dan-adventures-will-continue-in-new-game-lair-of-the-clockwork-god

Greetings all!
I am a longtime fan of Idle Thumbs, video games, and gamer culture. As such, it has been a dream of mine to make games of my own, and with this current Wizard Jam, I'm planning to do my best to make that dream a reality.
Currently, I'm designing a 2D platformer based around the Idle Thumbs episode titled "Real Slyboots," in which you traverse a series of levels in search of the real Slyboots, encountering all sorts of other boots along the way.
The ideal game I'm imagining is probably far more than a first-time developer like myself will be able to complete within the two weeks of the jam, but more than anything I'm aiming to get experience developing, and I'll be cataloging that experience on this thread.
I'm using GameMaker (which I've gotten little use out of other than casual goofing around) as an engine, and am creating art assets by hand with pen and paper. Finalized drawings will then be photographed on my iPhone and sent to my horribly outdated laptop, at which point I'll clean, tweak, and color them (using Paint.NET). Obviously I recognize that there are more efficient ways of handling asset work, but I find this process to allow for quick transitions between concept -> creation -> correction -> implementation.
In my parting words, I'd like to say that advice and criticism alike are welcome, and that I'm both excited to take part in my first jam as well as eager to witness the fruits of everyone else's labors. Thank you and good luck!

Did you ever wish you could rewind time, a dev log
----Released! http://panzorfork.itch.io/rewind
---A note about the dashes at the beginning of lines: '-' denotes the comment pass number that the comment represents. (E.X. '---' denotes the third comment pass, '--' the second, '-' the first, etc.) ----You'll work it out. You can do it, you're smart (pronounced with a Boston accent). -Hi, I wrote the first draft of this about a week ago, so things have changed, lessons have been learned, clones have been made, and clones have been destroyed. -I'm going to read through this and comment about each section. -Let's go time travelling! --It's me, from the current present. I failed to post this dev log again, so what you're about to read is an exercise in document time travelling. --I'll try to keep formatting distinct for each time period the text represents, but things are going to get confusing... --I've been trying to stay as minimally invasive of the past text (besides typos, light formatting etc). ----So here we are, the final comment pass, the end of the jam, and the game is finished. In the spirit of things, how about we start at the end, and do something of a post-mortem (if you want context, I'd suggest reading this document a section at a time, and come back to this post-mortem, or don't - it'll be odd either way)? I had a lot plans for this game, inspired in part by the 2 week timeline of the jam, but not all of them came to pass:
Rewind mechanic!
"WereDunkin'" backstory for the game.
Dunkin' based gameplay in which you try and avoid coffee zombies.
Galcon-like Dunkin' Donuts themed game, in which there are periodic rounds during which you can reorganize your Dunkin' Donuts locations (aka a double blind portion of time in Galcon during which you get to move your planets).
Ghost dad
"Falling platforms" or a "limited runway" level.
Overzealous AI buddy, facilitating use of rewind
Enemies
----Here's what ended up in the game:
Rewind mechanic!
Ghost dad
"Falling platforms" or a "limited runway" level.
Overzealous AI buddy, facilitating use of rewind
Meteors!
----"Known shippables":
While the meteors hit their targets perfectly fine, they seem to either continue to live or don't properly track. After a meteor hits, and time is rewound, the meteor will rewind with the correct amount of time, but it'll be beyond the terrain... This doesn't create much of a gameplay impact, so I'm going to let it slide.
Your AI buddies will get stuck on the terrain while falling to their deaths sometimes. I'm ok with this, just rewind
----"Time to make the donuts", or not. So obviously, Dunkin' Donuts is out. I came up with the "WereDunkin'" theme too far in to pivot (or so I thought), and was still struggling to get the rewind mechanic working at the time. I really do like the idea of a Rampart meets Galcon game, and might explore it in the future. I'm glad I stuck with the 2D platformer gameplay, as it allowed for 2 things: a low effort terrain plugin "Ferr2D Terrain", which really improved the looks and made it easier to create aesthetically pleasing platforms, and a low cost solution to background art in the form of switching the camera to perspective and using a heightmap, water, and skybox in the distance. Using the mix of 2D and 3D also allowed me to combine 3D projectiles with the 2D gameplay. ----I'm somewhat ambivalent towards the default character I used. This is one of the areas where I probably would have spent more time, had I either been a bit more sensible with my iterations on the rewind mechanic, or had gone with Chronos from the start. While exploring the WhereDunkin' theme, I drew a preliminary sprite sheet for the enemies, and somewhat regret not finishing it / integrating it into the final game. ----One of the things that felt really good from the beginning of this game's timeline was the music. ElektrikWizard did a wonderful job producing a variety of tracks to pick from, and Unity's `AudioSource.pitch` property being able to go negative basically did the rest. The audio rewinding is not perfect; while it does seek exactly to where you tell it, it then enters its "resume" state and slowly ramps pitch back up to 1. The result of this slow ramp ends up being euphonic (Rick was right about the slow ramp), although also means the pitch remains below zero for about 1/3 seconds, thus the inaccuracy. ----The final thing that I'd like to call attention to is the design of the game's single and only level. I don't really want to spoil it or spell it out, so if people are curious about what I had in mind, I can elaborate in a reply to this thread. While making this game, I've been listening to the book "Kraken" by China Miéville, so that may be informative of why I chose the theme I did. ----I've immensely enjoyed working on this game and getting back into Unity. Had I the ability to rewind time, I would do this game jam again . Unity, Unity never changes. Still as fun as I remember, Unity also crashes as much as I remember. I can let it sit and not touch it, and it’ll crash. Before I started to compulsively save, I started to wish I could rewind time and choose another engine. -Dinosaurs let me know that running editor scripts may cause those crashes, which is immensely helpful. Had I the ability to rewind time, I would let myself know. --Unity continues to crash, but much less frequently! ----After tearing out Unity Serializer, it stopped crashing in toto, minus a couple crashes that maaaay have been my fault entirely. Speaking of rewinding time http://www.gdcvault.com/play/1012210/The-Implementation-of-Rewind-in Jonathan Blow covers a few implementation approaches for rewinding time, but the winning argument is to store a diff of properties between frames as binary, and (possibly) compress them. This is a key detail for implementing rewind time, but it comes with some possible problems: memory consumption, non-deterministic objects rule out optimizations, reference destruction, decisions about what is effected by time travel. One of his big optimization suggestions is to use close form solutions for things like particle effects that can have predictable algorithms written. As to the application of diff between frames, Jonathan Blow suggests storing whole values, and not attempting to using delta encoding (reducing storage by only storing deltas). This is great news, as I could see this being a huge time sink in implementation time, and storing whole values makes the diffing algorithm requirements, frankly, a lot easier. I’m grateful that speed of implementation time was a goal for Jonathan Blow when he was working on Braid. Jonathan Blow talks at some length about memory usage by the frame diff storage, and suggests using the concept of “base frames”, or to only store the diffs from every N frames. -These are great ideas, and mostly accurately recounted! They just don't really make sense in Unity, since really, we can just store the whole dang object. It turns out that Moore's Law and a different target (PC vs consoles) makes this sort of a non-issue. Still, I should limit the time frame storage. --Game design to the rescue! I ended up making the level break up into pieces so that you need to run along it or fall and die. I have also limited time frame storage, but now I really don't think it's going to be much of an issue. Base Frames This takes the form of ([ ] = frame, [R] = diff to next recorded frame):
[R] [ ] [ ] [R] [ ] [ ] [R] [ ] [ ] [R] [ ] [ ] [R] [ ] [ ] [R] [ ] [ ]
Where only the [R] frames are stored, and then, only the diff between that and the last frame. This lets us reduce the amount of frames we store, thus reducing memory requirements, however it comes with the caveat that it also increases the rewind granularity. I'll play with the values in this regard to see what's best. -Yeah! Now we're getting somewhere, this idea has stuck, and I implemented a slightly odd variation of it. Currently it's just --Yup, that's an unfinished sentence. I got distracted by an idea and went to "fix" the time frames. Long story short, This makes the timing per base frame function:
int getFrameIndex(double rewindTimeDelta, Frames[] frames, double frameDT = 16, double baseFrameGranuality = 2) {
int getFrameIndex(double rewindTimeDelta, Frames[] frames, double frameDT = 16, double baseFrameGranuality = 2) {
var startTime = frames.Last().GameTime;
var first = frames.First().GameTime;
var rewindTo = startTime - rewindTimeDelta;
var diffFromStart = rewindTo - first;
diffFromStart = Math.max(0, diffFromStart);
return (int)(diffFromStart / (frameDT * baseFrameGranuality)); //note integer truncations means we don't need a Math.floor()
}
var frames = CharacterFrame [
{ GameTime = 0, Data = CharacterParams { ... }},
{ GameTime = 16, Data = CharacterParams { ... }},
{ GameTime = 32, Data = CharacterParams { ... }},
{ GameTime = 48, Data = CharacterParams { ... }},
{ GameTime = 64, Data = CharacterParams { ... }},
{ GameTime = 80, Data = CharacterParams { ... }},
{ GameTime = 96, Data = CharacterParams { ... }},
{ GameTime = 112, Data = CharacterParams { ... }}
];
assert(getFrameIndex<CharacterFrame>(32, frames) == 5); //gametime 80
assert(getFrameIndex<CharacterFrame>(10, frames) == 5); //gametime 80
-This is a nice notion, but one that is flawed for this context, or at least for my implementation. Frame Serialization You might have noticed the generic frames object being used. This is a work around for the fact that we're working with Unity entities, rather than custom models we're implementing ourselves. The Frame<T> interface allows us to implement flexible storage, and gives us different Apply method implementations (definitely not YAGNI since state transitions can be sticky and pre-written components I'm using weren't written with rewinding time in mind). -I dropped generic frame objects like they were hot! I don't even have a class called Frame now! It's been replace with a TimeFrame class, and it doesn't get serialized. Rather it represents a bucket of serialized TimeTravellers and provides --This has changed as well! Had generic frame objects been hot, then serialization was scorching. ----No regrets about dropping serialization. I'm using https://github.com/TheSniperFan/unityserializer-ng to do the serialization of GameObjects, which is a pretty huge boon. It also features compression
interface Frame {
double GameTime { get; set; }
void Persist(GameObject target);
...
-There was some code here that ultimately was broken, and kind of bad. You can see by the unfinished sentence, "It also features compression" that I stopped here. That's partially because I was writing untested statements (see: bullshit), and wanted to validate my assertions. --Yeaaaah, I was right about the broken part. Taking out serialization has made my life easier and the game not as taxing to work on in some respects. Music Elektrikwizard has produced a number of tracks from his collection that might fit the game to help get a sense for what I'm thinking about. Among them were a few that had a pseudo retro feel, and one in particular that was reminiscent of Spyro the dragon. I'm excited. You should be excited. You should hear them. You can't hear them yet. -"Games need good sound, otherwise, you wouldn't be able to hear them." -Erika N -This all remains as I wrote. I've talked to Elektrikwizard, and he's advised me on some finer points of creating a rewind effect without making the listener's ear vomit (my words, not his). Elektrikwizard recommended fading the forward playing track fully to 0 then doing the opposite for the reverse track to make sure that it sounds decent. Maybe if we ask him nicely, he'll post some links to the sample tracks we have in mind. --Implemented! I just adjust pitch back to -2f until I'm at the part in the track I want, then I adjust it back to 1. You end up going about a 3rd second before you were, but that's not very noticeable. It's been a bit squirrelly on the WebGL build output, but switching to FixedUpdate seemed to help some. -As for sound effects. I'm going to be super negligent, and hope the Unity Asset Store will provide. --This is still the case. ----This remains the case, as the music is currently the only sound Rewind emits.
//V1ish
using UnityEngine;
using System.Collections;
using System.Linq;
using System.Linq.Expressions;
using System.Runtime.Serialization;
...
-Then I had just copied a bunch of my code into this file because I hadn't been working with source control, in a single file. I ran a `git init`, and have been working still from a single file for the TimeTravellerBehavior, but now much more sanely. -Ok, now we're up to the present. --Ok, now we're actually up to the present. ---Ok, now we're also up to the present. ----Alright, it is currently the present, with significantly less typos. --I've been working on trying to develop some mechanics that feel "funish" with the rewind. Standard platforming mechanics definitely lend themselves to the rewind mechanic, but I've actually been charmed by the jankiness of the AI component I wrote, and think I'm going to expand on that. Essentially the game I'm thinking this will turn into is something close to a time attack runner with enemies that are a huge nuisance and should precipitate the use of the rewind mechanic. --Also, I wasn't feeling the game play a few days ago, and decided to explore options for a backstory. --One thing led to another, and... well, Dunkin' Donuts fan fiction:
---A note about this story: Ultimately, it would fit a game like Galcon meets Rampart, in which there would be a phase for reorganizing planets in the blind. Think real time Risk, where you'd get to move a country or two between turns. Now, layer on top of that the preceding Dunkin' Donuts backstory. ---I've reworked the TimeTravellerBehavior almost entirely, and it functions much better now. It's much simpler, and the model is as follows:
if (player is holding z) {
rewindToLastTimeFrame();
} else {
pushTimeFrame();
}
---There's a bit more to it, but that's the gist of it. I'm using a List<Frame> instead of a Stack<Frame> only because I trim the front off of it - were I smart, I'd use a ring buffer or some such. ----Speaking of gist, here's the code for the TimeTravellerBehavior: https://gist.github.com/john-holland/ec4df73d5215291d5e18 ----Keep in mind that there's still a bit of cruft left in there (OnDestroy and related variables). ---I'd like to share a handy little tool for implementing comparison interfaces in cases where the type you need them for doesn't / shouldn't need them folded in, and you are too lazy, or in a context like Unity, don't want to muddy your namespaces with utility classes.
public class Lambda
{
public static IComparer<T> comparer<T>(Func<T, T, int> compareTo)
{
return new Comparer<T>(compareTo);
}
public static Equatable<T> equals<T>(Predicate<T> equals)
{
return new Equatable<T>(equals);
}
public class Comparer<T> : IComparer<T>
{
private Func<T, T, int> compareTo;
public Comparer(Func<T, T, int> compareTo)
{
this.compareTo = compareTo;
}
public int Compare(T x, T y)
{
return compareTo(x, y);
}
}
public class Equatable<T> : IEquatable<T>
{
private Predicate<T> equals;
public Equatable(Predicate<T> equals1)
{
this.equals = equals1;
}
public bool Equals(T other)
{
return equals(other);
}
}
}
//Usage is as follows:
IComparer<float> reverseComparer = Lambda.comparer(a, b => a > b ? -1 : a < b ? 1 : 0);
var descendingList = new SortedList<float, string>(reverseComparer);
---Whheellp, I just found http://ludiq.io/chronos/, which seems like it's the defacto standard library / plugin to use for time control in Unity and looks slick as hell. Were I to make this game again, or remake it in some form to sell to people, I'd probably just use Chronos. That being said, I've had fun learning how to implement rewind, and jumping back into Unity with a fun problem to solve. I guess what I'm trying to say is, if I could rewind time, I'd go back and use Chronos... Even for the price of $40, I spent nearly 8 days solidly on the rewinding mechanic and messing with serialization problems and time keeping models. $40 is worth having that time wasted removed and gaining extra cool functionality such as slow time, well implemented undo redo commands, etc. ----I still might buy Chronos to read through the code, as the docs are very interesting and the author seems to have developed quite a few useful patterns.

So yeah. Grow Home. It's a short-ish(took me ~5 or 6 hours to beat) game from a small team in Ubisoft Reflections that is just innocent climbing, exploration, and putting animals into teleporters.
The premise is, you're B.U.D.: Botanical Utility Droid, and you've been put on this planet that has a Star Plant on it. Your job is to help grow this plant(by connecting its Star Shoots to energy rocks) beyond 2,000 meters, so it can finally flower and bloom.
It's got charming music, a nice art style, procedural animation, and just feels super original, fresh, and lovely. It's also $8, and does not require UPlay, so if any of the words in this post appeal to you, you really oughta play it. I 'beat' it today, but have a ton more to do, and I haven't been able to stop thinking about it all day.

http://www.sizefivegames.com/2013/05/07/announcing-gun_monkeys
A wazzo remake of cartoon deathmatch platformer "Gibbage", with better name and everything else.
(I didn't do any design on this, just playtesting/feedback/QA. I did design on the original, but Gun Monkeys has moved away from most of that.)
Keep an eye on twitter.com/danthat if you want in on the beta!

Hi Everyone,
I posted a plug for Gibbage a while back, but this is the last one ever, promise.
Dan Marshall has now completed his game, 'Gibbage'! It's a cartoon deathmatch platformer that Dan has created from scratch on his own, teaching himself to code along the way. It's so far garnered good feedback from Ron Gilbert and Charles Cecil.
The website is up and running. You can download the (new and improved) demo for free, read his blog, find out about the game, and download it for only £6/$11.
He's chronicled his progress in PC Zone magazine, and his blog reprints the articles. It's a really good read, and he'll soon be giving more in-depth tales of the basics of self-taught bedroom programming, so check it out.
I implore you all to download the free demo, give Dan feedback if you wish, and of course buy the game for the price of a couple of pints if you're suitably impressed. It's a brilliantly fun game, with the emphasis on gameplay, and as an Indie Game, fighting against the chart-clogging corporate tosh we put up with, it needs all the support and attention it can get.
Thanks,
Ben Ward