Jump to content

  • Log In with Google      Sign In   
  • Create Account

A non-programmer's programs

Let Loose the Kraken!

Posted by , 28 May 2012 - - - - - - · 1,933 views

I entered the "Let Loose the Kraken!" contest, which was my first weekend contest and the first contest where I could really put myself there and do hard work.

I am very happy with the result, and that I managed to make (and simply get) ideal conditions for rapid development.

Ideal conditions involved unemployment and an understanding girlfriend, with whom I cold make the fact understood "long" before the contest, that for three total days, I would be absolutely unusable, sometimes pissed off, sometimes tired, that I would only be able to pay attention to programming.

I had a great luck with time too. The contest started in my country at 8 AM.... Three full workdays for the project without the need to break my sleeping routine.
So it ended up an intensive but quite friendly 12 hours per day developing.

The idea:
I sketched up 5 ideas, 3D wasn't even considered, as I have never used an engine and 3D requires too much tweaking anyway (cameras, object sizes etc).

Luckily the sliding puzzle idea came up quite early. After maybe 1 hour of brainstorming. Making a puzzle was kind of default to me, I like puzzles, my girlfriend's parents always play with puzzles, and lately I was thinking about making a puzzle (a totally different kind). The simple ideas came rapidly, so in another 30 minutes I had all the game in my head.

Outline of the game:
The game is a level based sliding puzzle where you have to match the pieces of the Kraken's arms by sliding one row or column of the game-board at a time. All of the Kraken's arms must reach all the boat pieces to complete the level.

Idea is one thing, it has to be tested. Making a new kind of puzzle (maybe this type already exists, I don't know about it) can be risky in this time interval because if it's not that good, you can throw it out. But at least it's not as hard as prototyping a physics simulation thing or a 3D gameplay.

Luckily (for this project but not so otherwise) making games are always rapid prototyping for me (even if it's a proven concept like minesweeper), all the games I made were prototyped in max 2 days, so I have experience in that.

Throwing together the prototype was done in a half day with placeholder graphics for the cells. In this case, the prototype simple meant that I could slide the rows or columns in the game field, and see if it's interesting or boring, too easy or too hard, or is there a method the user can exploit that totally kills the challenge in the game. No winning conditions were examined, reaching a ship did absolutely nothing, the cells' images were just images.
There were quite amount of framework code lying around, as setting up an openGL window with the 2D projection, loading/uploading textures, font loading and rendering, generic mouse handling stuff, the windproc with the message loop, a ready to use Visual C++ project (these all mean I just used the skeleton of an old 2D editor I started but abandoned)

Prototyping involved hacking like crazy. I tend to hack but this time it was very embarrassing even for me.

The art:
I didn't expect to make decent art for this time interval. But it turned out I had plenty of time, and that I am quick with simple pixel-art. There was no time to try out ideas, but the themes were pretty default anyway. I admit I got some help by getting opinions about the finished images of each thingy, the opinions were about some colors only, otherwise it was "it's cute Posted Image"
I used reference images, but just as a guide and only by eye. I mean I didn't manipulate or draw on top of the images. So the quick method was: draw the bulk of the image with a 6-8-10 pixel soft-edged brush (and refine curves by drawing with the background color), that gives you nice curves and smooth edges, then simply draw the outline pixel by pixel (on a different layer) in 10x zoom. It's easy to do as you can see the fading pixels and you can set up a vague mental threshold which pixels should be part of the outline. Then refill the shape with solid colors and get rid of the reference sketch.
The outlined, solid colored but semi-realistic objects in front of simple gradients Japanese style was the default choice, as I'm not good with lifelike smooth shaded or "cute characters" art.

I did the art as the "stepping away" part of programming and vice-versa.

There is no sound or music in this game, as I have never worked with those. But I don't think I would put sound in it anyway, because I guess most of us either listen to music or don't want sound at all.

The download link and some teaser images:
Attached Image Attached Image

This little game turned out to be pretty good after playing with it for some time, I think I will make a polished releasable-to-the-wild game of it (and completely rewrite the thing). My girlfriend is testing the game "intensively" because she like it and she has ideas.

I don't think I will change the style, I like it Japanese (I will look into Japanese 'Kraken' mythologies and hope some kind exists...), but maybe some better frame and button style will be done. And more sets of textures for different resolutions.

Anyway, I soo needed this coding marathon as I hadn't done coding (apart from some random fixes for my portfolio) for more than half years. There's nothing like it.

Programming Portfolio

Posted by , 06 April 2012 - - - - - - · 2,299 views

I decided to use this entry as a surface for showing my programming experiences and portfolio in a brief summary for anyone who is interested. I know it's not the professional way to do so, but my profession is mechanical engineering anyway.

In advance, here are some links about some stuff I did and do:
Youtube channel
Paper modeller blog
My latest hobby: self-made technical Lego models
Gamedev.net Journal

The story

I am proficient with the C language, we started with it in the University. I coded on DOS platform and now I code on Windows. I tried some other languages and made things with those, but I stayed with C. Programming is a hobby for me, but a very important one. It's on a par with my profession.


The story begins in the University (Faculty of Mechanical Engineering and Informatics,
University of Miskolc) in 2004, in the first semester, "Computer science I." course, C language.
I fell in love with programming. My first graphical homework program was one of the best in the course.

From now, I will only list the programs that I made outside the few courses we had. Most of them are learning projects, but there are some programs that I actually use or used a lot.

Attached Image
My first own program was a prime number searching text program, that automatically made a little log file and printed some statistics when its execution was aborted. When the program was launched again, the counting continued from the number in the log file, and the statistics were also loaded from it. A percentage indicator showed the process during execution. Basic input (the highest number, to which the program should check the numbers), input validation and file usage.

3rd Semester, Computer Graphics. That started my 3D and graphical "career".

Attached Image Attached Image
Tank Wars
This time, I started my first big (and longest lasting) game project, which I actually finished and polished. It is a Scorched Earth clone, a 2D turn-based artillery game with complex AI ("bot" type), graphical menus, color themes (256 color palette graphics), team play and free-for-all mode, mouse and keyboard input, in-game console, save/load game, popup windows, multiple weapons and shopping, cellular automata, effects, complex scoring and money management, and so on. The terrain is generated with random Bézier-curves.
I had to make two tools for the development: a graphical 16x16 bitmap sprite editor and a color palette editor.
I worked on this project (with pauses and other projects) for almost two years. We played with this game with friends for many hours.

Attached Image Attached Image
Meanwhile I was exploring the 3D world with a small wire-frame display program with hard-coded vertex and edge data; and a 3D Bézier-curve editor. 4 viewports, one of them is 3D. The user could rotate and zoom the view, move one of the fixed number control points with simple keyboard interface.

Attached Image Attached Image
Ray-casting program
Another "big" (learning) project parallel with Tank Wars was ray-casting. I could only use the 256 indexed color mode then (VGA), so it was limited. Anyway, everything came from my head, I reinvented everything apart from the rotation matrix. It has texture mapping, shadows, alpha mapping, Phong-shading (I didn't know what it was called that time), specular highlights, reflection and refraction. There was a static scene, where the user could "fly around" and make renders when pushed a key.
All the texture data were hard coded, but the models was generated by the program (sphere, cylinder, some boxes). Most of the features couldn't be applied to the same surfaces, because of the very limited range of colors.

This was a long lasting project too, so I made other stuff meanwhile. Some of the noteworthy:

Attached Image Attached Image
A graphical minesweeper clone with mouse input. I made it mainly for learning, so the gamplay was polished and there was a very simple start menu, and save/load field features.
3D Rubik-cube manipulator. The sides could be rotated, rotating view, keyboard input.


I'm not sure when I was engaged in assembly programming, but it didn't last long. I needed that for speeding up my DOS applications. I didn't know that time, that assembly itself won't speed up my stuff...
Anyway, I made a small text viewer with the very basic text formatting features, like tabulator and newline, breaking wider-than-screen lines. It had a primitive syntax highlight feature: highlighting C++ style comments (//blah blah). It was only usable for small text files.

Windows and OpenGL Era

Attached Image Attached Image Attached Image
Rubik-cube program
My first program outside the class (well, my homework for my class was again one of the best: a revolved surface editor, where the user could place the points, then press a button, to generate the revolved surface from it, displayed in wire-frame mode), so the first OGL program was of course the Rubik-cube program. The user could manipulate the cube (turn the faces). It had a small pop-up menu, 2x2x2 and 3x3x3 modes, planar shadow, mouse input. Simple, but finished (uses GLUT).

Tank simulator prototype
At first, it started to be a small learning program for texture mapping. It became a bit more... I started using GLUT, but soon I dropped GLUT because of it's limitations, and moved to Win32 programming.
It focuses more on physics than graphics.This stuff uses the Fixed Function Pipeline, but implemented some advanced stuff with it, like cascade shadow mapping.

Read the descriptions on Youtube under the videos about the features.

There were several small programs for trying things out, like environment-mapping.


We were introduced to this program on the "Numerical Methods" curse. It was very high-level for my "experiences" with other languages. It was extremely useful for me, it gave me a new, higher-level viewpoint of how applications work in a higher-level environment. This new experience led me to Win32 programming.

Outside of the class (well, my homework was far more than a homework again...), I made a small image viewer program, with zoom, pan, menu, etc.
I made a lot of small programs with it during the university, many of them were used by my classmates too for speeding up monotonous design tasks.

I liked Matlab very much and I'd be happy to do some serious work with it in the future.

Back to C, OpenGL and Win32:

Minesweeper game.
This is a small, polished game, where you can scroll and zoom the large field. The windowed user interface was programmed from scratch.

Attached Image
Using the minesweeper "engine", I made a small game prototype of a game that looked promising when I fantasised about it. It turned out to be not so promising...

A little algorithmic exercise for the problem arisen a few times in the forums. See for example this.

For a little exercise, I made common beginner programs: Tetris, Snake, Breakout and a board game ("Brain Vita"). It was like a race, I was curious how much time it would take to make working prototypes. Well, Breakout and Tetris took about 5-5 hours, the other two took 1-1 hours.

Attached Image
For my job (Phobextools Ltd. 2011), I needed a Graphical CNC editor program. This program is very close to being finished, but my contract ended, so little bug-fixes, small improvements and the proper release never happened. Anyway, I actually used that program in a daily basis, so most of it was polished, and it just worked and did it's job. Other employees still use that program for work, and that is the most important. The application had to be too specific for the machine anyway.
You can read more about it in this Journal, for example here.
I didn't update the Journal about the project, above is an image of an earlier version (it has debugging info displayed, win32 status bar was added later).

Attached Image Attached Image
Finally, the biggest project I'm working on:
the Paper Modeller. This is a modelling software for making paper models from 3D data. Paper modelling is one of my hobbies and this program is to aid it. I plan to release this program, because I found that most programs are either very expensive or aren't suitable for serious paper model makers.
I'm talking about the features, implementation, thoughts, etc. in this journal (http://www.gamedev.n...mmers-programs/).and this blog.

For a more focused version of my portfolio, click here!

Thanks for reading and feel free to comment!

Das LEGO side-project.

Posted by , 28 October 2011 - - - - - - · 939 views

I'm still ""building my life"" so I'm still not at my computer, so the Paper Modeller project is still on hold.

But one can play with LEGO wherever one wants, so I've built my first ever MOC (my own creation) trial truck. I used to play LEGO a lot when I was a kid (approximately 10 years ago) but I didn't build much stuff on my own then, and mainly models (I mean for the looks) or only smaller parts of mechanisms. I hadn't built anything since then before now.

So my first real MOC project and my first meeting with the "studless" building system (in opposition with the older studded system which I was familiar with) lasted 4 days. I only had two kits (and one older one, but I used only a few parts from it). At first, I didn't take the "project" seriously, it was just for killing some time.

Due to these factors and the complexity/counter-intuitiveness of the studless system, the machine is quite hacky at some places, rebuilding the stuff would be a nightmare. If I had double amount of pieces, I could rebuild the whole thing using the older iteration as a reference. Maybe I'll do something about it, maybe it's time to move on to another project/experiment (experimenting with different suspensions for example).

So das auto:
It is an off-road vehicle with four wheel drive. It is not motorized (so "doesn't move by itself"). But it has a 2 speed gearbox, real differentials with a central differential and differential lock, working V6 piston engine and live axle suspension. The live axle suspension is pretty common in vehicles, especially off-road vehicles. Mine uses Panhard rods and trailing arms.

Building LEGO machines requires very much thinking in advance. You have to keep pretty much every features in mind from the beginning. Well, I couldn't do that, so the steering is not complete. It can be steered with a knob at the top of the vehicle (which is very common in LEGO kits too), but the steering wheel doesn't work. I managed to build the drive-train to it, but it has so many gears that the internal friction makes the whole thing jammed. So I took out the final gear, so the steering wheel is only decoration.

I don't have enough pieces to reinforce the body, so it has a small torsion under stress.
I'm satisfied with the model, it's pretty good for a first project with not too big piece inventory to work with.


Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image Attached Image

Paper Modeller 05 with progress and big screenshots

Posted by , 12 August 2011 - - - - - - · 1,196 views

I made the mistake, that I didn't make the intent of the application clear in this journal, I just linked my old one.

Thanks Zarfius for the comments that made me reply and write down the "goals", now I can just copy it here.

The goals of the application

Due to my relatively poor English, I can't really use the term "goal". In my previous entry, I was talking about my "goals", in this paragraph, I'll write about the application's "goals" (what it does).

The program is for aiding paper modelling, which has nothing to do with computer games. So the main feature is precise unfolding polygon meshes (so it's not the same as UVW unwrapping). I know there are many programs and plug-ins for that, but all the programs I found during a small research was either not "to my liking" or was "expensive". Some of them have manual unfolding (polygon-by-polygon, which is very tedious), some of them are only suitable for low or very-low poly models, some of them produces crappy unfolded geometry or are tedious to work with. And as far as I saw, none of them take the thickness of the paper into account (which is 0.5 mm for the cardboard I worked with for example).

A main goal is to make an algorithm that produces the best output with the least input even with high-poly meshes. Easily and intuitively modifying the unfolded geometry is a must too. And of course printing/plotting the result with different line types and textures. Later I'll add more features, like modifying surfaces of the original 3D mesh to be unfoldable (it's hard to explain what I mean by that); making slices of the mesh for layered paper structures; automatic/manual adding of "flaps" to the edges to be glued together, maybe basic documentation tools like guidelines, arrows, numbers, comments, assembly drawings, etc.

More explanations in my old blog, I don't want to rewrite/copy the whole thing here.

The Progress


Reused the code from the previous version, and added new features like
  • automatic welding of unfolded vertices/edges
    It's hard to explain why I need this. So see the first three images of an unfolded box. Second: with welding, third: without welding. You can see how the algorithm builds up the unfolded geometry.
  • displaying the split (cut up) edges in the 3D view
    and added an "unfold edges only" edge selection method. Of course, welded edges are not displayed
  • textures
    really just using the same texture coordinates as the original mesh
  • sharp edges are rendered as broken lines
  • triangle identifier numbers on 3D and unfold geometry
This is just the beginning. I plan to add a lot of other and powerful features to it to generate much nicer geometry that needs fewer further manipulation.
And of course taking the thickness of the paper into account. That will be a huge pain in the ass. Maybe I should start with a *perfect* shell generation algorithm (offsetting the faces). Well, even 3ds MAX cannot do that....

You can read more about the algorithm if you like, here.


I played (struggled) with it a lot, programming-wise. With the help of Gamedev of course. Now it has expandable/shrinkable groupboxes, and the whole "Right Panel" is scrollable with left mouse button drag. It still flickers (I didn't dare to use WS_EX_COMPOSITED style for the panel), but (IMHO) feels/looks quite slick. And it will be helpful in the near future, because I still haven't bought a new monitor, and the current has an approx 200x200 pixel dead area at the botton-right corner.

Of course, it's far from finished/polished, but at least I can forget about it for a while.


Or whatevers... I still have no idea about the mechanics of the editor. Especially the mechanics of unfolding.

I unfold the geometry, then I edit the unfolded geometry, then I press unfold again, and Bam! all the editing is lost. Or maybe every unfolding should go on a new "Sheet"? (if the user wants of course). After unfolding, the 3D and the unfolded geometry should be totally separately handled? What about other stuff in the future? When I add new meshes, like layered things of the 3D mesh? How about importing new meshes?

Maybe the user could select which sheet the new unfolding should go, and override the unfolded geometry on that sheet?

So a lot of brainstorming and design is ahead of me.

The first three demonstrates the welding stuff. The box is segmented only for testing this feature.
The other seven images are about the unfolding of the car model, modified by edge selection. The algorithm splits (cuts) the geometry at selected edges. It took me about ten minutes to make it (excluding 3D modelling). I tried two variations for the roof.
The last three shows the GUI.

Attached Image
Attached Image Attached Image

Attached Image
Attached Image
Attached Image
Attached Image
Attached Image
Attached Image
Attached Image

Attached Image Attached Image Attached Image

Attached Thumbnails

  • Attached Image
  • Attached Image
  • Attached Image

Paper Modeller 04 with unclear goals

Posted by , 29 July 2011 - - - - - - · 705 views

Progress is slow and doubts arose.

The main causes of doubts is the serious lack of knowledge and the unclear goals of the whole "project".

My former tool programming projects had clear goals: to make something useful for me and for a very certain, special task where an unfinished but working application is enough. Those goals were achieved pretty damn well in my opinion. I could make tools (the "DNC Editor" for example) that speeded up and facilitated work by orders of magnitude. They weren't finished, they had bugs, sometimes they crashed, they worked only on the target computer but that was enough.

This "project" has no clear goals.
There can be two main goals: making something useful for special tasks and a certain group like tools for game development in some cases, or making an application that's useful for the public.
  • useful for special tasks and a certain group: the problem with this goal that this tool would not be so useful for me or for a certain group. I will not make paper models, at least not in the near future (near <= 5 years) and I don't know any certain "groups" that would do so.
  • useful for the public: the problem with this goal is that it requires a finished, polished product, and I simply do not have the knowledge to produce one. It's much harder (in my opinion) to produce a good tool for the public than a game. Just think about the GUI (maybe that's the most important thing to get right).
    And unfortunately I don't have the drive to do what it takes to produce a finished tool: to learn. I think I'd need at very least one year of intensive learning, for which I don't have the time, the mood etc (I'm a mechanical engineer, and 8 hours per day of brainwork is just enough for me).
So, the whole project pretty much hangs in the void with a minor goal: to have some fun. But honestly, digging myself into MSDN, crying over my total lack of knowledge about memory management, etc is NOT that fun.

The fun is in the algorithms, the GUI layout and input/selection/edit features etc. Maybe a more suitable area would be the design for me and it would be better to be part of a team.

Anyhoo, about the progress of Paper Modeller:

I managed to fix the smoothing algorithm I mentioned in my previous entry: smoothing non-continuous surfaces. That's was a pretty hard task, but I also managed to "optimize" the algorithm while at it, so despite the more calculation needed for handling non-continuous surfaces, the algorithm is twice as fast in average. I even made a test mesh for it: screenie
Attached Image

I made a basic, context dependent GUI, which is (by chance) very similar to 3ds Max's right side toolbar. I have lots of glitches with the GUI, it will be a lot of work to get it right (programming and "user experience"-wise). But at least I can move on and I don't have to shit around with ""hotkey"" input.

Reimplemented selection and added some new features. I think my "biggest strength" is the ability to introduce useful features (if it is an ability at all...), so in the end, I think I have some pretty useful selection stuff (maybe more useful than Max's).

Implemented "sheet selection", so different sheets (where the unfolded geometry will be put) can be selected for display and for editing. It's much like the upside down tabs in AutoCAD like software than 3ds Max's multi-viewport layout.
The main problem with it that it's a bit out of place: it's openGL rendered, self implemented stuff, not a win32 widget thing.

Maybe I'm just being pessimistic.

That's pretty much it for now, screenies:
Attached Image
Attached Image
Attached Image
Attached Image
Attached Image

Paper Modeller 03 with smoothing control

Posted by , 19 July 2011 - - - - - - · 646 views

Maybe it isn't worth a journal entry, but I successfully implemented the automatic smoothing generation feature for shading the models. It was a necessary visual feature (totally smooth or totally faceted display was not only ugly, but disturbed the spatial sense too) but it was also important for editing/unfolding.

Smoothing is usually controlled through smoothing groups.
Smoothing groups are polygon/triangle based: every triangles have one or multiple smoothing group ID:s which control the vertex normal calculation: which triangle normals should be used for calculating the final interpolated vertex normal. The ID:s can be assigned in multiple ways (I guess every mayor 3D modelling applications support that), manually assigning values or "auto smooth" features with angle threshold.
It is important to note that .obj format doesn't support multiple smoothing group ID:s per triangle (or at least some exporters doesn't).

My approach is different: the automatic smoothing generation is edge based. That means in some cases the output of my algorithm and triangle/polygon based algorithms will differ even with the same angle threshold (see first image: the windows of the car).
Attached Image
This approach suits better the needs of a paper modeller, where some sharp edges are need to be perforated or etched before bending. These bend-edges are displayed too (see images below), and will affect the automatic unfolding feature. It will be possible to manually define bend-edges too.

The algorithm starts with simply detecting bend-edges (by the angle of the two side triangles), then comes the ugliest son-of-a-bitch hacked algorithm ever, it's such an ugly bitch that I even made a screenie about it:
Attached Image
It works nicely but in some degenerate cases it doesn't give good results (shared vertex but non-continuous surface), I'll deal with it some time...
See the screenshots with different angle thresholds below.

Some smaller stuff: I managed to use DevIL for loading images as textures, thanks for the posts in the other entry and Gaiiden for putting some focus on that entry!
Added "zoom to extent" feature, and vertex normal display (it's only useful for debugging the smoothing).
Replaced the jaw/pitch camera rotation to "arcball" rotation (or whatever it's called..).

Next: *sigh* selection and undo/redo *sigh*. I'll dig myself into Aardvajk's journal....
Maybe some refractoring too *sigh*

Attached Image Attached Image Attached Image Attached Image

Attached Image Attached Image
Attached Image

Paper Modeller 02

Posted by , 11 July 2011 - - - - - - · 574 views

Implemented texture coordinate loading. Took 2 hours due to a stupid mistake... Edge data is constructed and displayed: Only the polygon edges will be selectable. Edge flow will be important for selecting edge loops and edge rings. The .obj parser can parse polygons with arbitrary number of sides and converts the polygon to a triangle fan (in the most straightforward way).

.obj files and textures (non power of two textures too, but only 24 bit bmp textures yet) can be loaded separately with the file menu. I still haven't decided if I implement better material loading, or it will stay this way. After all, it's not an .obj viewer, so only the diffuse texture that's interesting. And I think I won't bother with material files and multiple texture files at all.

screenies: the pale dotted lines represent the non selectable lines (non polygon edges). (the texture is a totally random image of a random kitty, but the texture coordinates are just fine)
Attached Image Attached Image Attached Image

Paper Modeller 01

Posted by , 09 July 2011 - - - - - - · 638 views

I decided to make an entries about the progress with screenshots. So here it ising:
(a power out killed my well parsed literature masterpiece so I have to rewrite the post but in a simpler way):
  • window + menubar (only decoration yet)
  • openGL
  • 3D grid + basic camera control (rotate, zoom, pan, dolly)
  • coordinate system icon
  • wavefront .obj loading
    • vertex data
    • face data: with polygons, to preserve "edge flow" which is a very important thing in polygon modelling. But polygons are converted to triangle fans, polygon stuff will be maintained through the edges (selectable/non-selectable or visible/non-visible).
    • vertex normal calculation: I don't think I'll bother with smoothing groups, the mesh should be split accordingly. I use the angles between the incoming edges as the weights of the triangle normals, I think that gives the best results. The loader always recalculates vertex normals and ignores normal data in the .obj file.
  • smooth + vertex display of the mesh
The next things would be texture data loading, splitting the mesh according to the texture coordinates (so only one indexing, geez I don't speak English).

Or not, I'm not sure yet. spliting the mesh would probably screw unfolding, and the user wouldn't know why. So maybe I should only split the mesh for render, if I ever implement vertex buffer whatevers.

And of course loading the texture(s). *sigh*, I have to look for an image loader library for C. And atlas the textures *sigh*.

Sorry for the crap language, the former version was better (...)

Attached Image

EDITED some typos...

Back to Paper Modeller (?)

Posted by , 07 July 2011 - - - - - - · 612 views

So, I'll try to exploit unemployment and work on the paper modeller again. That means restarting from scratch again, reusing pure functions (yeah, I have some of those!!!!44).
I'll try to discipline myself again and write better code, but I guess I'll fail again. I even fell with the very first step: I just can't think of a way to avoid using globals with WindProc (and the number will grow, since it's an event based program).

The CNC file editor was a great experience, I learned a lot with it.

Fucking boring journal post.

Anyhoo, I'll do my best (...) to be a programmer this time.

New genius MMORPG idea

Posted by , 06 May 2011 - - - - - - · 702 views

Well, not MMORPG but genius 2D game idea anyway.

The Pissing in earthquake ftw.

You are a little kid called Timmy or Ricky or whatever, whose mother is a cleaning maniac. Little Timmy/whoever needs to piss, but an earthquake happens! The mission is to piss into the toilet and let as few drops of pee fall outside the toilet as possible. The pissing force and the angle is controlled real time by the mouse position (by dragging an arrow), while it's possible to walk and jump around. The pee would be simulated as accurately as possible.

If There's too much pee outside the toilet, Timmy's mom will slap him on his face and game over! The game would be level based. Harder levels mean more obstacles, moving objects like cats or whatever, more pee, things fall in the way of the pee, Timmy is further away from the toiled etc. As Timmy empties his pee, the velocity decreases, and finally, the pee will only come in bursts rather randomly and then just dripping at the end (we all know this thing...).

A possible improvement would be to add running to the toilet: a timer, while Timmy can hold back his pee, then if he runs out of time, pee would spray randomly, which would make the game even harder (since too much would be out of the toilet already). If the mouse is released, piss stops coming (need to improve this part of the idea), but the timer would restart again.

So! If anyone is interested in the idea, go ahead and steal it! (I'll be pretty pissed if you make trillions with this, but ftw)

Note: I'm not fully serious here (I just had the idea 10 minutes ago), and I'm in work obviously and my employer is wondering why I am giggling and
drooling like a retard kid....

January 2017 »

151617181920 21

Latest Visitors