Today’s title may be weird to see, after all, it’s about a mistake I made in programming. However, people made mistakes all the time, so they can learn from mistakes.

So, What happened?

What should happen:

It went like this:

I’ve been working on a project that resembles a pac-man game for quite some time, and all these time, I’m trying to work out a way of effectively doing collision detection. Now, what I initially thought how to do it, is to read the colors of the pixels that made the borders of the walls, and if the border of the sprite of pac-man intersected a pixel with such color, then it can be said that the main character has collided with the wall and will cease moving. (If the main character didn’t collide with a wall it will definitely keep moving towards that direction except further action is assigned).

Below is the “map” I made for this project, in other words, this is the pacman board.

The walls all uses the color (99,15,164), and the wall border is also specifically set as (5,3,67). Technically, I could set up so if the border of the pacman sprite intersects with a later color, then consider them collided and stop the movement of the sprite.

The similar way of collision detection has been already used in the Pacman eat pellet part, but it’s done traditionally since it’s easy to just erase the pellet when pacman’s sprite went through it. And technically, what I thought would work because there is a call in 2LoC engine that did get the properties of a pixel for me:

• GetPixel() : tloc::graphics::media::Image_T< T_ColorType, T_StorageType >

This call should get me the pixel-in-question’s color, and storage type.

So, I hook my if statements up with that, and compiled the program.

What really went down and why

And it turns out to be a disaster, none of the collision detection is there, when I pressed the direction button, the main character just turned and ate through those walls.

While I admit this turned out to be very funny, it’s not pac-man at all. So obviously, this should be fixed.

I looked through the code, and find out that the above call deals with images, basically it’s handled by the part that loads the images. So the results that came from the calls used in those if statements are not reflecting the color that the engine really reads, since there the engine let OpenGL to handle those buffers and everything should went there.

So I went through the code again, this time starting from another direction, and then fixed the calls so it came from tloc::graphics::gl instead of tloc::graphics::media.

Then, I rewrote the if statements to match the new changes, and run it. The result? Less a disaster, but still is:

Now the pacman character will stop when I hit a direction button when it cannot turn. However, the sprite turns, the pacman sprite actually went down some pixels before it got blocked with the collision kicked in.

So basically, the character is still turnable when it shouldn’t.

The problem this time, I suppose, lies in pixels. After a closer inspection made in Photoshop, it seems the sizing of the initial picture caused the pixels that has the color (5,3,67) to changed color – PS has a way of handling resizing of non-vector pictures, one of the ways is to change the colors of the border pixels in order to conduct the anti-aliasing. It uses a lot of pixels that look the same but has the different contrast and hue around the jagged parts – whatever – come to think of it, I even blogged about this last year in this very blog! How did I fail to see that coming?

So here I am, remaking that board, and writing this blog.

Then what about the “more” in this title?

Oh, it’s about my other project. See, I’m supposed to do a non-trivial cutscene, right? By a cutscene, that means with animated stuff, right? So last week I’ve been working on implementing rigged animation in 2LoC engine, and complaining the lack of presets in the engine to boot. Then I found out that the only thing that need to move is the keyframed camera. Heck, I worked on a week for nearly nothing, at least I put the ideas of that youtube video featured last week into practice, so something came out from that. But that aside, I still think I wasted some time so I don’t really want to talk about it. Now, back to making the new boards, or until I came up with a new and effective way to do these collision detection.

Until next time.

(Yes I’m referencing another certain game there, I know that the video involved runs for about six hours in total.)

Why are we here

So, recently, in the spare time of programming, I heard our professor recommended some videos for us to watch, and all of them are programming or game industry related, so I went to take a look.

And what a look that is, it’s six hours of content that worth about 20 blogs. However, there are some of them that left a very special impression since it’s actually related to what we’re currently doing, and the discussions in-class recently.

I also has some discussions with one of my artist friends, she can draw very good stuff, but knows nothing about programming and think it’s magic (really). So she is one of the best targets to conduct “rubber duck debugging” on that’s not a rubber duck (lawl), some of the comments below may came from her and surprisingly something in those videos are really more common sense than anything.

The videos are of follows:

• John Carmack Keynote – Quakecon 2013
• CppCon 2014: Mike Acton “Data-Oriented Design and C++”
• CppCon 2014: Nicolas Fleury “C++ in Huge AAA Games”

The three videos runs for about six hours. I spend about 3 days to watch them all. This blog are finished in one sitting, though.

The 1st hour: John Carmack on Game Industry and Engines

First video is John Carmack’s presentation on Quakecon 2013, One of the first thing that amaze me is that he literally talked for about 3 hours nonstop while constantly changing the topic, However, in my opinion most of the interest stuff are past the 1 hour mark,

Namely, Carmack talked about the modern game industry, about how the game developers should do to fit with this industry. Which makes me think of the presentation our professor made back in MIGS about the value of self-made engines and pre-existing, third-party engines and/or game makers.

Both parties agree that developing an engine is a heavy investment, which extra time on making the engine itself work. It is true that developing on third-party engines will save both time and cost since there are existing reference manuals and other developers’ experiences built on them. However, again both parties points out the fact that a new engine is a method towards something bigger.

In Carmack’s presentation, he reminds us that most programmers who works Multi-Paradigm tend to do the bad things, because they are used to work with something that’s not theirs. They may have experiences working on Unity and/or Unreal, but when it comes to making decisions, they are sometimes forced to make the worse and the most brutal way because their ability are limited to the engine. In his words, “They don’t have an escape plan.”

Note Carmack’s presentation didn’t actually points out “make an engine of their own!” to be the solution of the problem, instead, his standpoint on this matter seems to be letting the programmers do more and see more stuff, which according to our professor, can be done by making an engine of their own.

“But how about money and time?” My artist friend raised an objection.

The point here, in my opinion, is how far we as game developers plan to take game developing.

For example, as of now, our game (the one we are doing, not related to school projects) builds on a game engine, and we have nearly zero to work with, we have little time and money to justify the action of spending years to make an engine of our own. In this case, I think it’s okay to use other engines and make “implementation” top priority.

However, to really do something different, after gathering some money and free time (due to having more resources to work with), then working on an engine is a fast way to gain experience on actually working with questions, instead of writing code. Which leads us into the next video’s standpoint (don’t worry we’ll be back)

The 2nd hour: Mike Acton on how exactly do we program for

Mike Acton’s video presentation is about “Data-Oriented Design”. Which emphasis on the thesis that the basis of any programming is to turn some certain data into some other kind of data, thus, data-oriented design. Mike bashed on the common sense model of “Real-World modelling” at the beginning of the presentation, stating that while this is common sense and sometimes correct, in the data-oriented design, the format of the data won’t always match that of their real life counterparts. Also, as a programmer, our job isn’t to simply program, but rather, solving questions. Programming itself is only a tool to help us with solving a certain question.

The reason why Data-Oriented Design is mentioned is because in game developing, the project are most of the time with a Deadline, and with limited resource to work with, additionally, sometimes that the developer’s situation don’t quite match the situation of the target. (Since Mike is working on consoles, namely PS4)

In other words, Data-Oriented Design makes us more efficient with programming and design.

“But I don’t see that doing things without template or not referring to real world models are efficient.”

Which is also true. From my understanding, the efficiency Mike mentioned, together with the examples and codes he demonstrated in the later part of the presentation, are more like a way to speed up the CPU efficiency by grouping calls and setting up variables so the program only need to be working with data and how to convert those data to other formats to be outputted.

This line of thinking may be a case of sacrificing the programmer’s efficiency but makes sure that the program itself runs faster on most test cases.

In my opinion, both efficiency are important, it’s similar to the last case about engines, the question is how the programmer needs.

Mike’s project are under limited resource and time, and he has only so much to be working on (since every PS4 have the same hardware options). In other words, he has a definitive problem to solve, and this particular problem need a certain solution that requires a way, or the only way to max out the efficiency of the CPU.

However, sacrificing the programmer’s efficiency sometimes don’t quite justify the CPU improvement if you know your target market won’t have these problems to begin with.

That aside, the thesis of Data-Oriented programming is very solid, especially the part about solving problem VS simply writing code. Code is used to solve problems, you don’t code for code.

The 3rd hour: Nicolas Fleury shows why C++ is still efficient in AAA Games

The 3rd video is from Nicolas Fleury, who is working in Ubisoft, listing the reason why and how C++ is still used in their AAA Games.

Nicolas argues that C++ is still efficient because he can, and did modify some of the core functions to make the program runs faster. In other words, this is a balance point between human-readable code versus machine-understandable code.

In his example, he modified an entire Singletons to control the lifecycle of the program. With a controllable lifecycle, the program showed a notable increase of efficiency in tight loops.

In fact, in our everyday programming in school projects, we are always trying to invoke more functions in the engine that extends on existing code. For example, in our 2LoC Engine, there isn’t any code to read the animation files exported by Maya. So the sensible solution of this problem is probably to extend the keyframe related classes to somehow read those keyframes in outputted files, or write something entirely else to implement these unique keyframe animation yourself.

Related to Mike’s presentation, we don’t need to write something brand new just to let the engine support what we need, or conversing what we need into something the engine could understand. In this case, the animations maya outputted are data, the stuff people see on the screen when they run the game, is just another form of data. Thus, instead of focusing how to make the engine read a new kind of data, we should focus on how to let the engine read the original data, and let the engine do the job of conversing them to the new format of data, in this case, the animation that will show up on the screen that people see.

“But the end result is the same, right? At least I saw the same stuff…”

Yeah, what the user saw could be the same, however, Mike points out that sometimes your resources are limited, and lack of CPU time will ultimately cause a difference in performance, and these small problems stack up quickly.

Conclusion

in other words, The balance between what we read (human-workable, Programmer efficient), and what the programming(CPU time, code efficient) really does are a key element in this two video presentations.

These are all experiences that we can only gain when we are actually working with our own engine, instead of only implementing our stuff on some other engine. Which makes Carmark and our professor’s claims valid as well.

Until next time.

About Pacman

So, something interesting happened while I’m looking into the possibility of recreating pacman within our 2LoC Engine. (BTW I almost missed it, but 2LoC apparently means 2 Lines of Code – which is anything but! Nothing can be done within 2 Lines of Code! Just saying.)

I run in some problems that I’ll be listing below:

• Collision Detection, namely the walls.
  • It’s clear that in Pac-Man, the main character cannot go over the walls that’s in the way. It is true that when a direction button is pressed, the character can go straight ahead until another button is pressed. However when it hits a wall, the action stops.
  • However, the collision of the walls calls for some effective method. I’m thinking of letting the engine read the color of pixels and when the hitbox of the main character actually hit these specific pixels with this certain color it will count as a collision and stops the motion.
  • The more traditional way, is to out the wall parts, define them in the engine, telling the program that the main character cannot intersect with that specific area. However, I could foresee that this will take probably more time than the above method.
• AIs
  • The original game features 4 Ghosts as enemies, each has a different AI Set. There’s 1 randomizer, 1 chaser, 1 wanderer and 1 blocker. Which calls for 4 different set of AIs. However in our scenario, we’ll only work starting from 1 set of AI, that’s the chaser.
  • The core mechanic for the chaser AI is that the position of the main character is continuously tracked through moving, and the position of the main character is then used by the program to decide where this chaser AI can move. The chaser AI will always move towards the nearest route, which could be easily calculated on paper, but to actually calculate them into the engine would be harder than it looks.
  • The easiest AI to make would be the randomizer AI of course.
• Bonus
  • There are two bonuses in this game.
    • Power Pellet, which changes the AI to some sort of an Anti-Chaser because from then on during a set time the AI will actively avoid the player. Which will be easy to make once the AI is sorted out.
    • Cherry, an item that spawns after a set time that simply provide points. Now there’s a problem regarding the tracking of the time. In the original game it seems a cherry spawns once within 2 minutes. However that means the time that the game is played need to be still be tracked. So this is going to be implemented. A faster way to do so is actually to track the number of steps, or more likely distances the main character is traveled and base the spawning of the cherry on that amount. However this is unlike the regular game.
• Scoring and the actual pellets would be simple enough.

On other projects

Games need cutscenes, and there is a possibly that Maya-built cutscenes could work in our engine. However there’s additional coding to be done.

• Regarding Keyframes:
  • It is true that there are at least something in the engine that allows Keyframe-based animation. However, one notable miss in the crack is that the engine somehow lacks an ability to manipulate camera via these Keyframes. Not that they’ll be exported in the OBJ file to begin with. This need to be solved before any additional work could be done – maybe read these camera positions from another file?
• Regarding Morphs
  • Morphs, or blend shapes, is necessary for a cutscene to work. The problem is that similar to the above condition, the animation of a morph target cannot be outputted by Maya normally. Maya can output animation to some other formats but it seems the engine initially reads none of them – maybe additional extension of the engine itself is necessary? This is shaping up to like the FMOD situation I mentioned earlier…

Aside from that 2 problems, it’ll be easy to import a cutscene made in Maya into our game.

Yeah, I’m aware that this week’s post is more about questions and questions without any progress, but problem solving is a sort of progress on its own. So I’m back into that. Until next time.

Hi there,

So I’m back. A lot of things happened in the 2~3 weeks since the last entry. But mainly there are 2 things.

What We Are Doing

One is the game of our group, it’s a arena dueling game where 2 players play against each other. The players need to navigate in a medium-sized arena. find equippables such like weapons and ammos or powerups, and bring their opponent down using them before they got knocked out first. The concept is fun. But a concept won’t magically turn into a game.

In this game, the characters need to run, jump, collect items, inflict damage to opponents. Which means we first need a 3D Area, with normal (or in this case, slightly abnormal, because admit it run on walls is cool) physics. We still need to generate a list of items to spawn, and set up a list of collisions. Not to mention the parts that’s not related to the engine like, actually modeling the arena and items, Art, Sound Effect and Music, etc.

Fortunately, we do have something to begin with.

The L2oC Engine came with an example of an OBJ Loader, the OBJ Loader is quite useful on loading some of our models that we made in the last weeks. However, We still need to load the arena. We have tried to model the entire arena in Maya, export that scene into OBJ file, and load it up in the engine. The outcome is…passable, but is not what we are looking for for various reasons:

• Firstly, from our Game Design Document and our planned scope, the result of the arenas are quite big. It could load fine using the existing OBJ Loader Code, however there will be some loading times when the game is booting up, and we probably don’t want that.
• Also, A scene so big causes some problems that we currently don’t know why they’re there. For example, if the whole arena is imported as an OBJ file, sometimes the physics will outright fail to work (e.g The player is supposed to conduct a wall run by first running, then jumping and hugging the wall, but sometimes the player just floats with jumping, which is weird.)
• Lastly, If we load the entire arena as a scene every time, that means if we need to edit the arena in Maya, we need to open up the whole scene in Maya and change from there, then export them again. Maya exporting could take a long time especially on large scenes.
  • Plus, the UVing would be a chore since a scene so large need its texture UVs carefully planned, and if somehow we decided to change the aspect, or the shape/detail of the arena, the UVs need to redone. Which means more additional work.

To solve the problem, we are planning to split our arena into at least 4 Parts, and place that so it works like a 2*2 matrix:

Area 1  Area 3

[                         ]

Area 2   Area 4

Then, we build the above template in our game, and assign one part of the scene as a separate OBJ file to load.

We separate the OBJ in order to let the engine do something under-the-hood that will enhance the experience of players:

• Depending on the position of players, essentially we can only load 1~2 Areas when the game is started, this will shorten load time.
• Since the scene is split into 4 parts, individual editing in Maya/Mudbox will become much easier due to the smaller file size.
• And this is the better part, since we are actually rendering 4 separate areas, we can apply different shaders on them so they will look somewhat different! (and about shaders, I worked with them before!)

With that being said, the implementation of the above has already started and something would be ready in the next following weeks.

What I am doing

Here, I find an interesting question showing up in my TO-DO list.

The requirement is to rebuild the common and classic game Pong in the 2LoC Engine.

Well, it came in 2 parts. One is the classic one which is black and white and generally boring.

The other part is the same game, but with differently colored interface, proper lighting, motion blur and trail (that means bloom). Most of them will be done via shaders.

I actually got most of these shaders ready from last year, but when I tried to import them into the new engine the engine breaks down, it seems some additional work must be done.

But it’s quite interesting that a game looks so much better when slapped a big bunches of shaders on it.

In my opinion (I could be wrong and will correct myself next week if so), I don’t think the vertex shaders need to be changed, the meat and potato are in the fragment shaders.

I’ll be working them in the mean time, I wish myself good luck. (It’s not like I didn’t done Pong or Space Invaders in C++ before… …)

Ok, so we’re back! After an entire summer of dead air, this blog is alive and running again!

So yeah-

We’re Back!

Without further ado, let’s start from where we left off.

(Note: This entry, together with some of the next entries, may not have a picture for obvious reasons, since we are not talking about something normal players would seen.)

When we last left, we discussed a series of “techniques” and “algorithms” in order to create effects for our games. However, these are ultimately, methods. To use this methods, we need something that’s more basic, that’s an Engine.

Yes, we could totally work our game from ground up, coding what the game needs and came out with a good game, just like we did last year. However, it’s not feasible in the long run because of the following reasons.

The Problems

• Scope
  • The scope of a game is one of the basic property of game design, for small games that is a tech demo, or has short game play, there are no reason to not stick with “code-as-you-go” tactics. However, for a larger game with lots of content and assets, there are codes to be reused, exceptions to be thrown and track, and assets to load. If we don’t organize them it could be a disaster.
• Organization
  • From prior experience, to make a game with decent gameplay and appearance, a lot of assets will be needed, this include but is not limited to physical assets such as models, textures, sound files/music, but also coding assets such as shaders and codes that read the physical assets. These assets need a place to be read, but the programmer probably want to organize them so they don’t all went under “/resources” (which is exactly what happened months ago with our own game, though we don’t have that much resource in the beginning so we let that slide.)
• Debugging
  • Now let’s consider a bad case scenario in which something in the OBJ Loader went wrong and results in distorted models (don’t laugh, even Pokemon X/Y got that glitch). Programmers need to know if it’s because the model is flawed (thus has a bad output) or the OBJ Loader itself went wrong. Since in both cases the error messages would be similar, that provides a very hard tracking and debugging process.

So, we basically need something that will erase all these repeated codes, manage assets for us, and is easier to debug. This is where an engine comes in.

The Solution

Engines came with different kinds, the simplest Engine out there is probably RPG Maker, it’s more a game maker than an engine, but the most recent reasons enabled the game designers with coding skills to directly mess with the project’s code, making it a semi-engine since it has all functions a game engine would have already. However, what we need, and what we’re talking about, are much harder to deploy while allowing us to do much more than a simple maker that produces RPG Games.

Now here we will work with a special engine called 2LoC for the time being, which is quite special since it’s assembled by people at UOIT, meaning it’s academic instead of the common commercial work such like Havoc or Unreal. However, the basic idea are the same, while 2LoC did has wrappers for some Havoc functions and would be curiously familiar to people (such like me) that has experience with XNA or similar engines.

So what do we have here…

To address the above problems (no, not the familiarity of engines, the bigger problem above), 2LoC has the following characteristics.

• Function Overrides, or to use the better and bigger word, Polymorphism (πολύςμορφή, click for the wikipedia entry). Basically it works like this: First we got “base classes”, barebone classes that draw an outline of a series of functions. Then we have separate classes that divide from those base classes that override the base and provide the actual implementation. This is a very familiar practice since it also exists in XNA.
• However, the divided classes themselves on the other hand, are pretty much singled out with each class have implementations for just a single function. Combined with the fact that we can divide the implementation from our base class, this is a good design practice that makes sure one function only got one class while getting rid of the need of copying code for reuse – since they should be in the base class by now.
• The engine is also easy to deploy (well, I saw people had problems, but it runs smoothly here so yeah) via CMake,  We had this script that will deploy the engine files according to the version of Visual Studio installed. No more moving files from Visual Studio to the project files, or set up the properties in Project files since the CMake script did it all. We only need to import what we need into the generated solution and-
• Said importing is also easy since everything is organized. Plus, this engine has a clear exception handling so say if a model get displayed incorrectly, it’s now easier to see if it’s caused by the OBJ Loader, in which situation the engine will throw the exception, or by the model itself, in which the OBJ Loader itself will throw another exception.

By using this engine, we solved all the problems stated in the beginning of this blog article. Isn’t that a great thing?

But Wait…

Yes, maintaining an engine is not as easy as coding freely anymore. For example, to add something that’s a function, you need to follow the standards of overriding classes and write a new class that extends the base class. This needs a good understanding of the engine itself to carry out – but it’s still better than writing entire methods and reusing codes. As of now, I’m still looking into importing assets and functions into the existing and deployed engine, I’ll update the blog when I have something to show here. As of now, Nemo out and back into reading engine code.

Until next time, Be Lucky.

Now we are back to frameworks, we must ask ourselves: What exactly do we need to put in a framework?

Continue reading →