This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - Builderboy
1
« on: February 21, 2013, 05:19:36 am »
Serenity DemoSerenity is a pure basic puzzle platformer. Originally intended to be a complete game, this is simply a demo of the first sector, as there has been very little progress on the game for some time. In Serenity you are the captain of a simple cargo ship in the distant future. As you are on the way to deliver your mysterious cargo, you are hijacked by the devious Niska, and taken prisoner on his ship. Fight enemies and solve puzzles in this beautiful sidescroller. Note that this demo is about the same as I released a while back, but now it's all tidied up and in the archives   
2
« on: November 30, 2012, 11:10:01 pm »
Portal PreludeWelcome to Aperture Laboratories! Long before GLaDOS ever ran the facility, step into the shoes of a test subject and test the Aperture Science Handheld Portal Device (ASHPD) for yourself! Test your way through 38 devious test chambers using Portals, in addition to many other intriguing gameplay elements such as plasma balls and electric fields.  
3
« on: November 27, 2012, 07:25:21 pm »
A group of people with assorted eye colors live on an island. They are all perfect logicians -- if a conclusion can be logically deduced, they will do it instantly. No one knows the color of their eyes. Every night at midnight, a ferry stops at the island. If anyone has figured out the color of their own eyes, they [must] leave the island that midnight. Everyone can see everyone else at all times and keeps a count of the number of people they see with each eye color (excluding themselves), but they cannot otherwise communicate. Everyone on the island knows all the rules in this paragraph.
On this island there are 100 blue-eyed people, 100 brown-eyed people, and the Guru (she happens to have green eyes). So any given blue-eyed person can see 100 people with brown eyes and 99 people with blue eyes (and one with green), but that does not tell him his own eye color; as far as he knows the totals could be 101 brown and 99 blue.
The Guru is allowed to speak once (let's say at noon), on one day in all their endless years on the island. Standing before the islanders, she says the following:
"Among you is at least 1 person with blue eyes."
Who leaves the island, and on what night?
There are no mirrors or reflecting surfaces, nothing dumb. It is not a trick question, and the answer is logical. It doesn't depend on tricky wording or anyone lying or guessing, and it doesn't involve people doing something silly like creating a sign language or doing genetics. The Guru is not making eye contact with anyone in particular; she's simply saying "I count at least one blue-eyed person on this island who isn't me."
And lastly, the answer is not "no one leaves."
4
« on: November 17, 2012, 08:38:40 pm »
So I am going to be releasing the Portal Prelude level editor in anticipation of the upcoming Portal Prelude release. This is both to give you guys some time to create levels, and also because I need some more levels for my game! There are about 6 slots open, but I'm eager to see what kind of levels you guys can whip up! There are 4 files in the zip, the level editor which is prgmPEDIT, the appvarPortal2 which is necessary to launch the engine, the engine app itself Portal, and the README which details the quirks of the level editor.
5
« on: November 16, 2012, 07:19:51 pm »
Axe Diagnostic ToolThe Axe Program Diagnostics Tool is an Axe utility that allows you to run diagnostics on the runtime speed of your program, analyzing relative and absolute speeds of various subroutines. The utility works by setting up an interrupt that periodically samples your program to see in which routines it is spending the most amount of time. It also traverses the stack during each call to give you even more information.For example, is your game running slow? Can't figure out which part is slowing it down the most? Set up the Axe Program Diagnostics Tool to track all of your major subroutines, and it will tell you how long your program is spending in each routine. If you need higher fidelity, you can also place additional labels inside of a single subroutine to see which parts are taking the most amount of time. The screenshot below gives a good example how this program works, and specifically the difference between inclusive and exclusive samples. A label gets an inclusive sample every time it's own code is sampled, and a label gets an exclusive sample any time it has it's own code, or the code of any routine it has called, sampled. Below, there are 4 labels, MAIN L1 L2 and L3. MAIN is just the main loop that calls L1 and L2. L1 displays a sprite, L2 pauses and then calls L3, and L3 just pauses. When we look at the inclusive percent, we can see that MAIN has very little, since it is barely doing anything (just calling 2 subroutines and looping). L1 has practically zero percent, because the only thing it does is call another subroutine (to draw a sprite) which is not counted in the inclusive percent. Both L2 and L3 are about the same, they both have inclusive samples proportional to the amount of work they do. The 'Other' label has 11 percent, which accounts for the time spent displaying the sprite. But when we look at exclusive percent, things get a little bit more interesting. The percent for MAIN is 100%, since all code that is ever executed is either in MAIN, or inside of a function MAIN calls. L1 now has the same percent as 'Other' since L1 itself barely contributes and gets all it's percent from the sprite routine it calls. L2 has increased since it calls L3. 'Other' always remains the same between Inclusive and Exclusive.
6
« on: October 13, 2012, 03:04:59 am »
So a side project I have been working on in my spare time has been recreating a level from L4D2 in minecraft! I recently finished and released it, so I thought I would post it here  You can visit the project page Here, but here are some screenshots from the map! It's also fully playable, so maybe I can host a server one day and we can have a minecraft L4D2 party
7
« on: July 22, 2012, 01:57:12 pm »
So you want to implement multiplayer into your game? Having trouble with all the specifics? Well look no further because this tutorial will go over all the routines, ideas, and methods you will need in order to successfully implement multiplayer functionality into your Axe (or Asm!) game!
Ideas:
The hardest part of making a multiplayer game is to keep the two or more game experiences synced up. Many different methods can be used to do this, and we should learn at least a little bit about all of them before deciding how to handle multiplayer on our calculator. Traditionally in games like first person shooters, or other types of actions games for the computer, a method is used that relies on client and server based interactions. The client is the master control computer, doing all the calculations for the game state. The client computers simply send their inputs to the client, and get back the current game state to display. Unfortunately this requires sending a fair amount of data, and most games today use advanced prediction algorithms to give the clients the illusion of less latency than they actually have. This method would be an ok solution to any calculator game that doesn't have a lot going on, but sending information over the link port isn't the fastest thing in the world, and I think we can do better.
The method described in the previous paragraph is used almost exclusively in the gaming environment. It works well for most cases, but is not used in one very specific case: RTS games. In RTS games, there are hundreds, sometimes thousands of units on the screen and in the game at any given time. This would require huge amounts of data to be sent each frame if the traditional client-serer method was used. Instead, RTS games use a different method that is more suitable for cases when game states require a lot of data to represent. Instead of using a client server approach, RTS games have all parties on equal footing, with no server, just clients. Each state of the game, each client sends its input or commands to ever other computer. After each computer has the input of the other clients, each computer uses the input to simulate the next game step. This idea relies upon the fact that if the game is 100% deterministic, and if for each frame each game uses the exact same input, the game states should evolve in the same way, even though the actual game state is never being sent from client to client! This is the method I will propose in this tutorial, as it is a method that allows for low amount of data to be sent over the link port, and a small amount of additional coding to further iterate the game state.
The game state cycle
Using our new approach, there are several things that need to happen during a single game frame update. They would look something like this:
Get input from player 1
Get input from player 2
Simulate actions of player 1
Simulate actions of player 2
The order of the actions only matters if one of the actions can influence the results of another. For example it does not matter in what order input is attained, because (for the most part) the input you give does not depend on what input your opponent gives (for a single frame). However, simulating the actions of players can affect other players. For example, lets say one calculator simulates player 1 and then player 2, and the other calculator does the opposite. On calculator 1, player 1 might move forward to block the movement of player 2. On calculator 2, player 2 would be simulated first, allowing player 2 to move before player 1 could block them. This would be disastrous, as remember, we are not sending the game state, only inputs, and that entire concept relies upon the fact that the game states remain the same. If the two games get out of sync even a little bit, the changes can cumulate until the two players are playing completely different games! For this reason, the order of simulating actions must remain the same for both calculators.
Getting the input
There are two steps to getting the input for the game. First you need to get player 1's input, and then player 2's. But you can make a simplification assuming that one input does not affect the other. Instead of getting player 1's input and then player 2's, first get your own input and then your opponents. This way the code can stay more the same for both players, since they will both be doing much of the same thing. Getting your own input is simple enough, it is the getting of your opponents input that is a bit tricky. In the following example, we will assume the input to be sent is a simple key variable K:
GetKey->K //Get input from my player
If MyPlayer = 1 //If i am player 1
K->K1 //store my input into the player 1 input var
Repeat Send(K1,1000) //and wait until I can send it to my opponent
End
Repeat Get->K2-1 //then wait until I get the input from my opponent
End
Else
K->K2
Repeat Get->K1-1 //the other player needs to recieve first before sending!
End
Repeat Send(K2,1000)
End
End
This code uses several variables. K represents the input you are giving to your own calculator. K1 and K2 represent the inputs of player 1 and player 2. MyPlayer represents the player number of the calculator (1 or a 2). Whenever one of the calculators reaches this piece of code, it will first get the input from the player controlling this calculator, and then it will wait and try to talk to the other calculator. Once both calculators reach that part of the code, they will exchange their inputs and move on. Also, note how similar the get and send parts are. If your input was more complicated and required more code, it might be useful to put the code in a subroutine in order to cut down size.
Simulating The Game:
The previous routines and ideas will get you the input you need, but if you do not simulate the game correctly, your two simulations will diverge and the game will be lost. The only thing you need to ensure is that given identical inputs, the simulation phase must produce identical results given identical and initial game state. This is not too hard to attain, just make sure that instead of simulating your own player and then your opponents, you simulate player 1 and then player 2. The harder part is simply keeping track of all your variables, and for that I will provide a quick suggestion for Axe based systems.
Set aside 2 spaces of 56 bytes, 1 space for each player. We will call place 1 P1 and place 2 P2. Both of these memory locations need to be separate from your regular variable space. Our movement code will not do anything fancy with it's variable access, but we will use #Realloc() and Exch() to help us out. Move() will also be our subroutine that handles the movement of a single player.
#Realloc(°P1)
Move()
Exch(°P1,°P2,56)
Move()
Exch(°P1,°P2,56)
#Realloc()
Now the Move() subroutine just uses default variables, but because we use #Realloc(), we can change its effect to modify a player's variables instead! And when we exchange the player data, we can use the same Move() subroutine for both players!
Global Variables:
Now with all this memory swapping going on, we will end up with 3 different variable spaces. One for the regular #Realloc() space, one for °P1 and one for °P2. This can get a little annoying when trying to access data from a different sector, because you really don't have a simple way to access it. That is why I propose the use of Axe custom variables, as Global Variables. They are unaffected by the #Realloc() command, and so can always be accessed by any part of the program at any time, and they will always be the same variable.
Now this comes in extra use when it comes to input. Remember those variables K1 and K2 we were using before? Those are actually special types of global variables that refer to actual variables in a specific variable space. Specifically K1 refers to the K of °P1, and K2 refers to the K of °P2. This way, when it comes time to Move() each player, the K in their variable space will already have the input data needed! I recommend using these types of global variables frequently in order to help different variable spaces talk to each other. It might even be useful to create a whole set of global variables for °P2, since those variables will always point to the opponent whenever Move() is called.
Conclusion:
That's pretty much it! Using this knowledge and coding techniques, it should be relatively simple to make a simple multiplayer game, and when you decide to start a detailed in depth game with fully featured multiplayer, you will have the ideas to help you along the way!
8
« on: July 21, 2012, 12:49:42 am »
So a large village of people lives by a forest that is terrorized by a goblin. Occasionally when a large group of villagers go out to hunt, the goblin takes kidnaps them and plays a cruel game with them. The goblin first forces the villagers to stand in a single file line with each villager facing the one in front of him, and then places either a red or a blue hat on each villager such that they do not know what color hat they have on. If any villagers move or make any sort of signal, the goblin kills all of the villagers immediately. The goblin then starts from the back of the line (starting with the villager with nobody behind him that is) and asks them which color hat they are wearing. The villagers must either answer red or blue, and any variation or movement once again gets all the villagers killed. If the villager is wrong, he gets his head bitten off, and if he is correct, he is permitted to live, but must stand in his location without moving until the goblin is finished. After the goblin is finished asking each villager, all the ones still alive are permitted to leave safely.
The villagers (or at least the survivors) over time have come to learn the goblins game very well, and so set out to determine if there is a best strategy they can use to ensure the highest survival rate on average. They keep in mind that all villagers can hear the responses of all villagers before them, and a villager will know when a fellow villager answers incorrectly based on the sound of their head being eaten. All villagers can also see the hat color of all villagers in front of them.
So the question stands, if all of the villagers can come up with a strategy beforehand, what would the most optimal strategy be?
9
« on: July 04, 2012, 07:25:56 pm »
Well I have finally crossed the threshold I set for myself! I have been working on a contest entry for some time now, but have not been sure whether or not I would be able to finish it due to having a full time job and not that much free time. However, I have just finished the major part of the AI that has me decided that this will be released in time for the contest after all! So behold! Vortex 2.0 is a complete reboot of my old Basic Vortex game, using the power of Axe to bring the concept to the next level! You start the game in one corner of the large map, with nothing but a lousy pistol to defend yourself with. In order to win, you must destroy your opponent. You can do so with your pistol, but the real fun starts when you start finding chests of cash scattered all over the battlefield. You can use this money to buy upgrades, weapons, items, or even spells! You can upgrade your lousy pistol's speed to get a machine gun, or you can invest in high cost spells to defeat your opponent. Maybe you invest in speed and agility upgrades to out-maneuver your opponent, the combinations are endless! AINow, unlike the original basic game, this version will have a devious AI that you can battle against when you don't have a friend to play with (And yes, you will be able to play with a friend over a link cable! Although probably not for the contest entry). The AI is what is going to make this game truly fun to play, as it has many advanced algorithms that go into making it work: 1) At it's heard is a modified A* path-finding algorithm. I say modified because the AI does not solve for the most efficient path once and then follow it. He is constantly correcting for new information and updating the planned path according to new data, like area's he discovered or movements of you, the player! 2) Danger detection is another important role that has been integrated directly into the path-finding algorithm. As an AI battling you, he needs to know when an area is safe to enter. If you are standing nearby, the AI needs to consider whether or not he will be able to escape if you decide to attack, and path accordingly. 3) Dynamic build-order code helps the AI choose good combinations of items, while at the same time keeping him flexible and reactive to opportunities or dangers that can arise due to how the game is playing out. For instance, if a large number of chests are near the center, he might purchase a speed upgrade sooner in order to get there before you do. TerrainA large part of the game that could be overlooked is the map itself, what will it look like? Vortex 2.0 has an advanced procedurally generated terrain complete with blocks of land, chests, and various walls that fill the map. While not technically an AI, the dynamic nature of the terrain generator should help make for a game with a great replay value. More information and screenshots will be released as the deadline grows closer, but for now here is a screenshot of the AI pathing through the map to find all of the chests, and then heading to the bottom right corner of the map. All of the tiles with a single pixel are the tiles being currently considered by the pathing algorithm, and the darkened boxes are the tiles currently chosen for an ideal path.
10
« on: May 20, 2012, 09:58:19 pm »
For the last couple weeks, I have been working on and off on an Real Time Strategy engine, with the final goal to be the creation of a fully featured RTS game for the calculator. It has been quite a struggle with different types of data structures, but a lot of progress has been made since its inception. I was reluctant to post this on the forums for a while due to it being such a large project, and because I has having such difficulty getting some of the foundations of the engine working. However, just today I have solidified the basics of the engine.
However, the worries of this project being too much to handle for just one person still remain, so I am proposing that this be a completely open source project from the start. This will not be a community project though, as I will still be doing most of the coding. The idea is that from the start, anybody who is interested can take a look at the code and propose changes or optimizations as the development cycle goes on. Furthermore, I will not just be uploading the source, but simply zipping my entire development folder for all to see, so you will get to see all past backups, screenshots, and development notes that I create for myself.
The engine itself is one of the most complex I have ever written, and is still only in it's infancy. It is being written with multiplayer in mind, so transitioning into link-play should not be difficult. Link play will most likely come before any type of official AI, although both are planned (hoped for). Currently the engine has these features:
-64 units per player. Each unit is 4x4 pixels
-64x64 tilemap. Each tile is 4x4 pixels, but all buildings take up an 8x8 space
-256 4x4 'chunks' that are used in internal processing
-Rudimentary pathing
The chunk system is the thing I have been working on for the past couple days, and it is finally working to my satisfaction. Each player has a 832 byte section of memory allocated to all their units. This consists of a 256 byte lookup table, and then 9 sets of 64 byte lists, each list for a different attribute. The data structure that I chose is a linked list, and each chunk is it's own linked list. The 256 byte lookup table has 1 byte for each chunk, and this byte points to a single object that exists within the chunk (or nowhere if there is no unit in that chunk). Each unit then points to the next unit in the chunk, or nowhere if this is the last unit. I have routines for adding units into the world, deleting from the world, and moving from 1 chunk to another, and they are all very efficient. The deletion routine is just 2 simple lines, and the movement routine is equally simple. Both moving and deletion run in constant time, while addition runs in linear time (although still very quickly).
The pathing system is also a piece of code that was very time consuming to get working. It is quite complicated, but I will go over the basics here. When you order a select number of units to move to a specific location, the program does a depth fill from the destination location through the map until it locates all units (or until it has searched the whole map). After this depth map, it generates a movement tree that all objects follow in order to get to the destination location. Right now the way that this pathing tree is followed is very simple and often results in some traffic jams, but it is going to be improved in the future.
Anyways, that is all for now, I will leave you with a screenshot of all current progress, showcasing the unit selection and pathing routines. I will also be uploading the development files for all to see, so enjoy!
For those of you who want to compile the latest version, you will want to go into the backups folder, choose the most recent version, and compile prgmAARTS. Use the arrow keys to move the cursor, 2nd to select a region, alpha to toggle tiles, and Y= to send selected units to a location.
11
« on: May 18, 2012, 03:25:23 pm »
So a week or two ago, Valve released the Free DLC for Portal 2 that allows you to create and test your very own test chambers! I'll keep adding them to the first post and we can get a compendium of all the test chambers Omni has created! I've already added my own. So have any of you made any? Post-em if you got em! Builderboy's Test ChambersSpenceboy98's Test Chambers
12
« on: February 28, 2012, 11:29:22 pm »
A few days ago a friend in my math class introduced me to the game Core Wars, and I immediately decided to port it to the calculator! Core Wars is a two player competitive game, featuring a unique type of gameplay. The two contestants must each write a program in Redcode, which is the programming language of the Core. Each program is then inserted into a section of memory called the Core. If either program stops executing, that player loses. Of course it is simple to make a program that never terminates when left on its own, the tricky part is that both programs live in the same memory (the Core) and so can influence each other. The programs must try to find their opposing program and sabotage and destroy it in order to halt it's execution. It's the greatest battle of a programmers ingenuity, as they pit their own programs to destroy others in The Core! Redcode: The programming language of The Core is called RedCode, and is like a simplified version of assembly. There are only 18 possible instructions, but many different modifiers that make each instruction powerful. The instructions are formatted in a very specific way that is consistant for all instructions: NAME A BNAME is the name of the instruction. The name also indicates the type of instruction, and what it does. The A and B field both hold numbers, and in general data passes from the A field into the B field. The instructions are specifically: DAT: If any process tries to execute a DAT command, that process is killed. A and B field can be used to hold data.
MOV: Moves data from A into B
ADD: Adds A to B and stores the result into B
SUB: Subtracts A from B and stores the result into B
MUL: Multiplies A and B and stores the result into B
DIV: Divides B by A and stores the result into B
MOD: Divides B by A and stores the remainder into B
JMP: Moves program execution to location A (B is ignored)
JMZ: Jumps to location A if B is zero
JMN: Humps to location A if B is not zero
DJN: Decreases B and jumps to A if B is not zero
SPL: Starts a new process at location A
SEQ: Skips the next instruction if A and B are equal
SNE: Skips the next instruction if A and B are not equal
SLT: Skips the next instruction if A is less than B
NOP: Does nothing, guess you could use this to hold data as well.There is more than these instructions, and A/B than is just told here, and there are some good tutorials that I will LINK to in order to help keep this post shorter, and to probably help better explain as well. One element I do want to cover though is the SPL instruction. It says that it creates another process at location A, but what does that mean? Processes in Redcode are handled a very specific way. If you have two processes, each process will run twice as slow as if you only had one process. In other words, creating new processes does not give you any more computing power. If you had 3 processes and your opponent only has 1, then execution might look something like this: Player 1 Process 1
Player 2 Process 1
Player 1 Process 2
Player 2 Process 1
Player 1 Process 3
Player 2 Process 1As you can see, Player 2 was able to execute 3 instructions in his one process, while each of your processes were only able to execute a single instruction. Conclusion/Plans: Now the game hasn't been completed yet, but I do have the majority of the instructions implemented, as well as an assembler and a working interpreter. I will be updating the tutorial part of this thread as time goes on, but in the meantime feel free to visit This tutorial as well. The syntax is slightly different since we don't have access to the same characters as they do, but I will be posting more on syntax in the future. For now I will leave you with this screenie of what the game screen will look like! It features the two program's names, as well as showing how many processes they currently have. The square in the center is a visual representation of the Core, and shows how the programs move through and modify memory. The two other squares are each programs private memory areas.  
13
« on: January 05, 2012, 05:59:14 am »
14
« on: December 07, 2011, 06:15:09 pm »
Two bicycles are spaced 100 meters apart and start riding towards each other at 1 meter per second. At the same time, a fly on the front of one bike starts flying towards the other bike at 2 meters per second. As soon as the fly reaches the second bike, it turns around and starts flying back towards the first bike. The fly repeats this process as the bikes draw closer together, eventually turning around an infinite number of times. But how far does the fly travel before the bikes finally collide?
15
« on: November 27, 2011, 12:30:53 am »
So I was messing around with minecarts in Minecraft today, and I noticed something strange. I had put about a dozen minecarts on a single track, and whenever they got closer to each other, every once in a while my player would move slightly. Intrigued, I began to test. I build a 2x2 circle of rails, and added in several dozen minecarts. The results were interesting for sure. My player would be pushed away from the spinning minecarts with a surprising amount of force. What's more, any attempt to break a nearby block did nothing. I ended up building a facility to test this phenomenon. It has a bank of 114 minecarts that can slowly be added into a central field generator, and nearby minecarts to test the fields strength. Check it out! Here is a picture featuring the field generator 
|
Show Posts
