About this blog
Chronicles of the flawless tetris
Entries in this blog
I figured out that THAT much people want to see real-time what I see from my appartment window AND comment about it, so I post it in my journal. I'll include a permalink to this post in the journal header in no time - it's really, mainly for the comment support.
Enjoy the view:
click for big
Noticeable facts about this picture:
- The view is looking South, hence East to the left and West to the right
- The white flat area in the center (a little towards the top) is a (junior?) high school sportsground; every weekday, starting at roughly 9:00 AM, local time, you can see this area filled in dark blue, which is actually the full crowd of school students gathering for the 9-to-10 compulsory exercise session... You're really just missing the orchestral march song accompanying their moves :) The school buildings are the tall concrete cubes located to the left of this area.
- The red area in the center-right of the picture are NOT Chinese flags, but merely triangular red flags on the rooftop of a small on-the-street restaurant (although I probably need to make sure of that)
- The clearer area on the center, left border, is actually a typical Chinese (or should I say, asian) wood roof structure being renovated; you'll probably "see" it being rapidly built
- The whole typical small houses area (called hu tong in mandarin) seen in the picture dates back to the Qing dynasty, and is actually located between series of 6+-floor modern residential buildings (including mine); such typical areas are on the verge of extinction in cities all around China, though a few in Beijing are now protected by law (note that I don't advocate blindly for the conservation of such houses, because, as is, they pose serious hygyen issues)
... that's what it's all about !
In the news of the day, I am proud to announce that 2 of the 3 steps mentioned in the last post are achieved, nameley collision detection and user input.
To this latter extent, by the way, I must humbly grant significant insight-triggering to darookie: besides being the only active IRC chatter on #gamedev to share the same 3 first nickname letters with me, he has indeed be the source of unsuspected neuronal re-organization in my brain around the more or less well defined concept of "it's all about interfaces".
To make it short, I was simply amazed at the simple - yet profoundly impacting - following function signature:
GameEvent updateEvent(PlayerEvent event, Output &output);
I don't want to write much more about how thinking in an interface-oriented way has modified my approach to coding, since I am no expert at it... yet :)
Instead, here's what the Tetris is at:
- Collision detection works; block movement and rotation are limited to the appropriate area
- Player input is roughly implemented; in other words, it works, but I need to change the direct referencing to game logic functions according to the afore mentioned enlightenment :)
- Lines wiping also works perfectly, although I'm not sure I am already counting the wiped lines (wrote that code some time ago actually :P)
So basically, it is playable except for one noticeable unimplemented feature: falling. Yes, actually, the blocks are just hanging in the air waiting for the user to press the down arrow to move them down, or spacebar to 'drop' them (i.e. move them all the way down, wipe lines and insert new piece). It shouldn't really be a big issue, but since I want the falling speed to match the music tempo, I will be very careful as to how implement it.
Now, for the basic Tetris to be fairly enjoyable, it needs a scoring system, maybe some tuning on block rotation, and also tuning on user input (I would like the blocks to keep moving when a user keeps a key pressed).
Regarding graphics, the render classes I implemented so far are rather ill-designed, so that to finish with the core game engine, I especially wrote a single rendering class (called SimpleTetrisGridRenderObject...) before going on to deepen the graphics.
During my upcoming coding sessions, I will most probably start toying with audio, with OpenAL probably, though I didn't investigate any other sound libraries so far.
According to day-to-day mood, I might also start a real usable design document, since I will inevitably need one when it will come to add artistic content on a big scale.
Bye for now, with a shot of what it's up to, as usual:
EDIT: the current 'score' text is fake, obviously
Wrote significant portion of the code (un-releasable, though, since I am aiming so much at playability for now, i.e. ugly all public code), both on the game logic part and graphics part, which end up yielding the following test screen:
(click for full size)
Playability is roughly 3 steps ahead:
- Collision management
- Player input
On to the pit!
PS: for those who won't care looking down to the second post, the block art is self-made :P
I guess that simply adding the previous entry in my journal had me get back to it more seriously :)
Anyway, I have finally finished my embryo of 2D engine. It's basically very inspired from traditional 3D engine architecture, only with much less functionality - functionality will be added as needed, and hopefully not as pre-emptive stuff-in, I'M NOT MAKING AN ENGINE !!! :P
We have, then, RenderSceneNode objects, each of them having a vector of RenderSceneNode* as children, and a single RenderSceneNode* as parent.
I abstracted functionality on the fly in a way inspired by my habits of Java, leading to 2 interface-like classes which are Renderable (for objects with the ability to render) and Movable (for objects with positional data).
RenderSceneNode publicly inherits from both, and implements the tree-style function call of the render() method inherited from Renderable. RenderSceneNode also exposes a virtual onRender() interface that all class derived from RenderSceneNode should implement. The recursive call handles relative positioning in a 2D-vector style, since no support for rotation or scaling is implemented yet (such support is still at stake and hugely dependent on the debate "Sprites vs. Vector Graphics").
So far, classes derived from RenderSceneNode are fairly simple and designed for usability: TextObject, PictureObject (holds images loaded from files) and RectangleObject.
Of course, most is work-in-progress here, according to the iterative approach I decided to follow. Particularly, current implementation is coupled with SDL and SDL_ttf in a very ugly way (the actual declaration of the Renderable interface is "virtual void render(SDL_Surface *) = 0;" ...) and almost all classes have their member variables public.
To end my raw flow of thought about this project, I'm currently thinking of implementing dynamic scene creation (scripted and/or file-based) but I first want to make this damn Tetris operational ! :P
So long for now, with another picture of what Ctrl+F5 produces (in VC++ Express 2005):
(click for full size)
See you around...
It has now been something like several weeks that I started my project, and if a single word could fully account for the development process so far, it is definitely anarchy.
Despite my good will, I ended up tuning the code structure more than expected, and didn't come up with an operational Tetris game yet. Thing is not that I fell into the engine development death spiral, but rather that I touched the code very rarely along these weeks, with no solid design approach.
Anyways, I've been working on a small architecture which separates input handling from graphics handling, along with a simili-2D-engine which features - so far - simple rectangles, loaded images and text rendered from TTF.
I must say that too many design doubts and questionnable perfectionism hamper my ability to simply write the code down, though I'm working on it.
So, that was just some information about the progress, linking a test picture of what the graphics can handle:
(click for full size)
For the last few days, I've been doing a lot of thinking as to what issues I am going to encounter during development, along while coding basic classes and drawing things on screen with SDL.
But first things first:
My idea of a 'fun' Tetris is actually pretty simple: as I don't want to significantly change the rules, I expect the fun to come from the 'content'. I have seen many Tetris clones featuring nicer and nicer graphics, yet mostly in the "more refined, higher resolution, special glowing/lightening/transpareny effects" sense.
While such improvements indeed provide the players with graphical beauty, it always left me with a cold and austere feeling - kind of like visiting an ancient cathedral.
Somehow counterpointing to this approach, I would like to add fun through funny content... So straight forward isn't it ? Alright, what I mean by fun content is rather something combining several of the following elements:
- cartoon oriented visual art and sound effects (with no excess)
- significantly animated
- humorous in a surprising way
- game performance influencing the whole audio/visual atmosphere
On this last point, I'll add some details later, but basically, it includes: game speed in accordance with music tempo, which increases with difficulty levels, and thematic levels which feed the thirst for beating the whole game - provided that the first levels surprised the player in a good way (e.g. "Hey that's funny, I want to see more !")
That's it for the design idea.
Tech... tris (ok, this one is poor...)
Technically speaking, I already coded a Tetris in Java some time ago. Yet I realize that if I want something clean and easy to enhance content-wise, I'll have to make better than have the main class (TetrisPit) inherit from the main graphical class - basically having a 2-class application :)
However, I also want to avoid the far-too-often-seen-let's-develop-a-2D-engine-for-my-game with no actual game ever being developped. Thus, I'll go on with an iterative approach, coding for the game as needed, and then refactoring when modularity is at stake and code redundancy becomes a real burden (or maybe a little earlier than that :P).
That's it for now, and before leaving you, a somehow irrelevant picture illustrating my earlier mentioned sandboxing with SDL: it just illustrates regular sprites blitting with block sprites I did draw in approx. 2 minutes as temporary tetris blocks, hence their fantastically genuine look :)
(click for full-size)
Also, I should mention that I have a full time job and a girlfriend, both imposing drastic constraints on my productivity.
Please feel free to ask or comment as you wish!
Have fun and see you around!
Everything has a start, and so it is for my child dream to become a game developper.
I am a junior software engineer, and wanting this first serious individual project to be worth something, I have been reading stuff all around the Internet - including GDnet - and joined GDnet+ today to celebrate the kickstart.
So, following an article I read on GDnet, I am starting with that good old Tetris.
I am pretty sure I will have the game engine itself coded quite fast, so beyond the game itself my focus will be on the art - 2D sprites and anim, and music and sound effects. Precisely, I want my Tetris to be FUN. And I have some ideas on how I plan to do this - though I have no clue whether my ideas will actually make my tetris fun :P
Well, anyway, there will be some ongoing design doc somewhere at some point. I have made no real decision on my development process, but it will most probably be iterative all the way.
Some tech specs before diving into deep sleep:
- Code::Blocks / MSV Toolkit 2003 combo
- SDL for graphics
- still to determine audio lib, and maybe other interesting stuff to make the job easier
Idle 2D artists/animators, you're welcome to comment or give advice on the best tools, or even your availability if any of this tempts you :)
Bye for now!