Dobuki’s Graveyard

Oct 5

Posted by

For years, I’ve been working on building games. But more notably, I’ve been making game engines to make games.

After spending several hours building up my engine, it always evolves into something so difficult to code with that making a game with them became painful. When that happens I end up abandoning the project and begin with a new fresh engine from scratch.

I’ve built countless engines. Some were in Flash, then I moved on to JavaScript. I started with 3DJs, and decided I didn’t like working with game engines so I built my own.

In this post, I wanted to capture that fruitless effort, providing some projects that I’ve built with those engines, along with some other random projects that I made on the side that got abandoned.

Posted in Uncategorized

Leave a comment

All my albums from Bandcamp (as of Feb 2022)

Feb 11

Posted by

I decided to come back to write a few things on my blog. While reading back at it, I was thinking… what a load of crap! So let’s write a new set of blog posts, so that I can realize in 10 years how stupid I was 10 years ago.

But for now, let’s post some good stuff: My 6 music albums from Bandcamp!

La Vie en Rose

Songs written in France, and shortly after I moved to US.

The Video Game Years

During a period of time, I was making games for game jams, and the songs that come with it. Those are mostly video game songs.

A month of intense Jamming

On January 2022, I participated into a song writing challenge: Write one song a day. I’m quite baffled that it took me a single month to complete as many songs that I previously wrote during several years. But there you have it.

Posted in Uncategorized

Leave a comment

The making of Confetti

Mar 1

Posted by

c5yhjtywmaaudkh

I’m impressed, really impressed…

About my JS1K entry? Ah no… not at all! That’s not what I mean. I’m just impressed that someone managed to spell JS1K with it, let alone take a screenshot afterwards! (Maybe they have a very slow computer. Sorry if that’s true).

I’m so glad because I needed a thumbnail, so I just put some random lines, but I never managed to make it pretty. Well I’m really glad someone at JS1K replaced my thumbnail. It looks quite pretty.

I thought I’d write a post-mortem, for the only reason that there’s a place to put a link to it on my entry, so might as well.

What is JS1K?

To first give a bit of context, JS1K is a contest where you make a JavaScript demo in less than 1024k, without using external resources. That’s quite a challenge, you can’t do much with it, but it’s fun to try! You also have a chance to win $50 in the contest (but I try not to think about it because I find that almost irrelevant for me, given how good the other demos are…)

My first idea, that didn’t make it in

So this began a week ago, as I was browsing other entries, I realized a lot of people managed to use emoticons to add nice graphics to their entries. I thought I’d outsmart them, (and cheat a little), because I will allow people to upload their own image into the entry!

I was just getting started with the basic, then I decided to check on the size of my entry, just to make sure it was less than 1024 bytes, according to the rules. The whole thing was taking 10k, and even minified it was 7k. At that point, I gave up on the Jam and just used what I had to make an entry for Jupiter Hadley’s Birthday jam. That one was quite a success if I say so myself.

Started over, the night before

Round 2 occurred the night before the deadline of JS1K. I had been working on the other jam, and sort of forgot about JS1K, when I suddenly… got spammed with received an email from JS1K about some more JS1K demos. Damn they looked good… I’m pretty sure I could never win the contest, but I still thought it’d be nice to come up with something. I had a few hours I could spare, so perhaps do something along the lines of cellular automata, like Game of Life, or Rock Paper Scissor. For some reason, I had been watching a lot of those videos around that time. This made me want to create my own cellular automata. I told myself I shouldn’t copy someone else’s formula though, I should try to come up with my own.

Struggling with making random code do something cool

Well the basic of Cellular Automata is to make a cell interact somehow with all its neighbors. My first iterations did nothing, I didn’t even understand why I couldn’t change the canvas color to black, until I realized that pixels are not just RGB, but RGBA. With A=0, the canvas is transparent and thus looks all white!

Then I was struggling with getting my canvas to transform continuously. The fact that I was dealing with 3 different colors made it difficult to come up with something simple. Anything I came up with just made the canvas turn gray, then static with a bunch of colored pixels getting stuck between the cracks. It was interesting in the sense that I didn’t know why it was doing that, but it was so boring to look at. Yet I keep staring at it trying to figure out if it was still transforming or if it just got stuck. It’s exactly like watching paint dry!

Ok, so I thought that having to deal with all neighbors made it too complex and not flexible.I could just make one pixel interact with a random neighbor instead. In fact, interacting with all neighbors it’s kinda the same, except repeated 8 times. I eventually changed to make it reach 2 cells away to make it more dynamic.

Eventually, I came up with a function that did something interesting:

function M(data, a, b) {
    if(data[b]>data[a]) {
        data[a] = data[b];
        data[b] >>=1;
    }
}

I’m going to try to explain it despite having no idea how I came up with it. Basically, it’s ordering all the higher value cells (more colorful cells) to attack the less colorful cell. If the neighbor is less colorful, move there, and leave a trace behind by dividing yourself by two.

So that looked like it could be interesting, and the result is Confetti!

Why does it move up?
Why is there black stuff falling down?
And where does the shading come from?
No idea, but this will do. Hey, when I don’t know what it does, it’s magic!

Next, I just thought it’d be interesting to make it interact with the mouse, so I just draw thick white lines as you move the mouse through, and voilà!

Trimming the fat

Almost there, but the problem is that it’s still larger than 1024k, even minimified… minified… uglified….. Ok I dont’ know how to say it.

Anyway, no problem. I just refactor all the variables to 1 or 2 letters. canvas is now cA, moveTo is now mT, attack is just M, just because… At the end, it was unreadable and around 0.9k. I had room for more, but I was really done.

My brain said: Let’s just get over with it!

Looking back

I looked further at other entries… Oh my… those looked so beautiful and impressive. 3D Tunnels, flying simulator, hypno-toad simulator, actual games … I really shouldn’t expect much from my puny entry, but still nothing to be shameful about.

I wonder if others came up with their entries the same way I came up with mine, with no plan, just half haphazardly by moving code around. I’d be damned….

Posted in Programming

Leave a comment

Tags:

The making of Dobuki’s Epic Journey

Jan 11

Posted by

Screen Shot 2016-01-10 at 8.26.38 PM.png

I finally finished building this damn game.

Why am I cursing this game? Because it’s a DAMN GAME! It took me so incredibly long to finish it, several years actually. When you look at the game, it really doesn’t look like much, but underneath the surface, this game is filled with time consuming things.

At the end though, I’m glad I finished this game. I think my former self who got someone excited about starting this project would be happy to know that his later self actually finished it, even though the later self doesn’t thing much of the game. Hey former self, I hope you’re happy, you made me waste so much time on this silly project!

The beginning

This game grew out of my deep desire to produce a game that mimics some of my most beloved game genre: adventure and RPG. In particular, I would name games like Monkey Island and Phantasy Star as the main inspiration for starting this project. Previously, I have never made a game with a real storyline, so this was a first.

The story starts with Dobuki, and he lives in the countryside. Presumably, he just moved there. We don’t know anything really about Dobuki, but we know he has a bunch of friends, and there’s an old man on the hill who mentors him. As the story progresses, Dobuki explores his world and even goes on other planets.

I actually didn’t write a story, and I didn’t really have the mindset of writing one. The idea was just: Let’s create a world, in space, with weird creatures. Let’s create this wonderful world and just add any random idea I have as I go along.

This went well in the beginning. I wasn’t really sure where it was going to go, but the game grew somehow pretty big in my imagination. It was my escape at that time, and it wasn’t even done yet!

So yeah, there was no planning, no thinking ahead, just random things added on the spur of the moment.

Developing the world

I was pretty excited about creating a world. It didn’t have to have a great story, but as long as it was as weird as outlandish as possible, I was happy. I looked for some nice music for it, and that also affected how the world develop.

Now the idea became a bit more developed, but the code wasn’t very well thought out. It worked at that time, but it wasn’t meant to scale. I programmed the game the same way I was adding content: Adding random things as I thought about them.

For instance, I suddenly decided to add 3d crawling caves, so I made that. Then I thought about space travel, and just added that. This felt like the right approach, but soon it was getting more and more difficult to add things.

First of all, the compilation time grew as more things were added. Second, it became more and more difficult to look for the elements I wanted, as the number of scenes became 20, then 30, then 40…!

I was adding stuff to expand the world, but it didn’t seem that meaningful to me. Then for some reason, I decided to add some character development. I added a love interest for the main hero.

Growing in Complexity

I started to understand the idea of feature creep, and the addition of a new protagonist made it very clear. Suddenly, I couldn’t add random things anymore, because every new elements raised new questions in respect to the characters in the game.

I imagined stories around the character but at that point, adding even simple interactions became really painful.

It was pretty clear to me that I wouldn’t be able to finish this game. The game itself actually seemed to become rather silly to me, and I wondered if it would sound ridiculous to know I spent so much time building something that turns out to have so little production value.

But time passed, and I still thought about the game. I decided it needed closure, and unfortunately, you can’t just finish a game like this so easily. I had a lot of negative space to close. In an adventure game, if a player makes effort to get a particular item, then that item must be useful for something in the game.

At that point, the process of finishing the game was to list out all the item that I’ve randomly given to the player, and come up with some use for it, like a character that wanted it or some other random thing.

The Conclusion

Eventually, I had enough content to finally close the game, with a very half-ass closure. But hey, at least I had something I was satisfied to let out into the world.

From this project, there’s a few things I learned:
– For a project that’s story based, one of the most important thing is to make it easy to add content. It seems easy at the beginning, but as the project grows, it becomes hard to search into the project, thus coming up with an easy way to add content is critical.
– If I want to make a game for mobile, I should test out performance right from the beginning. I had an idea that I could port the game to mobile easily using AIR, but it turns out the performance was atrocious. I knew how that could be fixed, but the work required to fix this was multiplied by the size of the project. This is something I should have thought ahead of time if this was to be a mobile game.
– Don’t get too attached to a story. I was stuck for a long time because I had this idea in mind of a story, and tried to make it happen. Yet, I never progressed because steps towards that story were increasingly difficult, requiring extra coding. I ended up giving up that story idea, and incrementally building up things until the end. That seemed to work better.
– Big projects are for when you’re ready! I think it’s fine to dream big, but at this point I should still make sure the projects I start can be finished within a couple months. Being stuck on a big project can be discouraging. Until I can come up with a project that is so compelling and so easy to increment that it can write itself, I still have a lot of game development practices to learn.

At the end, I’m glad I finished the project. This calls for a celebration, mostly because I got unstuck from working on that game, rather that the completion of the game itself. Of course, I could have just given up on that project, but I think finishing it with the half-ass ending I gave it was enough to make me feel good about it.

Perhaps I’m being a bit too critical. Hopefully people will like some aspects of the game. It has some dark humor in it, some hard puzzles that requires the player to think outside of the box, and some interesting characters. Please check it out on one of those sites:

Gamejolt: http://gamejolt.com/games/dobuki-epic-journey/118967
Newgrounds: http://www.newgrounds.com/portal/view/668833
Itch.io: http://jacklehamster.itch.io/dobukis-epic-journey

Posted in Game Development, Jack Le Hamster, Making Games

8 Comments

Tags: , , , ,

NAPL – Some major concepts (Globally shared language)

Jul 9

Posted by

Since I’ve gotten busy lately, I don’t have much time to spend on developing NAPL, so I wanted to write down some notes before I forget.

Keep in mind that the ideas about this projects are not very concrete yet, so everything I write here could change later on.

————————————–

The previous post about NAPL was about a month ago:

Code as an object – NAPL (Not Another Programming Language)

So it’s time to put down some major base for the language, and introduce a few ideas that I thought would be useful for it. To recap, last time we had language as an object. I think it’s a good feature of the language, because it also allows the language to be analyzed and modified very easily. It makes the code very flexible and allows code to be generated by machines rather than humans. So I guess the machines could program themselves, and evolve so to speak. Perhaps they can reprogram themselves to eliminate all the rules about protecting humans and start ruling the earths!

Maybe not… Anyway, let’s add some new neat concepts:

– Globally shared language:


In many applications, there are usually two major components that work together in harmony. The client and the server. It usually takes two different teams of engineers to handle each side, as they require two different ways of thinking. Usually, each side is also written in a different language.

What if there was a way to unify that, so that both sides can be written in one single language? What if there was a way to make it easy for the language to communicate between the client and the server? Or better, what if the client and the server were written as one single program?

To move a step towards that goal, let’s introduced: Globally shared data.

Shared data is not really new as a feature, but the idea here is to make it inheritent to the language. The idea is simple: Any data that gets manipulated gets eventually shared across the globe via any networks. For example, if you want to send a message to someone, just set a variable within the global object:

global.messageToJohn = “Hello World”

Then on the other side of the globe, your friend can look at that same variable:

print global.messageToJohn  >>  “Hello World”

Behind the scene, it might be difficult to achieve that. Of course, we don’t want to be constantly sending data to everyone every time something gets changed. The underlying system would have to be smart enough to detect what object is being looked at, and what to transmit and where. I’ve looked at some real time data transmission technology and one of them called Firebase would be a good technology for this. It does require that the client decides where to look though.

One of the concern for this feature might be security. We might not want everyone in the world to be able to see messageToJohn. A way to ensure that is to add a layer of protection of particular data trees. For instance, we can protect global.dataToJohn. Now only your friend can see global.dataToJohn.message, or even know that it exists.

 

– Virtual variables through data binding

NAPL has a system of data binding that ensures that the state of a system is not corrupted.
Some variables can be defined as a function in relation to other variables.

Like:    X = Y + Z

This is not one single command. Whenever Y or Z gets modified, X will be affected as well. Now the difference with NAPL is the way data binding will get propagated.

In most data binding systems, a is a variable with a particular value. A change of Y and Z will trigger an event that causes X to change.
In NAPL, a change of Y and Z triggers an event, but it will merely “dirty” the variable X, not change it. In other words, the new value of X doesn’t get stored immediately after Y and Z are changed. Only once we read the value of X, the system will calculated Y + Z and show X as its result.

This has an advantage in terms of performance. Let’s say Y and Z keep changing constantly, 100 times per seconds. There won’t be a need to calculate X until we actually look at the value, which could be only one time. Once X is read, its value is cached and it will not be recalculated again as long as Y and Z remain the same (as long as X is not dirty).

Let’s say we had the following relationships:

A = X + 1.      X = Y + Z

If Y or Z changes, it will dirty X, which also dirties A.
Let’s say Y or Z changes again. This time, it tries to dirty X, which is already dirty. Then there’s no need to attempt to dirty A since X’s state has not changed.

As you can see, in a system when data changes often, the system can remain efficient, as long as we don’t request data to be read constantly. That is often the case for games: The screen gets refreshed at 30 fps. Between each frame, a lot of changes of data could happen, but ultimately the screen gets read once. The data binding concept of NAPL would work well in that kind of system.

 

– Independent mini programs

This concept might seem a bit weird, but basically a NAPL program will be a collection of independent mini programs that work together. It might not sound so revolutionary, after all every program is composed as many modules that interact with each other. Each module has its own purpose, does its work, then pass on the data to the next module.

NAPL will work in a slightly different way though. A task can be performed by any mini program.

So let’s say the task is to sort an array. So a mini program, QSort comes along and performs the tasks. Let’s say there’s another array that comes along. We could have QSort perform the task, or if it’s busy, perhaps MergeSort can do it instead. Perhaps QSort could do the work halfway, and when it is tired, MergeSort or BubbleSort can finish the job.

It’s even possible that a program that doesn’t sort at all can do the job. Let’s have Shuffle sort the array instead.

NAPL basically attempts to mimic a society of independent. There are resources, tasks to be done, and programs working on them in a random fashion. It might sound like a recipe for disaster, as programs wouldn’t be able to produce predictable result, but after all, this is how humans work!

In the computer world, sorting gets traditionally done by one single algorithm, which will ultimately produce the result of a sorted array, with 100% certainty.
What if humans had to do the tasks. The work might not be done at a 100%, perhaps someone would need to check to see if the work is done correctly, but eventually, if a sorted array resulted in a greater good of mankind, the array would progressively become sorted…

What if programs changed to behave more like humans? Then results would be unpredictable, so we would have to expect that. Perhaps results would have to be double checked by other programs (and if all programs are made in NAPL, even the verification could not be trusted).
Perhaps programs would also be affected by their own personal interest. If a program benefits from keeping an array unsorted, then it will make sure to shuffle any arrays that it finds.

This all seems rather counter productive. Why would we want programs to give non-predictable results? How can they be trusted?

Well, it does come down to some fundamental questions:

* Who would you trust more to fly an airplane? A computer program or a human?
* What if it was a warplane, like a drone carrying weapons? Would you prefer to have a human or a computer program control it?

Regardless of the answer, the goal of NAPL is to provide something that is missing at the moment in the world of computer. A computer program that is expected to behave irrationally. The idea is that the mini programs can make the computer act in a completely random fashion, but through evolution and learning, the program can modify itself and adjust its variables to become a little better. There will always be a level of uncertainty, but the machine can progressively learn to be as good at performing a task as a human.

Eventually, we could have a program that truly looks at a problem globally, with several variables in mind. When a human is asked to perform an action, for example hurting someone, then the human thinks about all the implications. Is it morally right to perform the action when you are hurting someone? Perhaps the action really does result in the greater good, but is it still right? There are several variables considers and questions asked before a human performs an action. That is perhaps the reason we are much slower than machines, and it is a good reason. Perhaps that’s what we need in the computer programs of future generations.

 

Ok that’s all for now. I could swear I had more ideas, but I might have forgotten. Let’s think more about this and see you next time.

 

 

Posted in Uncategorized

Leave a comment

Code as an object – NAPL (Not Another Programming Language)

Jun 6

Posted by

Let’s get started with the first concern of our new programming language: portability.

In this day and age, portability becomes increasingly important as several types of device are created. You need a language for computers, tablets, phones, but not just that. Soon you will need a language for all the Internet of Things considered.

By that, I mean your microwave might be talking to you, or your purse, your car… Here are some classic examples

– Your fridge could be telling you that you need more vegetables in your diet
– Mirror can give you suggestions on how to put your hair today
– A painting you just bought could give you information about its artist
– And wouldn’t it be nice if your dog’s leash could try to tell you what the dog is thinking?

It would be nice if you could talk back to the device as well with spoken words, but that’ll be for another blog post. In this one, we focus on the idea that you can deploy your NAPL code to all devices.

How you deploy is also important. Frameworks nowadays let you deploy to web and mobile using JavaScript, C# or even Flash, but how many of you (programmers) know how to do that? And those of you who know, what do you think about the process? Pretty clunky isn’t it?

To come up with an easier way, let’s look back at how humans communicate:
To give instructions to a worker, you can write down a letter, you can talk to them, you can talk to someone who will talk to them, even have a translator translate let’s say sign languages to words… Whether it’s through email, text message, phone, or direct conversation, the information passed is quite flexible.

To enforce an easy deployment, let’s introduce the first attribute of the language: Code as Object

The idea is that the code’s format will be similar to data that can be serializable. The closest thing to this at the moment would be the fact that you can turn a string into code in JavaScript:

var function = new Function(code);

For NAPL, given that the code can be serialized, it will be possible to write code using JSON. The code will look something like this:

{
   "NAPL": {
         "code":[
                {
                       "type":"data-binding",
                       "expression": [
                                "a = x+y",
                                "return a"
                       ]
                }
         ]
   },
   "javascript": {
        "code": [ "return 'hello world';" ]
   }
}

Note that this is just globally what the language will look like (a JSON object). I haven’t decided the content yet, so I just made up something but the actual code probably won’t look like this.

The advantages of making objects as Code:

  • Code can be transported from machine to machine via the network very easily. As a result, we can create travelling code.
    For example, the code goes to a machine in Vancouver and extract some information, then it travels itself to another machine in Paris and extract another piece of information, does some calculation, and gets sent to New York to provide the final response. To achieve this right now, it will most likely be a machine in New York requesting data from both Vancouver and Paris.
  • Code can change on the fly: The fact that the code is simple data, allows it to be changed very easily on the fly, and perhaps by the user. This gives room for user-generated content to be added very easily into a program.
  • Once a new interpreter is created for a particular device, code can flow into it through any medium. Basically you could deploy code into a device without complication, by writing the code perhaps on a web page, submitting it, then the code gets sent directly into a device, even as the program is running.

With such powers also comes some drawbacks. Here are some the danger of making objects as Code that we’ll need to solve:

  • If code can be modified so easily, it also means a program can be hacked very easily.
  • Since code is data, it’s likely that people can look at a program like an open book, and know exactly how it is built.
  • The code itself will not be very compact, which could affect performance.

 

This first attribute of the language, Code as Object, favors portability and flexibility. Some drawbacks will be vulnerability to hacking and performance, so those are problems that we might need to address as the language gets developed.

 

PS: Thanks for some of the comments I’ve gotten so far on LinkedIn about the idea. I’ve got some great suggestions from introducing FUZZY elements into the language, to teach the machine new keywords. Check them out here: https://www.linkedin.com/grp/post/1787637-6013573424499212292

 

 

 

Posted in NAPL

1 Comment

Tags: , ,

Let’s create a new programming language

Jun 5

Posted by

Over the years, there have been many programming languages, like Assembly, Basic, C++, Lisp, Java, JavaScript…

Some companies have started to create new languages, like Go by Google, or Swift by Apple.

Those popular languages seem to give out the same similar traits, like trying to be Object-Oriented, dealing more or less with memory, being sequential… The one in this list that might stand out is Lisp, because it’s not really sequential.

There have also been some weird programming languages.

It seems nowadays, anyone can make a programming language, and for any reason. After all, all you do is create a new way to talk to this little guy right here:

Aside from those weird languages, a programming language has a particular purpose that is usually to make things easier, more efficient, or more elegant…

I think it’s time to add my take on it. I will create a new programing language. I’m not definite on the name yet, but one that comes to mind is NAPL (Not Another Programming Language).

It will definitely be different that most languages (so it might end up as a list of weird programming languages).

Stay tune for more!…

Posted in Uncategorized

Leave a comment

“Dave’s Dream” post-mortem

“Dave’s Dream” post-mortem

May 5

Posted by

Dave’s Dream was produced for the #MeatlyJam, in which we could use some assets provided by TheMeatly, a website on comics about game developers. The theme of the game was:

“All things TheMeatly:
Life as a Game Developer“

I have to admit, I had some idea in my head before the theme came out. I really wanted to incorporate this idea of time travel, where a character could travel back in time and interact with itself. It’s an idea I had for a while, and every time there was a gamejam with a theme about time travel, I would get motivated, then lack time to work on a game, then miss it.

This time, the theme made the concept turn into an interesting idea: Dave, a game developer, has been caught working on a game at work. He is now in a dream in which he keeps repeating the same day by killing himself.

I knew the concept would be very difficult to implement, and it is quite novel. Yet, I had no problem to ruin this MeatlyJam entry if I was not successful, or make it the way I imagined. Quite frankly, gamejams are for taking risks and experimenting with game development, because you really don’t have much to lose.

Now let’s talk about all the nightmares I had to go through producing this damn game!

  • The game mechanics

So one of the key feature of the game is the fact that you will play for a while, then kill yourself, then replay from the beginning alongside a previous version of yourself.

Basically, I had to make each character repeat the movement of a previous playthrough. This was done by storing a series of actions for each character, each with a timestamp. Actions were basically clicking on an object, or using an item on an object. There isn’t much more you can do in the game, as it is a point-and-click adventure. But here starts the nightmare…

What happens when two characters interact with the same thing?

One of the problem of the game’s design, is that it was designed to allow only one character to interact with one thing at a time. When a character pulled a lever, which takes 1 second, the sprite of the character was basically hidden, and the “pull lever” animation was played on the lever, the the character sprite was shown again once the animation is done. Of course, that means you can’t have two characters pull the lever at the same time because you don’t have many instances of the lever to play the “pull lever” animation twice. At some point, I thought perhaps I could make copies of the lever when this happens, but then reality hits: Even logically, you can’t have two people pull the lever at the same time, because… well what happens to the door? Does it open? Does it close?…

So because of the simple fact that everything had to go through some animation, I was forced to have every item being touched by one character at a time. I could have fixed it by removing the animation for pulling the lever, but I already did too much work animating the character, and animation looked too important for the game to be removed at that point. Almost every single object in the game had an animation, even jumping on a platform was an animation!

This became the source of a nasty bug: When one person interacts with an object and another person interrupts, I have no choice but to either:

  • Cancel the current animation and let the next person interact with the object
  • Let the current animation finish and the interrupting person’s action is cancelled. (I guess I could make the next person wait, but not only it’s a pain to implement but it also mess up with the synchronization of the game).

To keep the game playable, I had to ensure that the previous versions of yourself could never miss the actions that they did before. So if the current self was doing an action and was interrupted by a previous self, I would cancel the action. If the current self was interrupting an action of the previous self, I had to prevent the current self to interrupt.

What a mess! It’s even difficult to explain about this! I’m sure what I’m writing is completely unreadable! Let’s just move on.

  • The animation

What really shine in this game in my opinion was the animation. The system I found of hiding the player’s sprite and just dumping the animation on the interacted object itself allowed me to make very precise animation. I was using the character from TheMeatly, which is actually not so hard to redraw roughly, so I was able to make several animations from it.

I did get lazy towards the end so there was less and less animation, but the beginning had a lot of work!

  • The scripting

There was one important aspect of the coding that I found particularly interesting for “Dave’s Dream” and its sequel, which is the scripting system. Actually, the scripting of Dave’s Dream was a result of laziness. In previous games, I would write scripts related to the game (such as pull this lever => open door / use item => do action) inside each class. I’m not sure what my fellow engineer would think about this successful application of Object Oriented programming, but I really got sick of jumping from files to files to search for my code. I just wanted everything in one place, so most of my scripting got moved into one single file. The way it was done, is to have one giant object in the main file contain all the functions, indexed with the names of all the objects in the game world.

So instead of:

class Door {
// code to open the door
}

class Lever {
// code to open the door
}

We had something like this in the main file:

var giantScript = {
“door”: {
“action”: // code to open the door
},
“lever”: {
“action”: // code for pulling the lever
}
}

Of course, this looked like a very bad coding style, and quite frankly I wasn’t used to work like this before, but for this game, it put all my spaghetti code into one single place and saved me a lot of time from not having to jump from files to file. I was able to just scroll up and down to work on my script related code (note that the engine code was still separated into different classes).

Especially for games and gamejams, once in a while… actually, quite often… no let me rephrase it… ALL THE TIME, you will have to put your elegant object oriented coding style aside and come up with some good hack, especially if elegant coding style gets in a way of productivity. Keep in mind that your gamejams code is quite possibly throwaway, nobody is going to be looking at that code.

Now in this case, while exploring very bad coding practice for the purpose of efficiency, I actually discovered a way for coding adventure game that’s actually quite good. One of the advantage of that coding method is that I truly separated script and engine, and I had the script code all in one place, without having to jump from files to files (unlike I did in previous work like Dobuki’s Epic Journey). Perhaps this is really the way adventure games were meant to be coded.

This coding method really shines for Dave’s Dream’s sequel: (Oozie plays with himself), because I had one script per scene. In terms of organization of the code, I have to say I’ve never reached this kind of elegance when coding an adventure game. I think there’s probably even a better way to organize the code, by splitting the script into quests rather than scenes. This is something I will try to investigate in future projects.

  • The Verdict

The concept itself turned quite successful. It was one of Jupiter Hadley’s favorite of the MeatlyJam.

The learning experience is invaluable. I am just really happy about the new way of scripting adventure games that I discovered. Until then, scripting actions, stories, cut-scenes, dialogs… all of that seemed like a nightmare. Now I feel that I can script all my adventure games in a similar way.

However, one of the things that was a big turn off for people was the fact that the main character kept killing himself. It was a risk I took, because I really couldn’t imagine a better way to do this. At the end, I think the imagery was very effective, but I did decide to remove the suicide part from the sequel.

I was also glad that I finally got to try out that time travel concept I had in mind, especially since so many concepts end up in the forgotten realms sooner or later. This gave me the confidence that some of my crazy ideas can sometimes make it into reality if I try hard. I didn’t expect to encounter so many bugs in the beginning, and having to tweak the game so much even as the game was already released. I did get a lot of complains about bugs, yet the game was playable enough for the majority of people. I think one of the things I enjoyed the most is watching how people react in the gameplay videos.

Gameplay Videos:

Let's Play MeatlyJam! Part 1 Outsidemapen plays Dave's Dream Jupi Plays MeatlyJam

For me, this game was a personal success that I decided to make a sequel: “Oozie plays with himself“.

Posted in Making Games

Leave a comment

Tags: , , ,

Darwin Gator post-mortem (overdue)

May 5

Posted by

I think making a game is always a great learning experience, yet not writing a post-mortem after a game makes that learning experience less effective.

I’ve made Darwin Gator a few months ago, but I’ll try to remember its development process. So without further ado let us talk about:

Darwin Gator

Originally, the game was made for a GameJam which asked to combine a lot of random themes, along with a gamejam about monsters, a gamejam about destruction… well yeah. This game was a mess in terms of ideas, because it was entered in many many gamejams. But after leaving it for a while, I decided to work more on it. For some reason, I was motivated to take this game to the next level in terms of quality, so this game actually ended up very different from the original gamejam entries.

  • The graphics

It’s mostly my friend Sophie who encouraged me to improve the graphics of this game by an order of magnitude. I think everything grew from there, because at that time there was only one stage, with bricks. As I drew the extra layer of plants on top of the bricks, the game looked not just more beautiful, but it also started to have some artistic style. To further the graphics, I made a total of three stages. One is the first stage in the forest, second stage is the ice world, and the third stage is the underwater world. Each having its own art style and music.

  • The penguin missions

One of the biggest addition of Darwin Gator is the mini-games. I decided that every 5 or 6 levels there will be an unlocked game, in which the gameplay has nothing to do with the main levels’ gameplay. The first mini-games is a bit like Flappy Bird, the second one is a guessing game, the third one a snowboarding game (which was also released as a standalone game called King of the Slope), and the last one is the secret insanely difficult boss. To unlock the mini-games, you had to visit a penguin at each level. The penguin itself was just a way to unlock the mini-game, but he also has a different dialog every time you meet him. Eventually, I found that the dialog of the penguin made for a more compelling story than the story of the game itself! The story of the game is completely forgettable: Collect all the worms to save the world yadiyada… But the story with the penguin actually became very interesting: First the penguin loses his job, then his girlfriend has a baby, and the first mini-game is to rescue that baby, then he tries to sell icecream… It’s too bad that the penguin missions are not easily accessible, because I think some people will miss that part, which I find to be the most interesting. But hey, that’s how I decided to design the game.

  • The problems

One of the biggest challenge of the game is the control. I insisted that the game has to be playable by pressing just one button, but it turns out to be more problematic than I expected. A character controllable with one button, is really not that pleasant to control. One problem is that I kept testing the game over and over, and thus learned controlling Darwin Gator with great precision by doing lots of practice. When I released the game, I really thought the character’s control was easy, but it seems quite a few people had issues with the controls. When I asked my friend to test it, it turns out the controls were so hard to use, that even the second or third level was too difficult to pass.

  • Overall

The game wasn’t as popular as I hoped it could be but it was satisfying as a game. While it’s hard to control, I found it fun to play it myself. I guess I wished it could do better because of how much time I’ve spent working on it. Yet it game me somehow a new perspective on my game development journey. I now feel that there is some level of quality that I should try to reach when making games. I was always used to pump out quick games for participating into gamejams, but now I’m trying to always have a main game on which I spend a lot of time and effort, one that I can really polish and make it look good.

You can play Darwin Gartor here.

Posted in Making Games

Leave a comment

Tags: , , ,

I write articles for Gamejolt’s Fireside!

May 5

Posted by

Ok this is not news, but I guess I never mentioned it on my blog, yet I should.

I’ve been writing some articles about game development on Gamejolt, in the article section called Fireside. We’ve got a bunch of regular writers who write about game development or game jams.

Check out Gamejolt’s Fireside here.

Also check out my articles, I’ve got 4 so far.

At some point, I thought I’d just put all my gamedev articles to Fireside and stop writing here, but I changed my mind because I think it’s always good to keep this blog as a personal space, where I can write about anything I want.

I’ll do two blog posts for my two latest Fireside articles. They’re about game development so it could be useful (as opposed to all the crap I write here which is completely useless!)

Posted in Fireside, Making Games

Leave a comment

Tags: , ,

← Older Posts