Happy Holidays Everyone!

As of this friday, me and Tobias have four weeks of break ahead of us, and Joakim a couple at least. This will mean more time to the project and more updates in this blog. (Hopefully we will find time to translate it to swedish as well.) The plan for this month is to start modelling and continue programming, in order to open up more areas for development.

Btw, here's a little something from us to you:

This is the concept art for the main female character of the game: Anna the Pirate. Today I also started modelling her head as you can see below:


See you soon, or in 2008!

Exams #2

Tomorrow is the last one. Tobias's and Joakim's were today. Wish us luck! :)

Exams

I guess that could be the title of an entry in a regular diary. And in many senses it means the same thing this time. In two weaks, we all have our last exams this semester and because of that, not as much time will be spend on this project. Sadly. However, we have a full month of winter break after that so work will continue then. See you soon.

Dolly

Pheew. This weekend has been insane.
It all started with me making a extremely primitive 3D version of tetris to test the new object system. During this procedure I realized that a GameObject::clone() method would be really nice to have - at least in a level editor. This turned out to be a lot harder than I imagined. First you have to mind shared references between different components, than you actually must be able to clone all the resources you have stored. This became a little adventure on its own, and I'm not nearly finished, but I really want this function so I'll build it. I have, as of 2 minutes ago, a really good picture of what the different functions would look like and I'm glad to see it doesn't disturb our existing system to much.

I wish I had some pictures to show you, but I mainly draw ASCII figures in forums these days.

But I found this old quick unfinished sketch of a paper boy for the game:

Cake

Hi,
the last weeks I have been more busy than ever...but this time with OddEngine!

Basically I have been putting large pieces of the engine together and started testing a lot... I have created some test components to use with game objects and they seem to work just fine. The ObjectManager has recieved a major lift and many features have been added from scratch.

As of a week ago we are running windows in OddEngine and not just command window stuff, so any moment now we can show the same thing we did months ago, hehe. But this time with a much better ground to stand on.

Nice to see the upswing in readers! Keep on keepin' on.

Quickie #1

Just a quickie:
Today I finished the first basic version of our new task based game loop (or Kernel if you want), so basically I've just been running some test tasks and it seems to work fine. A lot of inspiration came from the Enginuity articles at gamedev. They're really worth a read.

Enginuity (GameDev.net)

What to do and when?

Hi,
The last couple of weeks I've been reading up on engine design a lot, and this has had some effects. Today I begun rewriting our task manager, or the use of it. Up until now we've had our manager more or less idle, because I wasn't sure how to use it properly, but reading articles on the subject has made things clearer. This means that the basic structure of the low level components of our engine will transform a bit in the future, for the good of course.
Ciao

Bifurcation

First: Sorry for the slow updates in the Swedish blog, when things speed up in the creation process, so will the reporting.

Lately, I've been reading frequently about object management in different types of communities, books, articles etc, and I am thrilled to see that there is no real universal solution to the "problem". On one hand, you can do it quick, simple and well adjusted to your project. On the other you can spend a bit more time and have it more general. Really, what you choose depends on what you need, and this is where it becomes tricky. When you start a project you may not know all the details of the completed game and you will not know entirely what you will need your engine to be capable of. Some might say that this has to do with being able to plan ahead, but some questionmarks will remain. As for the object management, choosing a more general solution basically means it will be harder to create more complex objects, like tanks, cars etc, that need several types of physical components all tied together, the communication between them might get a bit mixed up. But if you choose to use an inheritance tree in a situation where you need many similar yet different types of objects, you will end up with far more classes than you need, and a lot of copied code.

What I'm trying to say is that at this point in the developing process, we really need to decide what the engine should be able to handle. And this is always hard. Everytime you start out, you want your compiled code to be totally independent of what the specific game will be, but in reality, you will probably have to sacrifice either speed or reusability or something else.

More questions - fewer answers this time.
Tomorrow: Sweet Nineteen, wish me a happy birthday and stay tuned.

Object Communication

Here's a simplified scheme of what inter-object communication might look like...remember these are just suggestions, if you can think of another option using the things in the image, that function will probably exist in reality.

Component Craze

'noon,
Today I finished the basic structure of the object management system by constructing the basic virtual functions of a component, as well as a small messaging system. I've played around a bit with adding components to objects and it feels comfortable this far. Yet, nothing concrete is finished but I think I'll begin implementing the system into the existing engine soon (until now the component system has been side project). This will mean some major reconstructions, but as there aren't many existing types of game objects, the time spent won't be huge. As always: no pictures - no fun...but hang on tight. (I'll get a sketch of the object system up soon)

Kneedeep

Hi,
Sorry for the last months absence. As expected, the first semester at the university ate most of our time and I can honestly state that we haven't made much progress in October. As of last friday some of our courses ended and new started today. For me, this means 3 courses instead of 4 and hopefully more time to work on the Odd Engine. Today I started a slight restruction-process to be able to implement a new component-based object management system. In short, this means that instead of hard-coding objects like "Car" or "Enemy", you code the components needed to build these objects. Then you define the objects (by their components) in scripts or databases. This is a more general, and reusable, approach to object management. This means a bit more work for now, but it will hopefully pay off in the end. As you might suspect, this is a result insufficient planning of the engine, something that I'll gladly admit as this is part of our learning process. So basically I want to stress the importance of planning, sketching and structuring, for anyone that might be in the same situation as us. I hope to report soon again.
Ciao

Progress

This weekend our little team held a short meeting discussing what needs to be done and what already is. The biggest issue of the last week has been wether we should keep OpenAl as our sound system or change to FMOD. This disscussion comes from different reasons and I can't say we have reached a final conlusion but a certain thing is that we will build our own 3d Sound Manager. This has both pros and cons but Tobias happily agreed to do it making it his main project.

As for me, I realize I have stepped aside a bit from the goals I posted last week, but the last few days I have built a basic LogManager, something that is needed more and more by the day as our project expands.

Joakim got the task of creating a Console / ConsoleManager for the engine. We put some thoughts on possible functions and paper, and the ideas are looking good even a couple of days later.

I don't know if I ever mentioned it, but the game engine we are creating are now officially called
Odd Engine in short, and Oddrose Media Game Engine in full.
(I realise many of you would want it to be the more logical OMG Engine, but I wouldn't be able to sleep if we named it that. So Odd Engine it is.)

Resurrection

Hi,
This last couple of weeks, (is it a month?) have been quite turbulent. With the start of my first semester at college, I (along with my fellow team mates) haven't been able to write more than a couple of lines of code. From this day, however, our daily schedule doesn't include an evening activity, which will hopefully enable us to work on this project a bit more.

The current situation is this:
* We have written a good chunk of a complete inventory system
* We have implemented some scripting features with LUA
* We have continued working on the GUI
* A time class has been constructed
* Updated character/camera movement, both now controlled with the mouse

Current goals:
* Complete the inventory system
* Get a working GUI class
* Construct a character loader
* Get working on a sound manager
. . .

I hope by this message I'll make it clear that we are in fact alive and healthy, and we plan to continue working on the project as soon as by this afternoon.

Good afternoon,

Life campus-style

Hi there,
As you may or may not have noticed, the last couple of days, it's been very quited around here. This have a very valid and natural reason. The entire Oddrose Game Prod. Team have started different university courses. At the start of the first semester (being freshman is it?) we all have a bunch of parties and activities, often just plain nonsense...but that may be me being boring. I can't tell. However, this has had great impact on our spare time, and so we have not been able to work (at all!) on the project this week. We hope to regain control of our situation some time soon.

Have a great day

Tech Meeting #?

Hi,

Yesterday we held another meeting with the development team, this time with a rather tight schedule. The agenda posed some questions on the use of OpenAL/OgreAL as a sound-wrapper. It wasn't until my arrival at home about 3 in the morning that I could verigy that it worked lika a charm. Yet, we haven't put it through any real tests.

In addition to the sound talk, we discussed the all-new dialogue system and how we should make the connection to/from it via Lua. It seems that we're quite well-prepared for implementing the scripts. At present, the data of the dialogues are stored in an XML-file (being considered) that is read by C++. In the Lua scripts there are events and triggers connected to these dialogues by name, so at a given moment a function runs in Lua, which triggers a C++ function, and the dialogue is printed on the screen. For now, this satisfies our needs.

One of the more interesting aspects of yesterdays meeting was the discussion about a japenese blog. Everyone wasn't super-psyched about the effort/cost that would mean to us right now, but some thought that there were great benefits of doing it. Nothing is settled, and a growing visitors count from samurai land kan change a great deal.

Sleep tight

Bank man

Hi there,
This is a sketch of a man working at the bank in the town where the main character lives. I'm sorry to say however that I misplaced the original image of this pic so you'll have to do with the small version.

A treasure hunt with sound #2

Hi there!

This weekend we had another tech meeting and I have to say that I am pleased with the outcome. We discussed some story management and even some level design. In addition to that we managed the wonderful effort of having sound blasting from our project. This is still in playground stage but tada.wav has been played in our executable. Updates concerning sound, gfx and game functions will be posted when the right time comes.

Stay tanned

Expo #3

Hi again...I threw a body i had lying around onto the fishermans head. And this is what he looks like at present. There are no textures on the body quite yet, and the modelling isn't entirely finished. Altogether he is about 2200 polys heavy at the moment, and I don't think that number will increase much, the heaviest things are the hands, so I may cut a few polys from them. The goal is for him to have even less correct proportions later on...his head will be bigger related to the body.

Expo #2

Here's a pic of an early version of the fisherman's head. It's quite low-poly (450) and it's not yet fully textured. But here it goes:

GUI

Hi, I know this isn't the funniest picture to look at, but in my opinion, all pictures are...well, fun.
This is what the default-look of RBGUI looks like, inside of ogre of course. At present, the box says "Krock!" (Collision in swedish) when you run into a trigger.

Sick as a dog

Hi there,

The last weeks have been surprisingly slow in production. I've continued working on game functions, Jocke with 2d, and Tobbe with sound. More and more stuff works so at least we are moving forwards. However, the last days I've been ill, and still am to some extent. I hope this won't have to big consequences on our plans. A meeting is scheduled this weekend and I hope that it will turn out good. Today I modelled the fisherman. He's coming along nicely but I won't show anything without some texture on it.

Take care

Absence

Starting today, I will be absent from any Oddrose-related tasks. I will return from my band-duties at the Emmaboda festival on sunday.

From what I've heard, Tobias will also dissappear this friday and he will also be back on sunday.

See you then.

A Treasure Hunt with Sound

Now I’m back from my holiday, and can start working on this project for real.

The most of the most important parts in the game has been started on already, 3D,2D, animation etc. but we still don’t have any audio prepared for the game, so that would be my task for a while ahead. The library I has thought to use is called OpenAL, a library that, if you believe the description on OpenAL’s homepage, seems really interesting and should be very useful.

"The library models a collection of audio sources moving in a 3D space that are heard by a single listener somewhere in that space. The basic OpenAL objects are a Listener, a Source, and a Buffer. There can be a large number of Buffers, which contain audio data. Each buffer can be attached to one or more Sources, which represent points in 3D space which are emitting audio. There is always one Listener object (per audio context), which represents the position where the sources are heard -- rendering is done from the perspective of the Listener."

To have OpenAL to work together with Ogre without any issues, thankfully the add-on OgreAL exists. Today I have spent a long time finding the correct header files that OgreAL required. These would seem to have disappeared without a trace, but after a visit among the header files in an old version of Ogre this mystery was solved. But, unfortunately, I haven’t been able to build it successfully yet, but I hope this won’t take to much time getting working. But now it’s time for a break and a good night’s sleep.

Goodnight!

Expo #1

Thought I'd post a concept sketch of one of the side-characters of the game. He is a fisherman that lives close to the main character's block.

Mum, I've got nothing to do

There is a certain way of noticing that more structure is needed in a larger project. That is when you start to wonder what you should be doing today. Since Tobias left for the woods, we haven't had a full-team meeting and thus we haven't been able to arrange the daily goals that are so important for productivity. Speeking for myself, the last days have past in slow-motion and I've been jumping from task to task. One of the functions that I'm working on is a class that handles tasks sent to the engine, by either the game itself or by the user. The tasks shall then be executed in a certain timeframe. The thing is that the free and open source TaskScheduler has just this ability. The problem is however, that TaskScheduler has given the project some unwanted bugs and to them I have yet not found a solution. Luckily, there is much work to be done even if you don't always know what to work on.

Yesterday, I instead started working on a collision handler that determines what happens upon the collision between two types of objects. For instance the character and triggers etc. Sadly, I have no new pictures to show but when the work with models picks up speed, you'll get more to rest your eyes on.

A new 2D GUI

Hi you guys!
During yesterday’s meeting me and Fredrik made some serious progress on the CEGUI-front. But as time went on our mind got more and more clouded with doubt on if this really was our thing? And this morning after finding a quote that was at least to say painfully striking we unanimously decided to widen our vision and maybe to remove CEGUI from our project. You can say that this quote sort of confirmed our doubts.


" It's not that we hate CEGUI (hate is such a strong word), it's just most of us have realized that there is much room for improvement in the area. I mean, come on, it's the year 2007 and all we have is Taharez-Look? "


As a complement to CEGUI we have found another open source GUI as Fredrik earlier mentioned. The name is not yet final but it’s called RBGui (www.rightbraingames.com/tech.php). And that is pretty much what I’ve been spending this day trying to fix (integrate with our Ogre-application). It was a lot trickier than I would have expected because RBGui have a lot of dependencies that had to be built from source. Mocha was one of them and had its own dependencies such as zLib. Another dependency of RBGui is an engine that handles the fonts, it’s called Free Type. I most likely will have an extremely interesting time ahead of me as I explore all of the possibilities with these new (to us) third party libraries. I shall return with a status report when I feel I’ve got something to present.

To make things more graphic I made an image that’s sort of showing a small hierarchic overview:

Screenshot

Hi there!
Just thought I'd post an early screen from the game engine:

I play around with the main character of the game.

Yesterday, it was time for another meeting, but sadly only two of us could be present. We went through some ideas concerning 2D and GUI, and came to the conclusion that there is some work to do. Today we heard about a new open source GUI (http://www.rightbraingames.com/tech.php). This will possibly (read probably) replace our current GUI, CEGUI

2D > 3D

Hey everyone!

Just like Fredrik said, I'm temproraily in charge of 2-dimensional functions in the game. The Graphics engine Ogre3D cannot render 2D grafics on it's own. So we are utilizing a third-party library called CEGUI (Crazy Eddie's Graphical User Interface). It's a C++ library that's integrated in Ogre3D so it's very user friendly. But CEGUI is not enough so I am currently using two other tools along with OGRE and CEGUI: SDL and Lua

SDL (Simple DirectMedia Layer) Is a free library with extended possibilities for 2D and Lua is a scripting language. The nice thing about Lua is that you can replace much of the programming with scripts which makes it possible to rebuild the program without compiling (saves a lot of time)

The first goal I want to reach when it comes to 2D functions is a Health-meter of some sort. We need to discuss this in detail at the next meeting

Over and out..

Serious Stuff

The last few days, me and Joakim have continued to program functions for the game and even further improved our knowledge of the tools and libraries we are using. Joakim has mainly worked with functions that consern the 2-dimensional content of the game, and I must say: it is going splendid. Myself, I have been working on what will become the thing that loads our scenes from a possible scene editor. Everything has gone greate and we now have the possibility to load worlds from xml-files. This week and some time forward, we miss our third happy programmer Tobias who is on vacation.

The nextcoming weeks will be spent building a strong framework to implement our game content into. The functions are still, however, on a very basic level and we try not to write any project specific code.

Board meeting

Today we held the first real meeting with the crew of the project. We went through some points that we had put down on paper, things touching the basic idea of the game and some of the functions we would like the game to have. The meeting went very well and we really covered some ground. In addition to that: we got to code a bit as well. At present, we have fully implemeted the physics engine and we can now load complete scenes in to the world.

After the meeting I made a short conept drawing of the main character:

F = m * a

Hi again!
The last days, have been incredibly productive, at least by our standards. During the past weekend, I rewrote the entire charactercontrol and changed it from using defined speeds to use forces instead. In short, this makes the movements of the character a bit more general towards the world. You could say that instead of making the player run with a speed of 7km/h, you apply a forces that make him reach that speed. When you want him to stop, you don't just set the speed to 0, but rather apply a force in the opposite direction. Very beautiful and very realistic for a person who has studied physics in school.

At this moment, our main character kan walk, turn and jump - the basics of character controlling. Something made entirely during the last few days.

If everything continues as planned, I will report back soon.

Don let go of the sun!

Treasure Hunt!

During the spring of 2007, Oddrose Media has started a project that have a more or less realistic timeframe. In short, the goal of the project is to create a computer game where the player is drawn in to a great treasure hunt. This blog is created more for the sake of ourselves than for potential readers, but anyone who wants to read is welcome.

The project started for real in the beginning of June in our small hometown of Lerum, Västra Götaland, Sweden. The first major obstacle was getting all our development software to work on all of our machines. The game is created in C++ with the graphics engine Ogre3d (www.ogre3d.org) and the physics library Newton Game Dynamics. Both of these have free licenses, a major reason for us chosing them.

Now, at the end of June, we have working versions of all of our libraries on our machines and we can now commence the actual building of the game. At this stage we're at a level were we explore and develop the physics of the game. In previous projects, we always used constant speeds instead of moving objects by applying forces. This will take some time to get used to.

When the game takes more concrete form and we can show you pictures or movies, I will let you know and post them here.

Have a great summer!

Translation is good stuff

Hi there,
This is the blog for a game project run by Oddrose Media. During this years spring and summer We've been running a blog on Swedish so to enable all of you to read about the project: here comes a translation of the first posts: