Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

285 Neutral

About Tesseract

  • Rank


  • Twitter
  1. Click the image to play with this one. This is my first go at the "Propagation" portion of the UnOfficial Four Elements Contest. Not complicated; click and drag your mouse around the bitmap and watch the particles spawn and flow downhill. Simple mechanic: each particle sniffs each of the eight pixels around it, and goes toward the darkest one. If the darkest neighbor is the same color as the current pixel, it stops moving. I check the neighbors from upper left to lower right, so there is a bias toward the upper left in case of a tie between more two or more neighbors. Adding vector data to the particles will take care of that. It will take a lot more work to make this usable in a game. It also gave me an idea for making a simple erosion simulator which will make the terrain much more realistic...if it works.
  2. I haven't had much time to code this past week, but I have thought quite a bit about how the different parts of the game will fir together. Right now I am sorting out the logic of re-creating a biosphere from scratch, and how the elements of propagation and evolution will fit in. Research has led me in some interesting directions; I picked up a college text-book on botany, and spent a good long time browsing Wikipedia, specifically looking at Ecological Succession. I also grabbed a book called Where Our Food Comes From: Retracing Nikolay Vavilov's Quest to End Famine. Put together, these sources prompted me to change the focus of my game, from re-starting a global ecology, to something much more local - create a regional ecosystem, over the course of some decades or centuries, which will ultimately be (a) self-sustaining, and (b) be able to support a population of recently-thawed humans. Yeah, the basic story/plot is kind of weak at the moment, but the technical issues with putting such a game together are quite interesting. Because I have no experience in ecology, biology or botany, I found myself at a loss as to where to begin. So I have started an exercise which has previously helped me make sense of information architecture problems: make a long list of simple, declarative statements, then order them, add to them, and flesh them out, until I have a design document. Here is my "ecology" list at the moment: All plants require sunlight. All plants more complex than algae require a solid surface for growing All plants have chlorophyll, which reacts with sunlight to create nutrients Algae scattered on ice will trap sunlight, and heat up enough to melt ice Lichen can grow on bare rock Moss can grow on bare rock and in minimal soil Plants growing on bare rock will begin to erode the rock, creating sand. When plants die, they mix with the sand to create soil The more complex the plant, the more nutrients it needs to grow The larger the plant, the stronger its root system needs to be. Taller plants need deeper roots. The more surface area a plant has, the more sunlight it collects. More leaves mean the plant needs to be either wider or taller Faster growth means faster propagation Faster growth means shorter life Faster growth means more fragile plant Plants can propagate by water, wind, or mechanical means Plants which propagate by water can only propagate downstream Plants which propagate by air can only propagate in the direction of the wind Plants which propagate by air can disperse to a wider area Plants which propagate by water propagate more densely in any given area Fitness is the likelihood that an individual will produce viable offspring Plants need to reach a certain maturity before they can reproduce Plant populations need to reach a certain density before they can effectively propagate plants need to reach a level of complexity where they create fruit before they can be considered food plants plants which contain sufficient nutrients to be worthwhile as food must get nutrients from the soil Obviously this list is simplified to meet the needs of the game. I am sure any botanists reading this are shaking their heads. Anyway, I consider it a good start. More updates to follow.
  3. Wow, has it been a long time since I posted here. The Unofficial Four Elements Contest ("UFEC") brought me out of hibernation, and has inspired me to put together a casual game. Here are the specs, thus far: Title: Thaw Platforms: PC/Mac/Linux Technology: Adobe Flash Requirements: Flash Player 10, for web release version. Genre: Simulation/Strategy Type: 2d/top down Players: 1 Story (at the moment): You have been awakened from cryo after a cold snap which left the planet encased in ice for a great many years. Using what is left of your technology, you need to start seeding the planet with the basic necessities to re-start the global ecology, starting with the simplest of plants and working up to a self-sustaining biosphere which can support humans. Along the way you need to establish local ecologies which can flourish in a post ice age/apocalypse environment. This includes specifics like creating energy sources, melting through the ice, discovering caches of seeds and DNA remnants, engineering new species for the new climate, and finding out why things ar eso much worse than the Powers That Be expected them to be when they put you in the freezer. I am still working out the fine points of this. I want it to be story driven as much as it is even driven, with the plot unfolding as the player makes decisions and begins to alter the environment. It might be much too big a game for a five month contest, but with appropriate use of procedurally- and user- generated content, I should be able to get something done. This will be the third Four Elements competition for which I have started a game. I will be taking ideas from those projects, plus myriad code snippets from several years of experiments and projects, and see if I can get something together by the end of March which people will want to play. My first step - and the only one, so far - is to set up a structure which keeps the event listeners to an absolute minimum, so I can eliminate the possibility of conflicts before the first screen is created. To that end, I have created two simple delegation methods - one which listens for timer updates and the other which listens for keyboard input. These functions receive the events, figure out the current state of the game, and forward the event to the appropriate manager. Code is here: private function mainLoop(e:TimerEvent):void { switch(GAME_STATE) { case "travel": worldManager.update(); break; case "manage": technologyManager.update(); break; case "fight": combatManager.update(); break; case "dialogue": storyManager.update(); break; default: break; } e.updateAfterEvent(); } private function onKeyEvent(e:KeyboardEvent):void { switch(GAME_STATE) { case "travel": worldManager.receiveKeyboardEvent(e); break; case "manage": technologyManager.receiveKeyboardEvent(e); break; case "fight": combatManager.receiveKeyboardEvent(e); break; case "dialogue": storyManager.receiveKeyboardEvent(e); break; default: break; } } With that simple structure in place, I don't have to worry about different parts of the game falling out of synch, or constantly turning listeners on and off in different parts of the game, depending on what the user is doing at any given moment. It is easy to expand this system as the game becomes more complex, and debugging is greatly simplified. Also, it requires a lot less code. One caveat: I have not actually built a system like this before, so I don't know if there are any hidden traps in this approach. Time will tell. I occasionally post screen shots in the UFEC screenshot thread, and will post updates to the progress of the game itself in its own thread. More development-specific updates will be posted here. Well, heck. I will probably just post everything here.
  4. After some self-enforced exile from the game dev world, I am diving back in. After some extremely helpful feedback over at the Kongregate community I am working on TriGaVoid 1.5, which will be more of a professional effort and include things like achievements, power-ups, and lots and lots of optimizations. I plan to post regular updates, code snippets, and links to the prototype as I make progress. We will see. I haven't been completely lazy during the past two months; I made a generative art toy which feels to me like the seed for a much larger, more involved project. If my job goes away, as so many seem to be doing these days, I might even have time to work on it.
  5. Quick note: I just uploaded a new tutorial to Kongregate. This one explains - with code - the formulae I used to build the Bad Guys in my game TriGaVoid. The code I used is actually about seven years old. Back when I was first learning javascript and "Dynamic" HTML, I tried to reproduce some of the experiments from Assembler.org, which lead me to the Famous Curves Index. After a quick couple of weeks of teaching myself basic trigonometry, I had the first few up and running in a thing I called the Trigonometron. Once I started learning Actionscript, back in 2002, I quickly ported everything over to Flash, and spent from then to now looking for something to do with the code. So here it is. All of the code is Actionscript 3, which should make it easily portable to pretty much any other language. At least, all of the actual movement algorithms should work - with syntax tweaking - in any language which supports math. Enjoy!
  6. While I am on a roll I will post a link to my first published Flash tutorial: Creating Textures using Perlin Noise and the Threshold Function in Actionscript. Though it is in Actionscript, the ideas presented should carry over easily enough to any language. Enjoy!
  7. Hello, everyone. Long time no see! Suffice to say, the final quarter of 2008 treated me very poorly in all aspects of my life. But that is not important now: I am here to announce the launch of my first game over at Kongregate: TriGaVoid! I used many of the lessons I learned here about simple/casual game design, spent some free time over the holidays coding, and voila! Something I can be proud of. I hope you all enjoy.
  8. Tesseract

    Shaded Landscape, Experiment 1

    Thanks, Jotaf! I am planning to eventually have the ants wander around on some photos; I just need to find the time to write the code.
  9. Click here to see the interactive version. Source code here. It took a little longer than I thought, and I am not entirely sure what specific thing I did which made things work right, but things are working right. Now that I have the last graphic treatment in place I am going to take a few days away from this project and work on a couple of simple game ideas which came up when I was playing with the earlier Perlin Noise experiments.
  10. Tesseract

    Perlin Ants

    I took a short break from working on the game engine to play around with a mash-up of Perlin Noise-based landscapes, and Langton's Ants. Click here for the single color version. Click here for the three color version. In other news, I figured out how to apply simple shading to the landscape in the tile game, and I should be able to post something sometime this weekend.
  11. Click here to play with the prototype. This latest update includes an event which fires every time the player moves to a new tile on the world map. Right now it returns the x and y coordinates and the elevation (based on color) of the current tile. Using that information, I will be able to set up a random-ish encounters table which takes into account environment (e.g. elevation), and factors such as distance from civilization, latitude, and the like. But for right now the deciding factor will be elevation. The system will work something like this: Each creature in the creature library has, as two of its attributes, a minimum elevation and a maximum elevation. This ensures that critters will not appear in inappropriate places - nobody wants to fight a squid on top of a mountain. It just isn't done. This is pulled from the design document: There are attributes for time and date, which I am not currently using. If the particular game whcih I build with this engine requires it I can add times of the day and seasons, and adjust encounters accordingly. This will make things more complicated however; right now I am looking at a single variable - elevation - to sort out the encounter. Each additional factor doubles the amount of data to sort through before the fighting begins - Day or night? Spring or winter? Close to a city? In water or on land? Full moon? You get the idea. In my 4E5 project (unfinished) I played around with having "sources" for different raw materials - salt, iron, wheat, and the like - the distance from which determined the likelihood of coming across a random deposit, and also helped set the buy/sell cost of the material while trading. This could also be determined by elevation, if I really want to go to town on the granularity of the game.
  12. Click here to see the live version. (When will we be able to embed Flash movies in our posts?!?) This is a quick update to the tile-based game engine experiments of months past. This update includes the procedural generation of individual tile textures. Each texture is the same, but I have colored them to reflect the colors of each pixel in the world view. After the initial tile is created, I clone it 256 times - one for each color in the color map - and overlay the Perlin noise with the solid color. Voila! 256 colored tiles. All in all, I would call it a great success. The next step will be to modify the way I color the tiles in order to make them more vibrant. I am sure there is a way of doing so which will not be too processor intensive. Right now, I think it looks just a bit like Ultima IV.
  13. Click here to play with the prototype. I have just updated the Gyruss clone to make it run more consistently across a wide variety of browser/platform combinations, and also to allow for more intense action if need be. I used this technique from 8-Bit Rocket, and in my linked prototype the game runs at a consistent ~30 frames per second. If you let it run for a minute, eventually there will be 100 enemies swirling around shooting at you. One caveat: I tried playing this on an old POS Mac OSX laptop, and it crashed the browser so severely that I had to give it the 3-finger salute to the the OS back. I took a couple of weeks off of thinking about this thing to do some playing with various cellular automata experiments. The links to these are below: Langtons's Ant Langtons's Ant Hexagon pattern Langtons's Ant 3d pattern Random 2d cellular automata Enjoy!
  14. Click here to play. Another week gone by, and a few updates have been made. Nothing too earth-shaking this time, just a graphic update: A rotating background. This was entirely too difficult to implement, or I was vastly over-thinking the problem. Probably the latter. Because I am blitting several bitmaps together to draw the screen I needed to come up with a method to get the bitmap which comprises the background to rotate. In this instance, a simple background.rotation++ wouldn't work; I needed to do a little matrix math to rotate the actual bitmap data, rather than the bitmap which contained the bitmap data. And that caused its own issues; namely, that the original bitmap - which was simply a square with some Perlin noise applied - had subsequently been redrawn around polar coordinates, and then twisted, and expanded so that the resulting circle was as large as the diagonal of the original square, rather than the sides. And somewhere in there the origin point for the bitmap data became, well... not the center of the circle. Obviously, I eventually got everything figured out. But not before dealing with a couple of hours of this:
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!