|
1921
|
Player / Games / Re: Cloned!
|
on: February 16, 2009, 11:24:47 PM
|
On Kongregate their game description says: A RTS that is a cross between Harvest Massive Encounter and Vector TD! Though I must say: it's totally not the same game. The key ingredient of HME, the energy management and overloading, isn't there at all. (Another game that is sort of the same game, but in slow motion, is Settlers. Man I love Settlers 2) And even though this probably totally sucks for you personally, and you do deserve credits and cold cash, I don't think it's all bad. I do believe that the world will be a better place if people steal eachother's ideas. It becomes a process of iteration, where good ideas inspire others to do new and creative things. If we get a wave of HME-like games, and even a new TD-genre, I'll be thrilled!
|
|
|
|
|
1923
|
Player / Games / Re: Hotseat Multiplayer Freeware: The Best
|
on: February 16, 2009, 06:46:39 PM
|
Lord Tim already mentioned it, but used strange name for it. He also forgot to mention that it's actually one of the best multiplayer games ever! Achtung, die Kruve! (also known as Zatacka) - Achtung, die Kurve! is an excellent Snake/Tron-like game. Every player controls constantly moving "vehicle" that produces a solid trail. The goal of the game is to force the other players crash into a wall or trail. Instead of turning in right angles, as is typical in Snake/Tron-games, you have a large turning radius. The trails contain small holes, preventing the game from getting locked down. This means that most of the time you don't get the typical Tron-gameplay, where each player tries to survive in their own solitary, separate area. The scoring system gives you points for every opponent you beat in a round, making sure every second of survival counts. However, what makes this the perfect multiplayer game is that drawing penises in front of your enemies is a viable tactic for winning! Year: 1995 (possibly) Developer: Unknown Hotseat: 2-6 Players Platform: Windows A failed round of Achtung, die Kurve!
|
|
|
|
|
1924
|
Developer / Design / Re: Design Challenge/Exercise
|
on: February 16, 2009, 01:24:35 AM
|
here's a discrete concept for someone else to try:
multiplayer game with time control
A slow, methodical strategy game. When two characters collide, the younger one always dies, or if their ages are equal then they both die. The objective is to catch your opponent's past self and kill him. A game of temporal cat-and-mouse ensues. The longer the game goes on, the more past each player has, and the harder it is to protect your entire timeline from the enemy. Now go make it! 
|
|
|
|
|
1927
|
Developer / Business / Re: Selling out
|
on: February 15, 2009, 08:53:19 PM
|
I personally can't enjoy games where I constantly have a gnawing feeling that other players - who can afford to spend more money - always will have an advantage over me. Consequently, I don't play such games. Is it wrong for you to sell out? Not really. You should do what you need to do. But for me, it will ruin the game 
|
|
|
|
|
1928
|
Player / General / Re: DF succession game - Crazydrinkers [Year two]
|
on: February 15, 2009, 07:37:31 PM
|
Sounds fabulous! And losing is fun, so there should be no shame in not being able to complete the full year. Today is monday and it's been 18 days since the game was handed over. Hideous, will you pick up where Lucaz left off? 
|
|
|
|
|
1929
|
Player / General / Re: DF succession game - Crazydrinkers [Year two]
|
on: February 15, 2009, 04:54:02 PM
|
I'm starting to think that one year is a bit too long. There have been two previous attempts at succession games on these forums that I know of (Rimmute and Boulderchannels). Both failed early on, because people simply failed to check in. Would it be possible to change the time limit to "six in-game month" or "one real-life weak" or perhaps "one in-game year or one real-life week, whichever comes first"? Or just "play as long as you've got a flow going, then quickly hand it over". I just think something needs to be done to prevent the task from becoming too overwhelming. At least in future games. That being said: I want in! 
|
|
|
|
|
1931
|
Community / Commonplace Book / Re: From Primordial Egg [Finished]
|
on: February 15, 2009, 12:52:36 AM
|
|
I played all the games (that would run on my computer) but failed to vote. But I thought I'd mention that I really, really enjoyed playing this one. It was the only one I felt compelled to play through to the end. Excellent work!
|
|
|
|
|
1934
|
Community / Procedural Generation / Re: Conway's Game of Bigotry [FINISHED]
|
on: February 11, 2009, 03:01:51 PM
|
Yeah, I actually did sign up just to ask.  I'm on Mac OS X, so I'll have to compile the game myself, but now the source code link appears broken.  I hope there aren't any Windows-specific dependencies. Awesome!  Fixed the source code link. (I need to get a real host, but this will have to do for now.) I tried to take great care to avoid everything Windows-specific, but I may very well have messed up somewhere. You may need to get a OSX-version of Glut, but it shouldn't be a problem and the code won't be affected. If I find the time I'll try to compile it under my Ubuntu. Please tell me if you can get it to work on your own! 
|
|
|
|
|
1935
|
Community / Procedural Generation / Re: Conway's Game of Bigotry [FINISHED]
|
on: February 10, 2009, 06:48:25 AM
|
Hey! I've fixed the link in the first post. Mikoangelo, did you join the forum just for ask for the game? Anyway, I'm really flattered that you asked.  The game actually doesn't play all that well. But if you find someone to play with, who knows how to play the game without the pre-defined patterns, you can get pretty intense matches. I also added a link to the source code, if anyone is interested. It is in the form of a Visual Studio 2005 project, but everything that matters is in the actual code (and not hidden in some secret, magic project file). I will try to make a new version in the future, though most changes will be cosmetic. I want to: - fix the blur on the in-game images (and I now know how)
- add a proper menu system
- allow users to remap the keys
- add an ingame pattern editor
- clean up the code
- comment the code properly
- possibly tweak the gameplay so it will work better in competition
- ...and when I become an awesome programmer, possibly add an AI (not likely)
|
|
|
|
|
1936
|
Community / Commonplace Book / Re: Homecoming
|
on: December 01, 2008, 11:45:58 AM
|
We're so sorry. We are committed to the project and are working hard to bring you something as soon as possible. 
|
|
|
|
|
1937
|
Developer / Technical / Re: Multi-threading OpenGL
|
on: November 22, 2008, 08:20:01 AM
|
Indeed. I did understand your suggestion but I have no idea how to actually do it your way. I'm using the soil library which loads one image at a time. Splitting the image in small pieces takes about 11 button presses in Photoshop. Relatively speaking, keeping track of hundreds of small texture pieces will be a breeze too. But if you can tell me how to read stuff in pieces that would be really cool. 
|
|
|
|
|
1938
|
Developer / Technical / Re: Multi-threading OpenGL
|
on: November 22, 2008, 05:44:49 AM
|
Thanks for all the answers! To begin with I'll try to clarify some things. What I am able to do: I can create new threads. I can share objects between these threads and put locks on them when needed. What I want to do: Load textures from image files without having the game freeze during the loading process. Loading a texture takes approximately one second. How I'm trying to do it: Putting the loading process in a separate thread. (Note: I do not intend to do any drawing from the loading thread. I just want to handle the loading of the image files from the secondary memory (hard drive) to OpenGL textures in the primary memory (RAM)). How I think it should be done: According to this article http://hacksoflife.blogspot.com/2008/02/creating-opengl-objects-in-second.html (and the others I have found) there is one way to go with this. You create two separate OpenGL contexts, one for the thread that loads and creates the objects (like textures, vertex buffer object etc.) and one for the rendering.. Once the loader-thread has created the objects it "sends" them to the main thread, where they are used. How platform independent code for this could look: eerrrrr... eehhh... ummmm.. ? As soon as I try to use the image loading code in the new thread I get a segfault  I don't know how to create a new OpenGL context in the new thread either, glut doesn't seem to allow it..? Help!
You have given me suggestion for some alternative solutions: Hajo suggested that I could use SDL. It's quite possible that SDL has support for multi-threaded loading. Have you used SDL for loading OpenGL texture objects or do you know of a tutorial dealing with this? LtJax came with a very interesting suggestion. I just realized that I can use photoshop to cut up the images in tiny pieces (using the slice tool). This way I can load a tiny piece of the texture every frame, preventing the game to completely freeze. In no way an ideal solution, but it's currently my main back-up-plan.
|
|
|
|
|
1939
|
Player / General / Term paper
|
on: November 21, 2008, 05:51:22 PM
|
|
I'm taking a course called Software Engineering at my university. I'm supposed to write a term paper on a random topic related to software design. I'm going to write a paper on "Independent Game Design", if I can convince my professor that it's a valid topic.
I need proper sources for my initial abstract. I'm wondering if anyone can point me towards any good books or published papers on independent game design. Perhaps texts about the process of creating games with a small budget and in small teams, or anything else that could be relevant to the topic.
Thanks!
|
|
|
|
|