Over on Indie Game Reviewer Callabrantus has taken the time to check out and give his thoughts on AI War's recently released Light of the Spire expansion.
Some of the more tasty bits:
"This latest entry brings with it a healthy variety of new content and features, most notably the campaign modes, while staying true to the core experience...Even without the expansion sets, AI War is the type of game one never truly masters...Here, the concept of “casual” cowers in fear."
Read the full review on IGR.
Thursday, March 31, 2011
A Valley Without Wind: First Public Release Now Beta, New Lighting Video and Perma-Death Journal
Arcen Games would like to pass along word of a new video, developer journal and new release info for its procedurally-generated action adventure title A Valley Without Wind.
We have made the significant decision to push back the first public release of AVWW to what we had originally planned for beta. For one, we feel it'd be a giant mistake to release any playable build of the game before there's more to do in it than fight Skelebots and destroy trees.
Not that killing Skelebots isn't fun, but that's not all this game is about; not by a long-shot. The choice to make the beta version the first publicly available build of the game allows us to add dynamic goals that players will actually care about, a fuller realization of our perma-death feature, and more ways the player can make an impact on their world -- along with much more overall content and variation. Those items, we feel, are now essential for the game before it can be considered playable and on sale to the public.
What this means for AVWW's release schedule is that the public alpha that was to arrive in April is now officially canned in lieu of a public beta. We'll determine a release date for it once we're closer to the completion of the aforementioned features. To sum it all up: A Valley Without Wind's first public pre-release will bring a much more content rich experience, we just need some time to put it together. The 1.0 launch remains unaffected by these changes and is still currently on target for October of this year, and of course we'll continue to update on the development of the game when new features and improvements are added.
Arcen head Chris Park explains and explores all facets of the matter in full detail on the Games by Design blog: http://christophermpark.blogspot.com/2011/03/first-public-version-of-valley-without.html
Making weighty decisions for AVWW doesn't mean we haven't been working on it! Check out our latest video showcasing the improved lighting in the game (along with a full explanation on where we were, and how we got to this point with the new method): http://christophermpark.blogspot.com/2011/03/valley-without-wind-pre-alpha-8-new.html
Chris also dives into the game's interesting take on perma-death and what he hopes it'll mean for the player's overall experience: http://christophermpark.blogspot.com/2011/03/valley-without-wind-whats-deal-with.html
A Valley Without Wind is currently set for official release on PC and Mac in October, with a public pre-release build coming earlier in the year.
About Arcen Games
Arcen Games entered the PC indie scene in 2009 with their cult classic AI War: Fleet Command, which was named the 40th best-reviewed PC game of the year by MetaCritic. Their second year was a busy one, seeing the release of The Zenith Remnant, the first full expansion for AI War; Tidalis, an innovative block-based puzzle with casual appeal and hardcore depth; and Children of Neinzul, a micro-expansion for AI War with all profits benefiting the Child's Play charity, of which Arcen is a platinum sponsor.
AI War's third and largest expansion Light of the Spire marked Arcen's first release of 2011, and now the company has shifted its focus and excitement to the development of A Valley Without Wind. Originally a one-man shop, Arcen Games has grown to have half a dozen part-time or fulltime contributors to its various titles.
We have made the significant decision to push back the first public release of AVWW to what we had originally planned for beta. For one, we feel it'd be a giant mistake to release any playable build of the game before there's more to do in it than fight Skelebots and destroy trees.
Not that killing Skelebots isn't fun, but that's not all this game is about; not by a long-shot. The choice to make the beta version the first publicly available build of the game allows us to add dynamic goals that players will actually care about, a fuller realization of our perma-death feature, and more ways the player can make an impact on their world -- along with much more overall content and variation. Those items, we feel, are now essential for the game before it can be considered playable and on sale to the public.
What this means for AVWW's release schedule is that the public alpha that was to arrive in April is now officially canned in lieu of a public beta. We'll determine a release date for it once we're closer to the completion of the aforementioned features. To sum it all up: A Valley Without Wind's first public pre-release will bring a much more content rich experience, we just need some time to put it together. The 1.0 launch remains unaffected by these changes and is still currently on target for October of this year, and of course we'll continue to update on the development of the game when new features and improvements are added.
Arcen head Chris Park explains and explores all facets of the matter in full detail on the Games by Design blog: http://christophermpark.
Making weighty decisions for AVWW doesn't mean we haven't been working on it! Check out our latest video showcasing the improved lighting in the game (along with a full explanation on where we were, and how we got to this point with the new method): http://christophermpark.
Chris also dives into the game's interesting take on perma-death and what he hopes it'll mean for the player's overall experience: http://christophermpark.
A Valley Without Wind is currently set for official release on PC and Mac in October, with a public pre-release build coming earlier in the year.
About Arcen Games
Arcen Games entered the PC indie scene in 2009 with their cult classic AI War: Fleet Command, which was named the 40th best-reviewed PC game of the year by MetaCritic. Their second year was a busy one, seeing the release of The Zenith Remnant, the first full expansion for AI War; Tidalis, an innovative block-based puzzle with casual appeal and hardcore depth; and Children of Neinzul, a micro-expansion for AI War with all profits benefiting the Child's Play charity, of which Arcen is a platinum sponsor.
AI War's third and largest expansion Light of the Spire marked Arcen's first release of 2011, and now the company has shifted its focus and excitement to the development of A Valley Without Wind. Originally a one-man shop, Arcen Games has grown to have half a dozen part-time or fulltime contributors to its various titles.
Pantai Soka
Selain keindahan alamnya, Pantai Soka juga memendam seribu satu keajaiban alam dengan dongeng-dongeng purbakala. Di sana terdapat sebuah batu karang dikelilingi pasir dan air laut, berukuran lebih kurang 3 m, disebut "Payuk Kebo Iwa." Payuk berarti periuk, jadi itu adalah Periuk milik Kebo Iwo. Di sebelah Baratnya, disamping Pura Luhur Serijong, terdapat batu karang yang persis seperti dapur penduduk asli, berukuran lebih kurang 1 x 20 m. Disanalah Kebo Iwa memasak dengan mempergunakan periuknya tersebut.
Dilihat dari mata awam, hal ini sangat masuk akal. Periuk yang besar dan Kebo Iwo yang konon menurut legenda adalah seorang pemuda Bali dengan ukuran tubuh yang tinggi besar, tegap dan sakti. Pura Luhur Serijong, dibangun hampir bersamaan dengan Pura Rambut Siwi di Jembrana dan Pura Tanah Lot, yakni pada abad ke XVI Masehi oleh Pedanda Bawu Rauh, serta mempunyai status yang sama.
Lokasi
Pantai Soka terletak di desa Antap, Kecamatan Selemadeg. Jarak tempuh dari Denpasar 45 Km dan dari Gilimanuk 84 Km, dilewati oleh jalan utama Jawa-Bali. Kendaraan yang lewat di sini sangat padat dari pagi sampai malam hari. Di sebelah Timur pantai Soka ini terdapat sebuah goa di tebing batu karang, disebut goa Bulung Daya ditempati banyak burung walet. Di bagian sebelah Barat terbentang kebun kelapa sepanjang pantai, di sini sudah ada sebuah penginapan "Balian Beach Bungalow" dan sungai (Tukad) Balian adalah tempat "Rufting" terbaik di Bali.
Fasilitas
Di pantai tersedia tempat parkir dan beberapa warung tempat makan-minum untuk melepaskan lelah. Pada hari raya dan bulan penuh (Purnama) pantai ini dipadati oleh pengunjung dan oleh umat Hindu yang sedang melaksanakan upacara keagamaan. Bagi yang senang memancing ke laut, dapat bergabung dengan nelayan setempat, memakai perahu tradisional yang memakai mesin tempel atau layar.
Silakan tambahkan ke daftar wisata anda...
Perancak
Bagi sebagian orang ketika mendengar nama ini, teringat akan sebuah sirkuit yang berlevel nasional dan kerap menjadi tuan rumah kejuaraan motor cross dan road race. Namun ada lagi keindahan yang tersimpan di sini.Obyek Wisata Perancak merupakan sebuah obyek wisata yang indah, bibir pantainya yang dihiasi perahu-perahu nelayan merupakan suatu keindahan tersendiri untuk dinikmati.
Setiap tahun obyek wisata perancak dijadikan tempat untuk lomba sampan dayung tradisional yang biasanya dirangkaikan dengan HUT kota Negara.Di Desa Perancak terdapat tempat Pelestarian Penyu Laut yaitu “Kurma Asih” karena Pantai Perancak sangat cocok untuk tempat bertelor bagi Penyu. Ditempat ini wisatawan dapat menikmati keindahan pantai dan melakukan kegiatan pelepasan Tukik/Anak Penyu ke Laut.Disamping tempat pelestarian Penyu di desa Perancak juga terdapat Pusat Riset Teknologi Kelautan, stasiun Bumi NOAA (National Oceanic and Atmospheric Administration) yang berfungsi untuk menentukan titik-titik berkumpulnya ikan di laut yang dipantau dari satelit. Pada lokasi yang sama wisatawan juga dapat melihat hamparan tumbuhan bakau yang beraneka ragam jenisnya. Di desa Perancak juga terdapat tempat penyulingan air laut menjadi air mineral yang berkadar Oksigen Tinggi yaitu Megumi.
Tertarik untuk mengunjungi objek wisata ini? Mungkin anda harus segera memasukkan dalam agenda liburan di Bali mendatang.
Tuesday, March 29, 2011
Dev-corner: 48-hour Reddit Game Jam Postmortem
Last weekend, I had the distinct pleasure of "leading" a large (20+) team of dedicated artists, coders, and writers in the creation of a wonderful (if a bit rough around the edges) 2D platform game called Last Escape. I put "leading" in quotes, because my position was more of organizer and first-among-equals (save for a couple of executive vetoes, mostly to save time and keep things moving). It was an amazing experience, and I'm very proud to have been a part of it. It was also highly educational, so I'm going to try and take stock of what we did right and what we did wrong, and write about it here, in hopes that it helps other teams develop games later on.
First off, a little more about the project. Last Escape was ambitious from the outset. Before the project began, we decided that we were going to work with C++ instead of Flash or JavaScript. This decision was of a practical nature; the two coders who had committed the largest amount of time to the project ahead of time (myself and FLARE creator Clint Bellanger) were the most comfortable with game development on C++.
The art in Last Escape is a combination of digital painting and pixel art. This effect is a bit jarring, but given the 48-hour time constraint, we had to make full use of all the artistic talent that was available to us. By and large, the vast majority of the art in the game is brand new, although we used existing assets where we could.
The basic premise behind Last Escape is that you're a person who has made a forced landing on an alien world due to your space ship being out of energy. The object of the game is to collect enough energy to power your ship, and, in the process, you run into some interesting alien ruins as well as some giant insects.
We started out by planning certain things beforehand. Since we didn't know what the prompt would be, we were somewhat limited in the planning we were able to do, but we did create a rough road map and timeline in advance to give us some indication of where we should aim. You can see these on the OGA forums. While we eventually fell a bit behind schedule on certain milestones, these documents were absolutely essential to keeping everyone motivated and on track, and I would not recommend undertaking a team based game design project without them, no matter how small.
When the contest theme was announced (it turned out to be "Energy"), we got the group together and immediately started brainstorming. I set the time limit on brainstorming for game ideas to 45 minutes, and we created a google document and began typing up a list of ideas as they came up. I attempted to steer the ideas in various directions to get a wide variety of suggestions, because I noticed that the discussion tended to get hung up on whatever game genre we were talking about at the time. We had to deliberately move things from puzzles to action to strategy, etc, and this is one place where I put on my "leader" hat in order to make that happen.
Following the brainstorming session, we put things to a vote. We went through a two-step voting process -- the first step was to ask for an approval vote, and just have everyone list all the ideas they liked. We used this to narrow the choices down to five. After that, we had a second vote and everyone picked their favorite. As an aside, it's interesting to note that in the craziness of brainstorming, I accidentally copied an idea from the main #opengameart IRC channel into the list, and that was the idea that was chosen. We discovered later on that the person who's idea we used was submitting their own entry into the game jam, so we ended up with two games that had a very similar premise. Fortunately, Xiphias3 (the originator of the idea) was cool with this, and said that we didn't have to mention it. We did anyway. :)
After the voting was finished, we put together a brief todo list and started frantically coding and doing art. This is where the real learning kicked in, and, knowing what I know now, there are some things I would probably handle differently.
First off, probably the biggest issue I ran into personally were merge conflicts. We hosted our project on GitHub and gave a number of people commit access. This was all well and good, but we were poorly organized (IRC can be a double-edged sword, since at any given time you have no way of knowing who is paying attention). Consequently, there were several situations where more than one person ended up working independently on the same feature or bugfix. I personally spent at least five hours cleaning up merge problems brought about by pieces of perfectly reasonable code interacting in unexpected ways.
As such, I would strongly advise anyone working on a large, rapid team project such as this one to have a web-based task tracking program ready to go at the outset. Google Docs proved inadequate for this.
Another related thing that I learned is that when you're managing a team of 20 people, the director doesn't really have time to code. This made things difficult for me, because I had already budgeted most of my time for coding, but as the project lead, people looked to me to know what was going on. On a large team, people generally need to be broken into smaller groups and given tasks; as such, you need someone whose job it is to know exactly who is doing what at any given time, and that's one area where I would make an effort to improve on if I were to ever undertake something like this again. Real task tracking software -- something simple with a quick and easy learning curve -- would have been very helpful for this.
One place where I would consider myself fairly successful is keeping a large group of people with differing interests and talents moving and motivated through a stressful project. Here's the advice I would give to anyone needing to do this:
While it may not be possible to avoid these sorts of issues completely, I would strongly recommend setting up your team with version control before you start coding.
Another issue we ran into with Git is that it tried to merge Tiled's XML map files. It did surprisingly well at this in most cases, but machine-generated XML isn't always the best thing for code merges, since it often needs to be in a very specific format. I'm guessing there's some way of turning this off for certain filetypes and forcing the merge to be resolved manually, as you would with a binary file.
Finally, some thoughts on coding. On one hand, you're trying to develop code quickly. On the other hand, you need to make your code easy to expand. Generally, you have two types of people -- the ones who want to code as quickly as possible due to the time limit, and the ones who want to code as cleanly as possible, time limits be damned. You need to be prepared to listen to both these sorts of people. Sometimes going off half-cocked can end up wasting a lot of your precious hours because you end up having to replace code or work around nasty hacks. On the other hand, when someone wants to take a while to do something the "right" way, you need to take stock of how long it will actually take them to finish what they're trying to do. If they can't do it within the allotted time, there's not much of a point, and they may as well have been working on something else.
What's important is that you be practical and strike a balance between the two. Your code needs to be at least somewhat maintainable and readable, or else you'll run into roadblocks long before your time is up.
So there you have it. No doubt some other folks from Team OGA will read this -- if you do, please chime in in the comments, and I'll try to work your thoughts into this post. As always, if anyone has any comments or questions, please feel free to post them. I tend to reply to almost everything. :)
A final, encouraging note: Last Escape has taken on a life of its own, and the project is continuing. You can follow our work (and download the latest version) on GitHub, although for the moment you'll need to compile it yourself. Here's the link:
https://github.com/lendrick/Last-Escape
Bart K.
OpenGameArt.org
First off, a little more about the project. Last Escape was ambitious from the outset. Before the project began, we decided that we were going to work with C++ instead of Flash or JavaScript. This decision was of a practical nature; the two coders who had committed the largest amount of time to the project ahead of time (myself and FLARE creator Clint Bellanger) were the most comfortable with game development on C++.
The art in Last Escape is a combination of digital painting and pixel art. This effect is a bit jarring, but given the 48-hour time constraint, we had to make full use of all the artistic talent that was available to us. By and large, the vast majority of the art in the game is brand new, although we used existing assets where we could.
The basic premise behind Last Escape is that you're a person who has made a forced landing on an alien world due to your space ship being out of energy. The object of the game is to collect enough energy to power your ship, and, in the process, you run into some interesting alien ruins as well as some giant insects.
We started out by planning certain things beforehand. Since we didn't know what the prompt would be, we were somewhat limited in the planning we were able to do, but we did create a rough road map and timeline in advance to give us some indication of where we should aim. You can see these on the OGA forums. While we eventually fell a bit behind schedule on certain milestones, these documents were absolutely essential to keeping everyone motivated and on track, and I would not recommend undertaking a team based game design project without them, no matter how small.
When the contest theme was announced (it turned out to be "Energy"), we got the group together and immediately started brainstorming. I set the time limit on brainstorming for game ideas to 45 minutes, and we created a google document and began typing up a list of ideas as they came up. I attempted to steer the ideas in various directions to get a wide variety of suggestions, because I noticed that the discussion tended to get hung up on whatever game genre we were talking about at the time. We had to deliberately move things from puzzles to action to strategy, etc, and this is one place where I put on my "leader" hat in order to make that happen.
Following the brainstorming session, we put things to a vote. We went through a two-step voting process -- the first step was to ask for an approval vote, and just have everyone list all the ideas they liked. We used this to narrow the choices down to five. After that, we had a second vote and everyone picked their favorite. As an aside, it's interesting to note that in the craziness of brainstorming, I accidentally copied an idea from the main #opengameart IRC channel into the list, and that was the idea that was chosen. We discovered later on that the person who's idea we used was submitting their own entry into the game jam, so we ended up with two games that had a very similar premise. Fortunately, Xiphias3 (the originator of the idea) was cool with this, and said that we didn't have to mention it. We did anyway. :)
After the voting was finished, we put together a brief todo list and started frantically coding and doing art. This is where the real learning kicked in, and, knowing what I know now, there are some things I would probably handle differently.
First off, probably the biggest issue I ran into personally were merge conflicts. We hosted our project on GitHub and gave a number of people commit access. This was all well and good, but we were poorly organized (IRC can be a double-edged sword, since at any given time you have no way of knowing who is paying attention). Consequently, there were several situations where more than one person ended up working independently on the same feature or bugfix. I personally spent at least five hours cleaning up merge problems brought about by pieces of perfectly reasonable code interacting in unexpected ways.
As such, I would strongly advise anyone working on a large, rapid team project such as this one to have a web-based task tracking program ready to go at the outset. Google Docs proved inadequate for this.
Another related thing that I learned is that when you're managing a team of 20 people, the director doesn't really have time to code. This made things difficult for me, because I had already budgeted most of my time for coding, but as the project lead, people looked to me to know what was going on. On a large team, people generally need to be broken into smaller groups and given tasks; as such, you need someone whose job it is to know exactly who is doing what at any given time, and that's one area where I would make an effort to improve on if I were to ever undertake something like this again. Real task tracking software -- something simple with a quick and easy learning curve -- would have been very helpful for this.
One place where I would consider myself fairly successful is keeping a large group of people with differing interests and talents moving and motivated through a stressful project. Here's the advice I would give to anyone needing to do this:
- First off, have a leader. You need someone with veto power in order to keep things moving in a good direction.
- As the leader, understand that it's not "your" project -- it's everyone's. This means that it's not your job to tell people what the direction of the project is; rather, your job is to facilitate the team finding a direction and keep things from getting sidetracked.
- Democracy rules. The main direction of your project is often best decided on by brainstorming and then a vote. This gives everyone a chance to make their case and have their idea judged by the entire team, and not just the leader.
- Large groups of people can tend to get sidetracked very easily in discussions. As such, it is very important that you limit discussion time in advance and make sure that you designate a time by which brainstorming is over, and a time shortly thereafter when you have to reach a final decision. If you don't set up these times in advance, people who are trying to make their case may assume that you want to silence them. Plus, it's not particularly fair to people if they're not aware when their time to speak is going to be over. To avoid putting yourself in the position of even appearing partial, it's best to set time limits in advance.
- If possible, keep votes in the open. When I took a vote, I asked everyone to send me a private message with their vote (because it was easiest to keep track of), but also vote publicly, and then verify my count.
- Remember, your project depends on your team. People will come and go, as is natural with any project, but people will be a lot more likely to leave if they feel that their input has no chance of being heard. This is to some extent reiterating what was said above, but I cannot stress enough that leading is about facilitating and not ruling with an iron fist!
- Where possible, be tool-agnostic. Not everyone is comfortable in the same software. Some people may prefer to use closed-source tools, and it's important to accommodate these folks if you want to keep your dev team happy.
- You should not be format-agnostic. You need to decide in advance what formats are acceptable for your media files. Stick to well implemented open standards, and make sure people understand that they are responsible for providing their files in these formats. This means that media editors that can't output to these formats are essentially out, unless the people using them have a quick and clean way of converting both to and from their proprietary formats. The rest of the team should not be burdened with these conversions.
- Version control is an absolute must. As much as I complained about merge conflicts, things are a lot worse if you're sharing a code base without version control. I recommend using a system with web-based tools that as many people as possible are comfortable with. Most coders prefer Git, and by and large GitHub turned out to be a good choice for us (with one major caveat that I'll get into below).
- Tiled (the Qt-based FOSS tile map editor) was absolutely excellent for putting tile maps together quickly. I strongly recommend it to any project considering making a 2D tile-based game.
- Try to avoid reinventing the wheel when possible when writing your code. You may have specific requirements that no existing game engine meets, but there are plenty of frameworks you can build your engine on that provide things like easy, cross-platform graphics, sound, and I/O. We used SFML to great effect, but there are plenty of other good choices.
While it may not be possible to avoid these sorts of issues completely, I would strongly recommend setting up your team with version control before you start coding.
Another issue we ran into with Git is that it tried to merge Tiled's XML map files. It did surprisingly well at this in most cases, but machine-generated XML isn't always the best thing for code merges, since it often needs to be in a very specific format. I'm guessing there's some way of turning this off for certain filetypes and forcing the merge to be resolved manually, as you would with a binary file.
Finally, some thoughts on coding. On one hand, you're trying to develop code quickly. On the other hand, you need to make your code easy to expand. Generally, you have two types of people -- the ones who want to code as quickly as possible due to the time limit, and the ones who want to code as cleanly as possible, time limits be damned. You need to be prepared to listen to both these sorts of people. Sometimes going off half-cocked can end up wasting a lot of your precious hours because you end up having to replace code or work around nasty hacks. On the other hand, when someone wants to take a while to do something the "right" way, you need to take stock of how long it will actually take them to finish what they're trying to do. If they can't do it within the allotted time, there's not much of a point, and they may as well have been working on something else.
What's important is that you be practical and strike a balance between the two. Your code needs to be at least somewhat maintainable and readable, or else you'll run into roadblocks long before your time is up.
So there you have it. No doubt some other folks from Team OGA will read this -- if you do, please chime in in the comments, and I'll try to work your thoughts into this post. As always, if anyone has any comments or questions, please feel free to post them. I tend to reply to almost everything. :)
A final, encouraging note: Last Escape has taken on a life of its own, and the project is continuing. You can follow our work (and download the latest version) on GitHub, although for the moment you'll need to compile it yourself. Here's the link:
https://github.com/lendrick/Last-Escape
Bart K.
OpenGameArt.org
Monday, March 28, 2011
AI War Beta 5.009, "Desync II: The Resyncing," Released!
This one fixes yet another desync that Fleet and Tssbackus were the sole folks to be able to find. Turns out you had to save your game under just the right circumstances in the middle of a big battle to get this one, which not many people presumably do, hence the rarity.
This release also includes some stronger desync detection methods based on a simple hash method on the clients and host, to make desyncs quicker to find and easier to reproduce. Hopefully that was the last desync for a while, though!
And lastly, this sharply nerfs the health of a lot of the spire core shield generators that the AI has, which I'm sure many people will be quite happy about. Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
This release also includes some stronger desync detection methods based on a simple hash method on the clients and host, to make desyncs quicker to find and easier to reproduce. Hopefully that was the last desync for a while, though!
And lastly, this sharply nerfs the health of a lot of the spire core shield generators that the AI has, which I'm sure many people will be quite happy about. Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
A Valley Without Wind: Interiors, Lighting, Crafting, New Regions, Character Stats, And Perma-Death (And Much More!)
Arcen Games is downright ecstatic to share the latest updates, screens and video footage for its procedurally-generated action adventure title A Valley Without Wind. We haven't shared in a few weeks, so there's a ton of new stuff to show and tell including interiors, lighting, crafting, playable/NPC Skelebots, lava and desert regions, perma-death implementation and lots more.
Interiors -- the last remaining world building focus for the game -- have been added, though at the moment we'll be needing the proper time to populate them. These structures don't have any electrical power, making most indoor exploring pretty dark. This is where lighting comes into play, as several darker areas both interior and exterior can be lit by various spells and objects to grant better visibility and ease the search.
There's been plenty of character focus this past update as well: Perma-death and crafting in their basic forms are now in place, along with a working system for producing a unique set of stats for each individual character. A neutral Skelebot that works as both playable character and as a non-hostile NPC, a dynamic character name generator, and NPC dialog have also been thrown into the mix.
New music, regions, improvements to shadows and particle effects, a new lamp object, and two new spells: "shrink" and "flash of light," round out the sizable list of update highlights. Check out the latest gameplay video showing off everything mentioned and more here (in HD): http://www.youtube.com/watch?v=24qWu6TPdpE&hd=1
17 new screenshots can be found on the AVWW feature page: http://www.arcengames.com/w/index.php/games/avww-features
And to make up for the lengthy radio silence, we have three new developer journals available. A breakdown of the video as well as a detailed explanation of the aforementioned features, additions and improvements: http://christophermpark.blogspot.com/2011/03/valley-without-wind-pre-alpha-7.html
Arcen head Chris Park goes into his approach to the design process of AVWW as compared with past works: http://christophermpark.blogspot.com/2011/03/a-valley-without-wind-design-process.html
Lastly, Chris discusses horizontal versus vertical game development phases, and wonders why indies can't explore the latter as much as they do the former: http://christophermpark.blogspot.com/2011/03/horizontal-vs-vertical-game-development.html
That's all for this process improvement focused update. Come back next time for an update heavier on the art advancement. A Valley Without Wind is currently set for official release on PC and Mac later this year, with a playable Alpha build available to customers who pre-order coming in April.
About Arcen Games
Arcen Games entered the PC indie scene in 2009 with their cult classic AI War: Fleet Command, which was named the 40th best-reviewed PC game of the year by MetaCritic. Their second year was a busy one, seeing the release of The Zenith Remnant, the first full expansion for AI War; Tidalis, an innovative block-based puzzle with casual appeal and hardcore depth; and Children of Neinzul, a micro-expansion for AI War with all profits benefiting the Child's Play charity, of which Arcen is a platinum sponsor.
AI War's third and largest expansion Light of the Spire marked Arcen's first release of 2011, and now the company has shifted its focus and excitement to the development of A Valley Without Wind. Originally a one-man shop, Arcen Games has grown to have half a dozen part-time or fulltime contributors to its various titles.
Interiors -- the last remaining world building focus for the game -- have been added, though at the moment we'll be needing the proper time to populate them. These structures don't have any electrical power, making most indoor exploring pretty dark. This is where lighting comes into play, as several darker areas both interior and exterior can be lit by various spells and objects to grant better visibility and ease the search.
There's been plenty of character focus this past update as well: Perma-death and crafting in their basic forms are now in place, along with a working system for producing a unique set of stats for each individual character. A neutral Skelebot that works as both playable character and as a non-hostile NPC, a dynamic character name generator, and NPC dialog have also been thrown into the mix.
New music, regions, improvements to shadows and particle effects, a new lamp object, and two new spells: "shrink" and "flash of light," round out the sizable list of update highlights. Check out the latest gameplay video showing off everything mentioned and more here (in HD): http://www.youtube.com/watch?
17 new screenshots can be found on the AVWW feature page: http://www.arcengames.com/w/
And to make up for the lengthy radio silence, we have three new developer journals available. A breakdown of the video as well as a detailed explanation of the aforementioned features, additions and improvements: http://christophermpark.
Arcen head Chris Park goes into his approach to the design process of AVWW as compared with past works: http://christophermpark.
Lastly, Chris discusses horizontal versus vertical game development phases, and wonders why indies can't explore the latter as much as they do the former: http://christophermpark.
That's all for this process improvement focused update. Come back next time for an update heavier on the art advancement. A Valley Without Wind is currently set for official release on PC and Mac later this year, with a playable Alpha build available to customers who pre-order coming in April.
About Arcen Games
Arcen Games entered the PC indie scene in 2009 with their cult classic AI War: Fleet Command, which was named the 40th best-reviewed PC game of the year by MetaCritic. Their second year was a busy one, seeing the release of The Zenith Remnant, the first full expansion for AI War; Tidalis, an innovative block-based puzzle with casual appeal and hardcore depth; and Children of Neinzul, a micro-expansion for AI War with all profits benefiting the Child's Play charity, of which Arcen is a platinum sponsor.
AI War's third and largest expansion Light of the Spire marked Arcen's first release of 2011, and now the company has shifted its focus and excitement to the development of A Valley Without Wind. Originally a one-man shop, Arcen Games has grown to have half a dozen part-time or fulltime contributors to its various titles.
Sunday, March 27, 2011
Tiny game: Stop the Zombies!
I'm so proud of saving more than killing...
I discovered a tiny and minimal Java/Processing game through future superstar game designer William: Stop the Zombies!
Launch nuke circles. Save human pixels. Kill zombie pixels. Or just kill everything.
The code is under a "Do whatever you want with it" license as far as I'm concerned, as it says in the code, it was based on someone else's code already.
It should be noted that that code will no longer compile due to changes in the Processing environment over the years.
Friday, March 25, 2011
AI War Beta 5.008, "Bad Robot, No Cookie," Released!
This one is pretty minor, just with a few balance tweaks and a bugfix related to minor factions and zombies going off their leashes too far. Since that one in particular is really important to some folks, we're going ahead and releasing the patch for this today. Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
Wednesday, March 23, 2011
AI War Beta 5.007, "Zombies Are For Eating My Neighbors," Released!
Well! I've been so focused on A Valley Without Wind for the last month and a half that I really wanted to make sure AI War was getting the love it needs. Keith has been doing updates for the game the last while, but we haven't had any really big burn-throughs of the mantis idea tracker in a while.
Yesterday was mostly all about one big desync, so today I wanted to spend one more day in AI War land and accomplish a variety of player-requested stuff, before I head back to AVWW tomorrow. That's what this release is all about, and it's the hugest one we've had since 5.0 came out.
One of the most notable things about this release is how minor factions and zombies have been tweaked. Friendly ones will still guard your planets somewhat, but they're also a lot more likely to strike out and help you deal with the AI on nearby planets. They thus act partly as a force for keeping the AI stalkers down, and for helping you with nearby offensives, rather than just being purely defensive. The hostile zombies and minor factions have also gotten some improvements, and thus the devourer golem is now better at actually devouring AI ships in most cases, for instance.
Spirecraft Penetrators have gotten quite a nerf, but before you panic remember that nothing is written in stone. These were clearly game-breaking in the hands of some players, though, so we went with some rather severe changes to work back up from there if this seems like too much. Some of the players who've seen the notes on this already are pretty optimistic this is a lot closer, though, so that's a good sign.
There have also been not one but two very notable performance improvements. Once massively reduces the load caused in big battles by gravitational effects, and the other makes control group adding/removing no longer cause crazy lag. For me, that's also seemingly really speeding up the loading of savegames.
Beyond that, there are a couple dozen other smaller bugfixes and balance tweaks. Oh, and a message that is sent now whenever an EMP or tachyon detonation occurs, which can help you detect breaches in your defenses when EMP guardians are secretly after you.
Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
Yesterday was mostly all about one big desync, so today I wanted to spend one more day in AI War land and accomplish a variety of player-requested stuff, before I head back to AVWW tomorrow. That's what this release is all about, and it's the hugest one we've had since 5.0 came out.
One of the most notable things about this release is how minor factions and zombies have been tweaked. Friendly ones will still guard your planets somewhat, but they're also a lot more likely to strike out and help you deal with the AI on nearby planets. They thus act partly as a force for keeping the AI stalkers down, and for helping you with nearby offensives, rather than just being purely defensive. The hostile zombies and minor factions have also gotten some improvements, and thus the devourer golem is now better at actually devouring AI ships in most cases, for instance.
Spirecraft Penetrators have gotten quite a nerf, but before you panic remember that nothing is written in stone. These were clearly game-breaking in the hands of some players, though, so we went with some rather severe changes to work back up from there if this seems like too much. Some of the players who've seen the notes on this already are pretty optimistic this is a lot closer, though, so that's a good sign.
There have also been not one but two very notable performance improvements. Once massively reduces the load caused in big battles by gravitational effects, and the other makes control group adding/removing no longer cause crazy lag. For me, that's also seemingly really speeding up the loading of savegames.
Beyond that, there are a couple dozen other smaller bugfixes and balance tweaks. Oh, and a message that is sent now whenever an EMP or tachyon detonation occurs, which can help you detect breaches in your defenses when EMP guardians are secretly after you.
Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
Tuesday, March 22, 2011
AI War Beta 5.006, "Raiders Of The Lost Desync," Released!
This one
fixes a desync that has been haunting my nightmares for months. It's been incredibly, incredibly rare, to the point that only a few players have ever even seen it. But those players could reproduce it reliably, while almost nobody else could reproduce it at all. Knock on wood, today that saga ends. One savegame provided by those same players most affected, Fleet and Tssbackus, has finally yielded a reproducible case for me. The battle was hard, but in the end we nailed it to the wall.
But that's not all! This release also has some pretty notable balance shifts around translocation shots, specifically so that your military command stations are now more powerful and less unwieldy. Also regeneration got a few tweaks to be less unwieldy when fortresses and force fields and such are around, too.
Lastly, and I'm sure most excitingly for the largest number of people, is some notable raid starship rebalancing. The raids have been split into two lines: one for the humans and one for the AIs, and the human ones have been made about 20% more powerful, while the AI ones are now only 50% as strong as the human counterparts. In other words, your raids will survive a bit longer against the AI missile guard posts, while the AI starships won't wreak quite so much havoc all through your systems when they come in any volume.
Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
fixes a desync that has been haunting my nightmares for months. It's been incredibly, incredibly rare, to the point that only a few players have ever even seen it. But those players could reproduce it reliably, while almost nobody else could reproduce it at all. Knock on wood, today that saga ends. One savegame provided by those same players most affected, Fleet and Tssbackus, has finally yielded a reproducible case for me. The battle was hard, but in the end we nailed it to the wall.
But that's not all! This release also has some pretty notable balance shifts around translocation shots, specifically so that your military command stations are now more powerful and less unwieldy. Also regeneration got a few tweaks to be less unwieldy when fortresses and force fields and such are around, too.
Lastly, and I'm sure most excitingly for the largest number of people, is some notable raid starship rebalancing. The raids have been split into two lines: one for the humans and one for the AIs, and the human ones have been made about 20% more powerful, while the AI ones are now only 50% as strong as the human counterparts. In other words, your raids will survive a bit longer against the AI missile guard posts, while the AI starships won't wreak quite so much havoc all through your systems when they come in any volume.
Enjoy!
This is a standard update that you can download through the
in-game updater itself, if you already have 4.000 or later. When you
launch the game, you'll see the notice of the update having been found
if you're connected to the Internet at the time. If you don't have 4.000 or later, you can download that here.
Dev-corner: Making unlicensed fan games -- why your time is better spent elsewhere
If you're reading this blog, you're probably like me in that you feel that current copyright law vastly overreaches in favor of the "content industry" and at the expense of culture as a whole. You may or may not also enjoy playing unlicensed fan-made games -- games that make use of IP from other games without the original owner's permission.
Today I'm going to talk about a little game company named Squaresoft(*). I liked Squaresoft -- a lot. I never cared for the company Squaresoft all that much one way or the other, but I loved their games (as you may have figured out from my previous blog entries). Chrono Trigger, in particular, is a game that frequently shows up in the ubiquitous "Top 10 video games of all time" lists and polls that gaming magazines like to do from time to time -- and it's also one of my personal favorites.
Among Chrono Trigger fans, the Chrono Trigger franchise is generally considered to have been treated very poorly by Squaresoft (now Square Enix). After a dissatisfying sequel, the only attention Chrono Trigger has received at all has been in the form of multiple re-releases, none of which have changed or added very much to the game.
Arguably, when a company can release the same thing over and over with minimal modification and keep selling it to people, it's become part of popular culture and the copyright ought to have expired, seeing as how the stated intent of copyright is to encourage innovation and progress as opposed to cultural stagnation. If you look at the original intent of copyright as stated in the U.S. Consitution (To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries), fan games actually look like a fairly good idea. If copyright is leading to cultural stagnation (remakes of remakes of remakes), maybe it's time to take culture into our own hands and follow the intent of copyright, rather than the letter of copyright, which exists in its present form entirely because of the lobbying efforts of the content industry [author's note: the intent of this blog entry is not to advocate violating copyright law -- there are other ways to fight bad laws. Please read to the end for the full context of this article before reaching any conclusions about what I'm writing here. Thanks!].
So yeah, I have nothing against fan games. Given that Chrono Trigger has received precisely zero attention from Square in recent years, I would have loved to have played Chrono Resurrection or Crimson Echoes, both of which looked very promising. If Square had purchased those games from the developers and sold them, I would have happily paid for them. Instead, Square hit them (and their fans, indirectly) with legal threats, shutting both projects down (a week before conclusion, in the latter case). By the letter of the law, this is entirely their right.
Now I don't know about anyone else, but this really cheezes me off. Square has taken something that I like and turned it into a cheap cash cow, and I'd really like to stick it to them, which is why I'm advocating against spending time making more fan games. Allow me to explain.
Fan games, like it or not, do these big fan-hating companies a favor by creating buzz about their games. Chrono Trigger is 12 years old now. I think maybe it's time that, instead of talking about it and spending our time adding to the Chrono Trigger mythos, we ought to relegate it to the black hole of dead copyrights. That's right, I think we ought to move on and stop doing Square a favor by spending time and effort promoting their games only to be slapped in the face for it. Instead, take that massive effort that you wanted to pour into a Chrono Trigger fan sequel (or whatever other game you want to make a fan sequel of) and use it instead to take the buzz away from big, fan-hating companies by either making something original or expanding on some content that's already available in the Creative Commons (like the many different Wesnoth campaigns).
Wouldn't it be nice to have some open franchises that people can expand on without fear of being sued? This is something that I think the Creative Commons needs more of, and there's nothing stopping us from doing it.
Bart K.
OpenGameArt.org
P.S. Feel like working on a game this weekend (3/25-3/28)? Join Team OGA and in the 48-hour Reddit Game Jam!
----
* Now Square Enix
Today I'm going to talk about a little game company named Squaresoft(*). I liked Squaresoft -- a lot. I never cared for the company Squaresoft all that much one way or the other, but I loved their games (as you may have figured out from my previous blog entries). Chrono Trigger, in particular, is a game that frequently shows up in the ubiquitous "Top 10 video games of all time" lists and polls that gaming magazines like to do from time to time -- and it's also one of my personal favorites.
Among Chrono Trigger fans, the Chrono Trigger franchise is generally considered to have been treated very poorly by Squaresoft (now Square Enix). After a dissatisfying sequel, the only attention Chrono Trigger has received at all has been in the form of multiple re-releases, none of which have changed or added very much to the game.
Arguably, when a company can release the same thing over and over with minimal modification and keep selling it to people, it's become part of popular culture and the copyright ought to have expired, seeing as how the stated intent of copyright is to encourage innovation and progress as opposed to cultural stagnation. If you look at the original intent of copyright as stated in the U.S. Consitution (To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries), fan games actually look like a fairly good idea. If copyright is leading to cultural stagnation (remakes of remakes of remakes), maybe it's time to take culture into our own hands and follow the intent of copyright, rather than the letter of copyright, which exists in its present form entirely because of the lobbying efforts of the content industry [author's note: the intent of this blog entry is not to advocate violating copyright law -- there are other ways to fight bad laws. Please read to the end for the full context of this article before reaching any conclusions about what I'm writing here. Thanks!].
So yeah, I have nothing against fan games. Given that Chrono Trigger has received precisely zero attention from Square in recent years, I would have loved to have played Chrono Resurrection or Crimson Echoes, both of which looked very promising. If Square had purchased those games from the developers and sold them, I would have happily paid for them. Instead, Square hit them (and their fans, indirectly) with legal threats, shutting both projects down (a week before conclusion, in the latter case). By the letter of the law, this is entirely their right.
Now I don't know about anyone else, but this really cheezes me off. Square has taken something that I like and turned it into a cheap cash cow, and I'd really like to stick it to them, which is why I'm advocating against spending time making more fan games. Allow me to explain.
Fan games, like it or not, do these big fan-hating companies a favor by creating buzz about their games. Chrono Trigger is 12 years old now. I think maybe it's time that, instead of talking about it and spending our time adding to the Chrono Trigger mythos, we ought to relegate it to the black hole of dead copyrights. That's right, I think we ought to move on and stop doing Square a favor by spending time and effort promoting their games only to be slapped in the face for it. Instead, take that massive effort that you wanted to pour into a Chrono Trigger fan sequel (or whatever other game you want to make a fan sequel of) and use it instead to take the buzz away from big, fan-hating companies by either making something original or expanding on some content that's already available in the Creative Commons (like the many different Wesnoth campaigns).
Wouldn't it be nice to have some open franchises that people can expand on without fear of being sued? This is something that I think the Creative Commons needs more of, and there's nothing stopping us from doing it.
Bart K.
OpenGameArt.org
P.S. Feel like working on a game this weekend (3/25-3/28)? Join Team OGA and in the 48-hour Reddit Game Jam!
----
* Now Square Enix
Dev-corner: Bart K. explains (and rants about) C/C++ pointers
C pointer syntax is an egregious design flaw. It's so bad, in fact, that it's solely responsible for multiple generations of programmers struggling with pointers, which frankly aren't that hard of a concept. I'm going to take some time today to explain pointers and, in the process, point out exactly what it is I can't stand about C/C++ pointer syntax. If you've never been able to wrap your head around pointers up until now, please give this a read, and hopefully you'll have a better understanding of them by the time you get to the end. I'll start with the basics (which you probably already know, but please bear with me).
Conceptually, a pointer is a variable that points to a location in memory, generally another variable. In C and C++, the actual data stored in a pointer is a memory address, which is just a number that signifies a particular location in memory. You can interact with a pointer in two ways. You can either look at the actual value of the pointer, which as I said is a memory address, or you can dereference the pointer (I'll explain this in a bit) and look at the value stored in the memory address that it's pointing to. A pointer can point to any type of variable. What's important to remember, though, is that pointers are their own type, distinct from the type of variable they're pointing to. A pointer to a character is not the same type as a character, which brings me to my first major beef with C/C++ pointer syntax. I'd like to introduce you to our recurring villain: the asterisk (*). The asterisk is a villain because he does two completely different things that both have to do with pointers, and he does them in a way that's very confusing. I'll address the first of these things now. Let's say you're declaring an integer.
Ha! If only.
A pointer is a type, the same way that character and integer are types. And yet, you don't declare them the same way as you declare other types. In fact, you can mix them in with declarations for different types, which is horribly inconsistent. C doesn't let you declare a mix of integers and characters on the same line -- so why can you declare a mix of integers and integer pointers on the same line?
Here's a better way to think of pointer declarations:
You either have to declare them one per line or declare them in a way that's conceptually misleading:
Now why on earth would I want to do that? Simple! When C looks at a pointer, it has no idea if the number contained in that pointer is a valid piece of allocated memory or just some random number that points off to Tux-only-knows-where. So what does C do? It just trusts you. It assumes, sometimes wrongly, that the number that's sitting inside that pointer is a valid memory address, and will happily write to that address if you tell it to, regardless of whether you've actually allocated memory there. Often times this will overwrite some of your code or another variable, and your program will continue humming happily along with no idea that it just made a huge mess of itself, only to mysteriously crash later on in a way that's very difficult to trace.
The thing about zero is the C knows it's not a valid address, so when you try to do something to memory address zero, your program will crash in an immediate, clean, and traceable way, which makes debugging a lot easier. If you're super hardcore and you're writing code on an embedded system where processor power is expensive, you can always remove the "= 0" bit later, although I wouldn't necessarily recommend it.
Another perfectly valid thing that you can do is just allocate the memory immediately when you declare the pointer instead of setting it to zero (or null, as they call it). In C, you'd do this with the malloc() function, and in C++, you'd use the 'new' operator. Here's how that looks:
Let's look at the C declaration again, this time in glorious technicolor!
A void pointer is useless on its own, since 'void' is a type that doesn't actually store anything. The intent, in this case, is that you cast the void pointer to whatever kind of pointer you're allocating, which brings us to the (int*) bit. If you're familiar with C and C++, you've probably already seen a cast, which is where you convert one type of variable to another. What we're doing in this case is telling it to change the void pointer that malloc() returned into an int pointer, so we can then set i equal to it. [edit: There are some good arguments in favor of omitting the cast, although my own C++ habits lead me to include it (not that one ought to be using malloc() in c++ anyway. See this stackoverflow link here: http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc (courtesy of )]
The last part, the sizeof(int) is telling malloc() how much memory to allocate. Since we want a pointer to an integer, we're allocating enough space to store an integer. Sizeof is a function that's built into C that returns the size in memory of the given type. Hence, sizeof(int) returns the size of an integer in bytes, which can vary depending on your system architecture.
So, to summarize, the above line of code creates an integer pointer, initializes an int-sized block of memory, and sets the new pointer to point to the memory address you just initialized. Ugh.
C++ is way simpler in this regard:
Hmm, now where'd that evil little bastard asterisk go? Ah, there he is! He's off dereferencing stuff!
So what does dereference mean, exactly? Well, remember how we when we initialized the pointer to zero, we were actually setting the address to zero, and not the contents of the address. One has to wonder at that point, how do we interact with the stuff contained within the address the pointer is pointing at? You dereference the pointer.
Dereferencing is an operator. An operator works essentially like a function, in that it takes a value and returns a different value. When you dereference an integer pointer, you get the integer that the pointer is pointing to in memory. When you dereference a character pointer, you get the character that the pointer is pointing to in memory. What's important to remember here is that when you dereference a pointer, it returns a different type than the pointer itself. This is because a pointer isn't the same type as the item that it points to -- a pointer to an integer is a pointer, not an integer.
So how do we actually dereference a pointer? We use... the asterisk! (dun dun DUNNNNN!)
This brings us to my other big problem with the asterisk. It does two completely different things. In one case, it signifies a type. In the other case, it's an operator. Let's look at this little piece of C++ code:
Now, some more explanation on why I like to write my pointer declarations the way I do ("int* i;" instead of "int *i;"). Look at this code here:
Instead, consider writing your code this way:
Finally, there's one last thing that you need to know about pointers: C and C++ don't care when pointers fall out of scope, which means that you need to explicitly get rid of them when you're finished with them. If you don't, the memory will never be de-allocated even once the pointer falls out of scope, so you won't know where it is to be able to de-allocate it or reference to it. This is what's called a memory leak, and it can cause your code to run slowly and eventually crash when it tries to allocate more memory than the machine has available. Delving deeply into memory allocation is beyond the scope of this blog entry, but here's a quick note about how to do it:
The other thing you'll notice here is that I say "i = 0;" after I deallocate the pointer in both cases. This is just so that C and C++ will know in the future that the pointer no longer points to a valid address. If (as is often the case) you're deallocating a pointer at the end of a function, it's generally okay to skip this step, since it's just going to fall out of scope anyway. However, if you want to be as safe and clean as possible, it doesn't hurt to just leave it in.
So there you have it. My pointers rant. I predict that there will be at least some comments below saying that you don't have to do it my way, and that it's shorter to mix your pointer and non-pointer declarations or that it's better to not initialize your pointers. If you're new to pointers, ignore those people. Once you've gained a solid understanding of them, you can start breaking the rules a little bit. What I've written here isn't necessary in terms of language syntax; it's simply a good set of habits for beginners to get into in order to keep their understanding of pointers as clear as possible and also ease debugging.
If you have questions, feel free to ask in the comments. If you see any real, actual errors in my code, please point them out.
Peace,
Bart K.
OpenGameArt.org
Conceptually, a pointer is a variable that points to a location in memory, generally another variable. In C and C++, the actual data stored in a pointer is a memory address, which is just a number that signifies a particular location in memory. You can interact with a pointer in two ways. You can either look at the actual value of the pointer, which as I said is a memory address, or you can dereference the pointer (I'll explain this in a bit) and look at the value stored in the memory address that it's pointing to. A pointer can point to any type of variable. What's important to remember, though, is that pointers are their own type, distinct from the type of variable they're pointing to. A pointer to a character is not the same type as a character, which brings me to my first major beef with C/C++ pointer syntax. I'd like to introduce you to our recurring villain: the asterisk (*). The asterisk is a villain because he does two completely different things that both have to do with pointers, and he does them in a way that's very confusing. I'll address the first of these things now. Let's say you're declaring an integer.
int i;Now you want to declare an integer pointer:
int *i;When you're declaring variables, the asterisk signifies that the variable is a pointer. Easy enough, right?
Ha! If only.
A pointer is a type, the same way that character and integer are types. And yet, you don't declare them the same way as you declare other types. In fact, you can mix them in with declarations for different types, which is horribly inconsistent. C doesn't let you declare a mix of integers and characters on the same line -- so why can you declare a mix of integers and integer pointers on the same line?
Here's a better way to think of pointer declarations:
int* i;Note that the space is now between the asterisk and the variable, so you're seeing "int*" instead of "int". This is conceptually a much better way to declare your pointers, because it stresses the fact that pointers are a distinct type. Unfortunately, here is where the evil asterisk rears his ugly head. Let's say now I want to declare two integers:
int a, b;Good so far. Now I'm going to declare two integer pointers:
int* a, b;Simple, right? No! The above code is wrong, even though it should be correct. What the above line of code actually does is declare 'a' as in int pointer and 'b' as a regular old integer, making it very difficult to treat pointers the way they ought to be treated -- as a separate type.
You either have to declare them one per line or declare them in a way that's conceptually misleading:
int *a, *b;The above code correctly declares two pointers but makes the evil asterisk appear to be in his other role, which I'll get to in a bit. First, one other important note about declaring pointers: Never leave them uninitialized. It's 2011 at the time of this post -- the overhead of initializing a pointer is utterly minuscule compared to the amount of time it will save you later on when it's time to debug your code. The real way to declare a pointer is like this:
int* i = 0;So, what am I doing here? Remember that a pointer is its own type, and it holds a memory address that points to a location in memory. When I set a pointer equal to something, I'm actually changing that memory address itself, not what's stored in the memory address. Hence, the above variable declaration is creating a pointer that points to memory address zero, which is invalid.
Now why on earth would I want to do that? Simple! When C looks at a pointer, it has no idea if the number contained in that pointer is a valid piece of allocated memory or just some random number that points off to Tux-only-knows-where. So what does C do? It just trusts you. It assumes, sometimes wrongly, that the number that's sitting inside that pointer is a valid memory address, and will happily write to that address if you tell it to, regardless of whether you've actually allocated memory there. Often times this will overwrite some of your code or another variable, and your program will continue humming happily along with no idea that it just made a huge mess of itself, only to mysteriously crash later on in a way that's very difficult to trace.
The thing about zero is the C knows it's not a valid address, so when you try to do something to memory address zero, your program will crash in an immediate, clean, and traceable way, which makes debugging a lot easier. If you're super hardcore and you're writing code on an embedded system where processor power is expensive, you can always remove the "= 0" bit later, although I wouldn't necessarily recommend it.
Another perfectly valid thing that you can do is just allocate the memory immediately when you declare the pointer instead of setting it to zero (or null, as they call it). In C, you'd do this with the malloc() function, and in C++, you'd use the 'new' operator. Here's how that looks:
/* In C: */Egad, what's all that craziness in the C version?
#include <stdlib.h>
int* i = (int*) malloc(sizeof(int));
/* In C++: */
int *i = new int;
Let's look at the C declaration again, this time in glorious technicolor!
#include <stdlib.h>First we'll take a look at malloc(). Malloc is actually a function that's declare in stdlib.h, which is why we included it. What malloc() does is allocates a block of memory and returns a void pointer to the allocated memory address.
int* i = (int*) malloc(sizeof(int));
A void pointer is useless on its own, since 'void' is a type that doesn't actually store anything. The intent, in this case, is that you cast the void pointer to whatever kind of pointer you're allocating, which brings us to the (int*) bit. If you're familiar with C and C++, you've probably already seen a cast, which is where you convert one type of variable to another. What we're doing in this case is telling it to change the void pointer that malloc() returned into an int pointer, so we can then set i equal to it. [edit: There are some good arguments in favor of omitting the cast, although my own C++ habits lead me to include it (not that one ought to be using malloc() in c++ anyway. See this stackoverflow link here: http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc (courtesy of )]
The last part, the sizeof(int) is telling malloc() how much memory to allocate. Since we want a pointer to an integer, we're allocating enough space to store an integer. Sizeof is a function that's built into C that returns the size in memory of the given type. Hence, sizeof(int) returns the size of an integer in bytes, which can vary depending on your system architecture.
So, to summarize, the above line of code creates an integer pointer, initializes an int-sized block of memory, and sets the new pointer to point to the memory address you just initialized. Ugh.
C++ is way simpler in this regard:
int *i = new int;When you say "new int" or "new char" or "new whatever" in C++, you're going through the same process as above, but in a much more readable way. The "new" operator looks at the type you gave it, initializes the memory for that type, and returns a pointer to it.
Hmm, now where'd that evil little bastard asterisk go? Ah, there he is! He's off dereferencing stuff!
So what does dereference mean, exactly? Well, remember how we when we initialized the pointer to zero, we were actually setting the address to zero, and not the contents of the address. One has to wonder at that point, how do we interact with the stuff contained within the address the pointer is pointing at? You dereference the pointer.
Dereferencing is an operator. An operator works essentially like a function, in that it takes a value and returns a different value. When you dereference an integer pointer, you get the integer that the pointer is pointing to in memory. When you dereference a character pointer, you get the character that the pointer is pointing to in memory. What's important to remember here is that when you dereference a pointer, it returns a different type than the pointer itself. This is because a pointer isn't the same type as the item that it points to -- a pointer to an integer is a pointer, not an integer.
So how do we actually dereference a pointer? We use... the asterisk! (dun dun DUNNNNN!)
This brings us to my other big problem with the asterisk. It does two completely different things. In one case, it signifies a type. In the other case, it's an operator. Let's look at this little piece of C++ code:
int* i = new int; // Here, I'm using * to signifyNotice that when I'm dereferencing i, I write (*i). The parentheses aren't strictly necessary, but they're another way to differentiate between using the asterisk to declare a pointer type and using it to dereference a pointer. In this case, the asterisk is an operator that operates on the pointer i and returns an integer variable that's located at the memory address i points to. I can then treat the result of that operation the same way I would treat any other integer.
// a type.
(*i) = 100; // Here I'm using * as the dereference
// operator. I'm setting the value of the
// memory address that i points to to 100.
cout << "This is a memory address: " << i << "\n";
cout << "This is the value of that memory address: " << (*i) << "\n";
Now, some more explanation on why I like to write my pointer declarations the way I do ("int* i;" instead of "int *i;"). Look at this code here:
int i = 0;These above two lines of code do the same thing, the only difference being that the first line also declares i as an integer before it sets it to zero. Now look at this code:
i = 0;
int *i = 0;Any reasonable person would assume (wrongly) that the two above lines of code do exactly the same thing, with the exception that the first line also declares i as a pointer. In actuality, the first line ("int *i = 0;") creates a pointer an initializes the address that the pointer points to to zero. The second line dereferences the pointer and sets the value stored at the address to zero. In any case, if you try running the above two lines of code in immediate succession, you'll get a null pointer error, because you've set the pointer to a null address.
*i = 0;
Instead, consider writing your code this way:
int* i = 0;Now, it's a lot more clear, despite the efforts of that thrice-damned asterisk, that the first line is initializing a pointer and the second line is dereferencing a pointer and setting the value of its address. (Note that running these two lines in immediate succession would still cause a null pointer error, for the same reason as above).
(*i) = 0;
Finally, there's one last thing that you need to know about pointers: C and C++ don't care when pointers fall out of scope, which means that you need to explicitly get rid of them when you're finished with them. If you don't, the memory will never be de-allocated even once the pointer falls out of scope, so you won't know where it is to be able to de-allocate it or reference to it. This is what's called a memory leak, and it can cause your code to run slowly and eventually crash when it tries to allocate more memory than the machine has available. Delving deeply into memory allocation is beyond the scope of this blog entry, but here's a quick note about how to do it:
/* In C: */The free() function is essentially the reverse of the malloc() function, in that it tells the computer you're no longer using the memory that the pointer points to. The computer then releases the memory back into the pool so that it can be allocated again. The C++ delete operator does the same thing. The only catch here is that if you're writing in C++, even though it's possible to use malloc() and free(), you can't mix malloc() with delete and new with free(), since internally they work in different ways. In C++, it's best practice to avoid malloc() and free altogether, and you should never delete a pointer allocated with malloc(), or free() a pointer allocated with new.
#include <stdlib.h>
free(i);
i = 0;
/* In C++: */
delete i;
i = 0;
The other thing you'll notice here is that I say "i = 0;" after I deallocate the pointer in both cases. This is just so that C and C++ will know in the future that the pointer no longer points to a valid address. If (as is often the case) you're deallocating a pointer at the end of a function, it's generally okay to skip this step, since it's just going to fall out of scope anyway. However, if you want to be as safe and clean as possible, it doesn't hurt to just leave it in.
So there you have it. My pointers rant. I predict that there will be at least some comments below saying that you don't have to do it my way, and that it's shorter to mix your pointer and non-pointer declarations or that it's better to not initialize your pointers. If you're new to pointers, ignore those people. Once you've gained a solid understanding of them, you can start breaking the rules a little bit. What I've written here isn't necessary in terms of language syntax; it's simply a good set of habits for beginners to get into in order to keep their understanding of pointers as clear as possible and also ease debugging.
If you have questions, feel free to ask in the comments. If you see any real, actual errors in my code, please point them out.
Peace,
Bart K.
OpenGameArt.org
AI War Review on i-luv-games.com
AI War 5.0 has received a glowing review from John over on i-luv-games.com. Here's some of our favorite words:
"I love that AI War is so different from every other Real-Time strategy out these days...No other strategy game that I’ve played treats the player to battles of such epic proportions...AI War: Fleet Command is a game that combines equal portions of quality and quantity. Not only is it a great game, but it’s a great big game. The battles, micromanagement, exploration, and discovery, will keep strategy gamers coming back."
Read the full review here.
"I love that AI War is so different from every other Real-Time strategy out these days...No other strategy game that I’ve played treats the player to battles of such epic proportions...AI War: Fleet Command is a game that combines equal portions of quality and quantity. Not only is it a great game, but it’s a great big game. The battles, micromanagement, exploration, and discovery, will keep strategy gamers coming back."
Read the full review here.
Monday, March 21, 2011
Dev-corner: Primer to texture creation
So you got this shiny 25 megapixel camera from your grandma last Xmas, and are getting bored making photos of your cat with it? Put it too a good use and make some environmental pictures and upload them to the burning well!
Wait, you don't have a rich grandma?... well take some photos from the website above (all public domain) and convert them to some nice textures to use in games ;)
Most importantly THE GIMP of course! Which is the premier open-source image manipulation software, that doesn't need to hide behind other commercial programs starting with Photo and ending with Shop (the other major FOSS contenders being Krita and MyPaint both in that order aiming more at digital paining then image manipulation. Oh and check out Alchemy for a funny sketching app.).
So what you will normally want to do is take a picture that shows a relatively flat surface with an interesting pattern and not too strong shadows (a cloudy day with a lot of diffuse lightning is best is you want to take photos yourself).
The guys at OpenClonk have a pretty nice tutorial about the manual process.
However nowadays there are also some smart algorithms available as GIMP plug-ins that try to do the job for you (with better or worse results, but it is for sure a lot faster). Here is an example with a short tutorial of what I did in less then 5 minutes with the perhaps most advanced of these plug-ins: Resynthesizer. Another, which looks good too but I have not tried is Texturize. However the latter does not remove your ex-girlfriend from your favorite holiday shots, so 1:0 for Resynthesizer :)
So your are working on the next super MMORPGFPS super Counterstrike killer with next-next-next-gen graphics? Well then your texture (don't go for anything lower that 10,240 x 10,240 for your toilet door textures!) needs a normal map of course!
But don't worry, there is a GIMP plug-in for that too!
Wait, you don't have a rich grandma?... well take some photos from the website above (all public domain) and convert them to some nice textures to use in games ;)
And of course FOSS is to the rescue and provides you with all the tools you need:
Most importantly THE GIMP of course! Which is the premier open-source image manipulation software, that doesn't need to hide behind other commercial programs starting with Photo and ending with Shop (the other major FOSS contenders being Krita and MyPaint both in that order aiming more at digital paining then image manipulation. Oh and check out Alchemy for a funny sketching app.).
Creating a seamless texture
So what you will normally want to do is take a picture that shows a relatively flat surface with an interesting pattern and not too strong shadows (a cloudy day with a lot of diffuse lightning is best is you want to take photos yourself).
Based on this you take a small part and try to make it seamless, e.g. make the edges fit to each other so that it can be tiled endlessly on a 3D surface in a game.
The guys at OpenClonk have a pretty nice tutorial about the manual process.
However nowadays there are also some smart algorithms available as GIMP plug-ins that try to do the job for you (with better or worse results, but it is for sure a lot faster). Here is an example with a short tutorial of what I did in less then 5 minutes with the perhaps most advanced of these plug-ins: Resynthesizer. Another, which looks good too but I have not tried is Texturize. However the latter does not remove your ex-girlfriend from your favorite holiday shots, so 1:0 for Resynthesizer :)
Making a normal map for your texture
So your are working on the next super MMORPGFPS super Counterstrike killer with next-next-next-gen graphics? Well then your texture (don't go for anything lower that 10,240 x 10,240 for your toilet door textures!) needs a normal map of course!
But don't worry, there is a GIMP plug-in for that too!
So there you have it... start making some texture packs and upload them to OpenGameArt!
Sunday, March 20, 2011
Monument Bajra Sandhi
Keseluruhan data daerah monumen berbentuk segi empat bujur sangkar dengan penerapan konsepsi Tri Mandala :
1. Sebagai Utama Mandala adalah pelataran/gedung yang paling ditengah
2. Sebagai Madya Mandala adalah pelataran yang mengitari Utama Mandala
3. Sebagai Nista Mandala adalah pelataran yang paling luar yang mengitari Madya Mandala
Bangunan gedung monumen pada Utama Mandala tersusun menjadi 3 lantai :
* Utamaning Utama Mandala adalah lantai 3 yang berposisi paling atas berfungsi sebagai ruang ketenangan, tempat hening-hening menikmati suasana kejauhan disekeliling monumen.
* Madyaning Utama Mandala adalah lantai 2 berfungsi sebagai tempat diaroma yang berjumlah 33 unit. Lantai 2 (dua) ini sebagai tempat pajangan miniatur perjuangan rakyat Bali dari masa ke masa. Di bagian luar sekeliling ruangan ini terdapat serambi atau teras terbuka untuk menikmati suasana sekeliling.
* Nistaning Utama Mandala adalah lantai dasar Gedung Monumen, yang terdapat ruang informasi, ruang keperpustakaan, ruang pameran, ruang pertemuan, ruang administrasi, gedung dan toilet. Ditengah-tengah ruangan terdapat telaga yang diberi nama sebagai Puser Tasik, delapan tiang agung dan juga tangga naik berbentuk tapak dara.
Kabupaten/Kota : Denpasar
12 Misteri Dunia Belum Terkuak
1. Misteri Atlantis (kerajaan yang Hilang)
Dua buah catatan dialog Plato (427-347 SM) yakni buku Critias dan Timaeus menguraikan kisah tentang sebuah kerajaan yang dikelilingi oleh tembok emas dan dipagari oleh dinding perak. Atlantis, begitu disebutnya, memiliki peradaban yang memukau. Di sana sudah terdapat pelabuhan dan kapal dengan perlengkapan yang sempurna, juga ada benda yang bisa membawa orang-orang terbang. Suatu saat ketika Atlantis baru akan melancarkan perang dengan Athena, tiba-tiba terjadi gempa dan banjir, tidak sampai sehari semalam Atlantis tenggelam tanpa bekas di dasar laut. Kerajaan besar yang memiliki peradaban tinggi itu pun lenyap dalam semalam.
Penyelidikan arkeolog menurut versi Plato, waku tenggelamnya Atlantis kurang lebih 11.150 tahun silam. Plato mengatakan bahwa kerajaan Atlantis diceritakan turun-temurun, bukan rekaan sendiri. Sejak ribuan tahun silam orang-orang menaruh minat yang sangat besar terhadap hal ini. Sejak tahun 1960-an sampai abad ke-20, laut bermuda yang terletak di bagian barat Samudera Atlantik berturut-turut diketemukan keajaiban yang menggemparkan dunia. Pada tahun 1968, beberapa penyelam melihat sebuah jalan besar yang dibangun menggunakan batu persegi panjang yang disusun sangat rapi. Tahun 1979, ilmuan Amerika dan Perancis menemukan piramida di dasar laut bermuda. Diperkirakan bangunan-bangunan bawah laut tersebut adalah sisa-sisa kerajaan Atlantis yang telah tenggelam.
2. Si Merah dari Antartika(gletser merah antartika)
Jika mendengar kata air terjun pasti kita akan membayangkan suatu tempat yang sejuk, banyak cipratan air yang indah. Tapi bagaimana kalau mendengar kata air terjun darah? Pasti ngeri sekali. Air terjun darah benar-benar ada di Antartika, daratan yang dilapisi oleh es. Air terjun tersebut mengalirkan air yang berwarna merah secara terus-menerus.
Saat pertama kali ditemukan oleh seorang ahli geologi pada tahun 1911, warna merah yang mengalir secara perlahan-lahan tersebut diperkirakan berasal dari ganggang merah. Agapan lain menyebutkan warna merah berasal dari gletser yang terkurung di bawah aliran air selama jutaan tahun dan mengandung mikroba-mikroba kuno yang terisolasi di bawah lapisan es yang sangat tebal, karena tidak ada cahaya, panas dan oksigen sehingga mengalami salinitas yang tinggi dan mengandung zat besi, dari zat besi itulah warna merah dihasilkan. Dengan adanya celah gletser, air keluar membentuk air terjun tanpa mencemari ekosistem di
dalamnya.
3. Garis-garis Misterius (Garis Nazca (Nazca Lines))
Garis Nazca (Nazca Lines) adalah garis-garis yang membentuk suatu bentuk gambar yang terletak di daerah gurun. Garis-garis Nazca akan terlihat jelas gambarnya jika dilihat dari langit karena garis-garis ini sangat besar. Nazca Lines diperkirakan dibuat antara 700 SM sampai 200 SM. Ratusan garis gurun Nazca membentu aneka gambar seperti monyet, ikan, laba-laba, burung dan kadal.
Pertanyaannya adalah bagaimana cara pembuatannya? Bisakah di peradaban kuno membuat sketsa yang sangat besar tanpa bantuan dari udara?. Menurut teori Joe Nickell, garis tersebut dapat dibuat dengan cara menyingkirkan kerikil-kerikil disekitar gurun. Dengan perhitungan yang akurat, saat kerikil dipindahkan, lapisan tanah yang berwarna kontras akan memberi kesan garis yang membentuk gambar. Pada tahun 1985, Johan Reihard menyatakan bahwa Nazca Lines dibuat untuk keperluan ritual keagamaan yang berhubungan dengan penyembahan dewa.
4. Lubang Api
Asal mula lubang api di Uzbekistanberawal sekitar 35 tahun lalu ketika seorang ahli geologis menggali tempat tersebut untuk mencari gas alam. Mereka menemukan satu jurang besar di bawah tanah. Peralatan penggalian pun ikut masuk ke dalam jurang yang ternyata dipenuhi gas beracun. Untuk mencegah penyebaran gas beracun, mereka menyalakan api. Akhirnya lubang dipenuhi api dan anehnya sampai sekarang api tersebut masih sangat terlihat terutama saat matahari tenggelam.
5. Benda terbang tak teridentifikasi (Unidentified Flying Object)
UFO adalah akronim dari Unidentified Flying Object atau dengan kata lain benda terbang yang tidak bisa di identifikasikan oleh pengamat. Benda terbang itu kebanyakan berbentuk menyerupai piring dan memiliki kecepatan terbang yang tinggi, bisa menempuh ratusan kilometer per jam. Penampakan UFO sudah menjadi topik paling hangat dibicarakan diseluruh dunia. Pada tahun 1951 di Texas, para profesor beserta mahasiswa melihat formasi cahaya aneh sedang melintas.
Begitu seterusnya muncul kisah penampakan UFO di seluruh dunia termasuk Indonesia. 10 februari 1953, penduduk kota Magelang melihat empat buah benda kecil mengkilap yang bergerak perlahan-lahan hingga menghilang di balik awan. Pada tahun 1973, wisatawan Jepang, Ryo Terumoto yang sedang berkunjung ke gunung Agung Bali tidak sengaja memotret benda berbentuk cakram tersebut. Penampakan pun terjadi di kediaman salah satu maestro seni Indonesia, Guruh Soekaro Putra. Pada tanggal 23 Mei 1981, penjaga rumah
melihat makhluk setinggi 1,2 meter yang kemudian menghilang bersamaan dengan munculnya benda bercahaya. Paginya dau disekitar penampakan UFO menjadi berwarna coklat seperti tersengat hawa papas.
6. Motif unik misterius (Crop Circle)
Crop Circle adalah suatu bentuk lingkaran dan bentuk-bentuk lain seperti geometri denga ukuran besar/ luas di ladang pertanian khususnya gandum. Ada juga yang berbentuk menyerupai kalajengking, bunga matahari, lebah, dll. Di Inggris, Canada, Amerika, Australia dan Jepang banyak ditemukan fenomena Crop Circle. Biasanya fenomena ini muncul di musim panas saat ladang pertanian ditumbuhi dengan tanaman. Bentuk geometri itu kadang berupa lingkaran-lingkaran atau bisa juga berbentuk rangkaian gambar yang unik, menunjukkan bahwa pembuatnya adalah makhluk yang cerdas. Banyak yang mengaitkan Corp Circle dengan kemunculan UFO. Sebuah Video yang berhasil merekam proses terjadinya Crop Circle menunjukkan bahwa Corp Circle terbentuk hanya dalam waktu 20 detik saja, padahal besarnya mencapai puluhan meter.
7. Lubang Biru (Great Blue Hole)
Great Blue Hole atau lubang biru terletak di timur daratan Belize (Amerika). Karena terletak di dekat daratan, maka air di pesisir terbuang kedalam Great Blue Hole. Bentuknya bulat dan berdiameter lebih dari 305 meter, sedangkan kedalamannya mencapai 146 meter. Lubang Biru ini merupakan hasil runtuhan berulang-ulang dari suatu sistem gua batu kapur yang terbentuk pada saat permukaan laut yang lebih rendah ketika terjadinya zaman es berjuta tahun lalu.
Pada tahun 1971, Jasquer Yves ( Penyelam terbaik dari 4 situs penyelam di Bumi) menyelam kedalam lubang untuk mengukur kedalamannya dan memeriksa stalakmit dari dinding yang menggantung. Keindahan dari lubang biru yaitu kedalamannya menciptakan warna nila yang menyebabkan struktur yang diberi nama lubang biru. Selain itu juga terdapat banyak ikan seperti Angel Fish, Butter Flyfish, ikan hamnlpis dan ikan kerapu kecil yang menyapu permukaan air ketika tenang sehingga menyebabkan berkilauan ketika diterangi matahari membuat keindahan yang luar biasa.
8. Segitiga unik (segi tiga bermuda)
Segitiga bermuda disebut juga segitiga setan yang terletak di samudra atlantik seluas 1,5 juta mil persegi atau 4 juta kilometer persegi dan membentuk garis segitiga antara bermuda, wilayah teritorial Britania Raya sebagai titik disebelah utara, Puerto Riko, teritorial Amerika Serikat sebagai titik disebelah selatan dan Miami, negara bagian Florida, Amerika Serikat sebagai titik disebelah barat. Segitiga bermuda sangat misterius karena banyak kapal-kapal yang hilang saat melintasi kawasan tersebut.
Menurut teori Badan Penyelidikan Geologi Amerika Serikat pada tahun 1981, hilangnya pesawat terbang dan kapal laut karena dikawasan tersebut banyak terdapat gas methana. Ada yang megatakan bahwa segitiga bermuda adalah pangkalan UFO, sehingga kendaraan apapun yang melintas teritorial tersebut akan diculik dan terhisap. Ada pula yang mengatakan bahwa penyebabnya dikarenakan oleh adanya sumber magnet terbesar di Bumi yang tertanam di bawah segitiga bermuda, sehingga logam berton-ton pun dapat tertarik ke dalam.Meskipun banyak teori, namun tidak ada yang memuaskan sebab munculnya tambahan seperti benda asing bersinar yang mengelilingi pesawat sebelum kontak dengan menara pengawas terputus dan pesawat menghilang.
9. Bangunan Megah Termisterius (piramid)
Piramida Mesir adalah sebutan untuk piramida yang terletak di Mesir yang dikenal sebagai negeri piramida. Bangunan megah itu umumnya digunakan sebagai makam raja-raja mesir kuno. Namun demikian, berabad-abad lalu piramida sering digunakan sebagai sasaran penjarahan dan perampok makam karena para raja-raja membawa kekayaan dan segala macam artefaknya. Piramida tidak dibuat sembarangan sehingga batu-batu besar itu bisa tersusun dengan rapi dan kokoh tanpa bahan perekat. Sebuah pertanyaan besar tentang siapa pembuat piramida itu dan bagaimana mungkin batu-batu itu bisa disusun hingga menjulang tinggi tanpa bahan-bahan perekat. Agaknya pertanyaan itu masih belum menemukan jawabannya.
10. Hujan Aneh (hujan darah)
Tidak ada yang menyangka, pada 25 Juli 2001 hujan yang seharusnya putih itu berubah. Negara bagian Kerala di India diguyur hujan aneh berwarna merah hingga september 2001. Lebih dari 500.000 meter kubik air berwarna merah tercurah ke Bumi. Awalnya ilmuan mengira warna merah itu dihasilkan oleh pasir gurun namun setelah diteliti lebih lanjut ternyata unsur merah di dalan air hujan tersebut adalah sel hidup yang bukan berasal dari bumi. Komposisi sel tersebut terdiri dari 50% karbon, 45% oksigen dan 5% unsur lain seperti besi dan sodium, sel tersebut juga membelah diri. Karena partikel merah tersebut adalah sel hidup, maka banyak yang mengajukan teori. Teori pertama menyebutkan bahwa batu meteor yang meledak di udara telah membantai sekelompok kelelawar di udara namun teori ini dibantahkan karena tidak disertai bukti-bukti yang mendukung seperti kelelawar yang berjatuhan dari langit. Dengan menghubungkan antara suara ledakan dan cahaya yang mendahului
hujan darah, Louis mengemukakan teori bahwa sel-sel merah tersebut adalah makhluk ekstra terestrial.
11. Petir Abadi (kilatan cahaya venezuela)
Sebuah fenomena alam yang unik yakni petir abadi, terjadi di Catatumbo di danau Maracarbo. Fenomena ini berupa awan petir yang membentuk sebuah garis kilat sepanjang 5 kilometer setiap 140-160 malam dalam setahun, 10 jam tiap malam dan lebih dari 280 kali dalam 1 jam. Ini hampir bisa disebut badai permanen. Menurut penelitian, petir ini terjadi karena tumbukan angin yang berasal dari pegunungan Andes. Petir ini juga dijadikan sebagai navigasi oleh para pelaut.
12. Jeritan Misterius (lubang siberia)
Sebuah lubang besar di Siberia dibuat dengan tujuan untuk kepentingan penelitian. Ketika melakukan penggalian, tiba-tiba mesin bor berputar dengan cepat ketika telah mencapai ruang kosong yang besar di perut bumi. Sensor temperatur menunjukkan kenaikan sangat dramatis. Sebuah microphone supersensitif dimasukkan ke dalam lubang dengan tujuan untuk mendengarkan pergerakan lempeng bumi. Tapi sebaliknya, yang terdengar adalah suara jeritan-jeritan manusia.
awas virus komputer sering menyerang laptop/komputer anda.
sampai ketemu di post saya berikutnya,,,thanks for attention.
Penyelidikan arkeolog menurut versi Plato, waku tenggelamnya Atlantis kurang lebih 11.150 tahun silam. Plato mengatakan bahwa kerajaan Atlantis diceritakan turun-temurun, bukan rekaan sendiri. Sejak ribuan tahun silam orang-orang menaruh minat yang sangat besar terhadap hal ini. Sejak tahun 1960-an sampai abad ke-20, laut bermuda yang terletak di bagian barat Samudera Atlantik berturut-turut diketemukan keajaiban yang menggemparkan dunia. Pada tahun 1968, beberapa penyelam melihat sebuah jalan besar yang dibangun menggunakan batu persegi panjang yang disusun sangat rapi. Tahun 1979, ilmuan Amerika dan Perancis menemukan piramida di dasar laut bermuda. Diperkirakan bangunan-bangunan bawah laut tersebut adalah sisa-sisa kerajaan Atlantis yang telah tenggelam.
2. Si Merah dari Antartika(gletser merah antartika)
Saat pertama kali ditemukan oleh seorang ahli geologi pada tahun 1911, warna merah yang mengalir secara perlahan-lahan tersebut diperkirakan berasal dari ganggang merah. Agapan lain menyebutkan warna merah berasal dari gletser yang terkurung di bawah aliran air selama jutaan tahun dan mengandung mikroba-mikroba kuno yang terisolasi di bawah lapisan es yang sangat tebal, karena tidak ada cahaya, panas dan oksigen sehingga mengalami salinitas yang tinggi dan mengandung zat besi, dari zat besi itulah warna merah dihasilkan. Dengan adanya celah gletser, air keluar membentuk air terjun tanpa mencemari ekosistem di
dalamnya.
3. Garis-garis Misterius (Garis Nazca (Nazca Lines))
Pertanyaannya adalah bagaimana cara pembuatannya? Bisakah di peradaban kuno membuat sketsa yang sangat besar tanpa bantuan dari udara?. Menurut teori Joe Nickell, garis tersebut dapat dibuat dengan cara menyingkirkan kerikil-kerikil disekitar gurun. Dengan perhitungan yang akurat, saat kerikil dipindahkan, lapisan tanah yang berwarna kontras akan memberi kesan garis yang membentuk gambar. Pada tahun 1985, Johan Reihard menyatakan bahwa Nazca Lines dibuat untuk keperluan ritual keagamaan yang berhubungan dengan penyembahan dewa.
4. Lubang Api
5. Benda terbang tak teridentifikasi (Unidentified Flying Object)
Begitu seterusnya muncul kisah penampakan UFO di seluruh dunia termasuk Indonesia. 10 februari 1953, penduduk kota Magelang melihat empat buah benda kecil mengkilap yang bergerak perlahan-lahan hingga menghilang di balik awan. Pada tahun 1973, wisatawan Jepang, Ryo Terumoto yang sedang berkunjung ke gunung Agung Bali tidak sengaja memotret benda berbentuk cakram tersebut. Penampakan pun terjadi di kediaman salah satu maestro seni Indonesia, Guruh Soekaro Putra. Pada tanggal 23 Mei 1981, penjaga rumah
melihat makhluk setinggi 1,2 meter yang kemudian menghilang bersamaan dengan munculnya benda bercahaya. Paginya dau disekitar penampakan UFO menjadi berwarna coklat seperti tersengat hawa papas.
6. Motif unik misterius (Crop Circle)
7. Lubang Biru (Great Blue Hole)
Pada tahun 1971, Jasquer Yves ( Penyelam terbaik dari 4 situs penyelam di Bumi) menyelam kedalam lubang untuk mengukur kedalamannya dan memeriksa stalakmit dari dinding yang menggantung. Keindahan dari lubang biru yaitu kedalamannya menciptakan warna nila yang menyebabkan struktur yang diberi nama lubang biru. Selain itu juga terdapat banyak ikan seperti Angel Fish, Butter Flyfish, ikan hamnlpis dan ikan kerapu kecil yang menyapu permukaan air ketika tenang sehingga menyebabkan berkilauan ketika diterangi matahari membuat keindahan yang luar biasa.
8. Segitiga unik (segi tiga bermuda)
Menurut teori Badan Penyelidikan Geologi Amerika Serikat pada tahun 1981, hilangnya pesawat terbang dan kapal laut karena dikawasan tersebut banyak terdapat gas methana. Ada yang megatakan bahwa segitiga bermuda adalah pangkalan UFO, sehingga kendaraan apapun yang melintas teritorial tersebut akan diculik dan terhisap. Ada pula yang mengatakan bahwa penyebabnya dikarenakan oleh adanya sumber magnet terbesar di Bumi yang tertanam di bawah segitiga bermuda, sehingga logam berton-ton pun dapat tertarik ke dalam.Meskipun banyak teori, namun tidak ada yang memuaskan sebab munculnya tambahan seperti benda asing bersinar yang mengelilingi pesawat sebelum kontak dengan menara pengawas terputus dan pesawat menghilang.
9. Bangunan Megah Termisterius (piramid)
10. Hujan Aneh (hujan darah)
hujan darah, Louis mengemukakan teori bahwa sel-sel merah tersebut adalah makhluk ekstra terestrial.
11. Petir Abadi (kilatan cahaya venezuela)
12. Jeritan Misterius (lubang siberia)
awas virus komputer sering menyerang laptop/komputer anda.
sampai ketemu di post saya berikutnya,,,thanks for attention.
Saturday, March 19, 2011
Pelecing kangkung dari pulau Lombok
Resep Bahan Pelecing Kangkung :
* kangkung 150 gram, siangi
* kacang panjang 50 gram, siangi
* taoge 50 gram, siangi
* kacang tanah 3 sendok makan, goreng
* air 1 liter
Resep Bumbu Pelecing Kangkung :
* cabai rawit 10 buah
* tomat 1 buah
* terasi 1/2 sendok teh
* garam secukupnya
* gula pasir 1/2 sendok teh
* air jeruk limau 1/2 sendok teh
Cara Membuat Pelecing Kangkung :
1. Didihkan air, rebus sayuran bergantian hingga matang dengan urutan taoge, kacang panjang dan kangkung. Angkat dan tiriskan.
2. Haluskan sema bumbu hingga rata.
3. Atur kangkung, taoge, kacang pancang dan kacang tanah di atas piring saji. Tambahkan bumbu halus dan bumbu kelapa di atasnya.
4. Sajikan.
Untuk 3 porsi
Tips :
Bumbu kelapa dibuat dari kelapa sedang parut yang dibumbui bawang putih, cabai merah, cabai rawit, kencur, daun jeruk, dagarm dan gula. Dimatangkan dengan cara dikukus.
Subscribe to:
Posts (Atom)