Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

Brain Zap

15pmps5.png
Logo courtesy of RadethDart.

Brain Zap is a puzzle video game published and developed by Coral Live! (‘kó-rə-līv) for the iOS and Android OS. It will be released in the Apple Market on July 1, 2012.


Gameplay
In Brain Zap, tests are done in order to measure a brain’s amount of neural connections or brain saps. The greater the amount of saps, the smarter the brain is or better its reaction time. The brain is represented by a sapling that grows to be a full-fledged tree. There is no single game mechanism to Brain Zap; as it is an assortment of puzzles with no one puzzle having greater priority than the other. There are three modes of play: Test mode, Practice mode, and Versus mode.

Test mode

Test mode consists of a formal test consisting of five puzzles, with one puzzle taken at random from each of the five categories to determine the player’s amount of brain saps.

There are five different categories of tests with three activities per category. The categories are:
  • • Logic
    • Reason
    • Math
    • Visual
    • Memory

Practice mode

Practice mode allows the player to select which specific activity he or she wants to do in order to train their brain. The activities available for play consist of those available in Test mode.

I know this is preliminary, but I am planning on posting more content later this week. And yes, this is a clone of the Brain Age and Big Brain Academy games. I still like the project very much.
 
I'm thinking whether I should make a pause in the development of Brain Zap to participate in the Construct 2 contest, but, I don't know if it's worth it. To begin with, I don't know a rat's ass about Construct 2, so I'd have to sit many hours and learn how to use it. Besides, it's too much of a hazzle, and I don't really want Construct 2 that much.

I've made some pretty great developments in Brain Zap. I haven't actually started coding, but I've done hours of painting. I've got most of the menus painted, and I've started designing the games. As of the moment, I just finished the math games. These will be Number Cruncher, Word Cruncher, and Magic Squares. Number Cruncher requires you to solver simple equations as fast as possible. Word Cruncher is the same, but with written equations. Magic Squares requires you to find the missing number in a magic square, a 3x3 table where all rows and columns add up to the same number.

I know these are pretty run-of-the-mill, but I assure you they will be entertaining.

Tomorrow I might upload some mock screenshots. I'm still waiting on my pet character. So far, I've got one submission. If this doesn't work out, I'll just pay a graphic designer, which is what I've been trying to avoid, because if I don't like the design then obviously there will be a dispute.
 
I had some ideas for the versus mode I forgot to mention yesterday. First, you have two types of versus mode, turn-based and reactor. Eventually, specially with the new upcoming build of DragonFireSDK, I could add a versus mode with an Internet-player. Will see, because this also means having a server, and that might not be very profitable. Maybe I could eventually release a social media (a.k.a. Facebook) version with this feature, but for a standalone it might be unnecessarily complicated. Anyhow, the turn-based mode is the same games, but you take turns between player one and player two. The reactor mode lets player one and player two play simultaneously. The one who finishes a certain number of random-picked tests first wins. Eventually, and we'll see how profitable this game turns out to be, I could release an iPad version with a 4-player reactor. Now, that would be something. Four people competing to see who has the smartest brain.
 
Well, a lot has happened since my last post.

1. DragonFireSDK v2.0 came out.
This new version of the SDK has multiple lines text boxes, SQL compatibility, Box2D, containers, and many other incredible things.

2. I hosted an art contest.
Tomas won. The mascot's name is Dr Albright. He's a yellow neuron with orange hair / dendrites, and he's smoking a pipe. Evidently, I made a particle engine just so that the pipe's smoke would be animated. Really, I see no other use for the particle engine, but the guy looks really cute smoking.

3. I've made a final list of games / brain-training exercises.
Fake coin. Rock, paper, scissor. Train tracks. Cube count. Algebraic reasoning. Word scramble. Calculations. Word calculations. Number cruncher. Syllable count. Which is the same? Memory sprint. Piano player. Low to high. Guess who?
Most of these games are variations of Brain Age games. They're split into the five aforementioned categories. The names for the games are definitely not final.

Finally, I give you Dr Albright.

x6g4h.jpg

f4e2e0.jpg
 
This is a screenshot, not a mockup. It has several components: the background image, the logo, the pet character, pipe smoke generated from a particle engine, and some text. The way DragonFireSDK works is, I have my regular images, and I have a HD copy of each image (including text) with a "@2x" suffix. Newer generation iPhones and iPads will recognize the suffix and use the HD version of each image. However, the emulator uses the SD images, which is good, because my monitor resolution isn't that high.

w6zjk.png
 
RadethDart":bpkwwq5j said:
Oh, wow...that looks slick my friend!
Thank you, Radeth. I'm putting as much effort as possible on this game since I plan to sell it in the App Store. I don't plan charging too much for this app, but I truly believe people will pay for quality.

Today I worked on a message system. It's not finished, but it's pretty close. It takes a single character array and splits it among several lines and pages. As of the moment, it can display one page at a time. I'm still figuring out how to make it change pages. It's much harder than it looks. C++ doesn't have strings in the sense Java does. Instead, you have to work with character arrays, which follow the same principles of other arrays. One of the biggest roadblocks is you can't change your array's size. It's very frustrating.

Incredibly, after only two days, the code's a freaking mess. I need to figure out how to better organize it. One of the bad things about working with DragonFireSDK is you can only have one .cpp file. In the end, this translates into having many, many headers.

Tomorrow I'll finish the message system. After that, I'll start thinking about SQL databases. Programming your game from scratch is hard. However, making your own bitmap font is even harder.

rsdc20.png
 
Message system works perfectly.

I finally figured out all those little tweaks that need tweaking. Most of the time, you get stuck in really stupid stuff. In example, I divide the total number of lines by the max number of lines to get various elements: number of pages, how many lines to display at a time, etc. I failed to notice at first hand that if the the total number of lines was a multiple of the max number of lines, the remainder would be zero. Another example, I was using an intrinsic function of the SDK called StrCopy instead of using the much more convenient and C++ native sprintf. What's the difference, you ask? StrCopy only lets you copy 100 characters.

Anyhow, the message system works. You can have up to 255 character messages, which is a lot. And although I haven't tested it yet, it should work with any bitmap font, in a message box any size.
 
http://www.youtube.com/watch?v=aeidHtL6R50

Right now I'm working on the dialog box, and I'm also commenting and reorganizing my code. I also got a musician, he goes by the name of djzalzer (a member of HBGames.org), but his real name is Isaac Kolding. He seems like a really nice guy.

Tomas still hasn't given me the final version of Dr Albright, but I'm sure it's going to be great, so I'm not pressuring him. He's going to make various facial expressions for Dr Albright to give him a more human persona.

I've also made a definitive list of games and I've sort of planned in my head how I'm going to implement them. Basically, each game will be a reusable class. I instantiate the game class from my main class. Then I somehow trigger it (i.e., a button). Then the game class loops until it's done. Since there is only one instance of each game, I'm assuming it won't consume much memory.
 
This guy who goes by the name ajf made an unofficial DragonFireSDK forum a few days ago. This is great considering the "official" DFSDK forum has been on repair for nearly two years (a long time before I found about the SDK). It's funny, cause if you email the DFSDK guys about the forum, they'll tell you it's still being repaired. How long can that possibly take?

http://dfsdk.ajf.me
 
You can go ahead and skip this post. It's more of a development dump, rather than any actual progress.

DragonFireSDK allows you to have only one CPP file named "app.cpp". This isn't so true, since you can include both H and CPP files in "app.cpp", and as long as you include them in the right order, you'll be okay.

In DragonFireSDK there are three required functions: AppMain, OnTimer, AppExit. AppMain marks the beginning and the end of program execution. There is one and only one AppMain per program. Here is where you add all of your components. OnTimer is called 30 times per second (unless you're doing something stupid that makes your program lag). Here is where you update all of your components. AppExit is called whenever your application terminates (i.e., a phone call).

Every function that has Init or Add in its name should be added within AppMain. Otherwise, this can make the program leak memory, and will have some serious lag issues. This is the golden rule of DragonFireSDK.

The rest is up to you. So far, I've figured I'm going to need a message box, a dialog box, and Dr Albright. Each of these components gets its own separate container. All the other stuff goes into container with the name of each screen. This way, I can easily make containers visible and not visible.

I was thinking, I could probably use an enumerator to manage screens. Additionally, a variable can manage events within screens. I.e., the welcome screen first shows a message box (event 1), then it shows a dialog box asking for your name (event 2), then it clears the dialog box and shows another message (event 3).

I don't want to clog the three main functions. Instead of having a huge AppMain, I can call an Init function from AppMain. The Init function can call other Init functions. From the top of my head, I can think of the following: InitImages, InitSounds, InitComponents, InitData, etc. To use as little images as possible (since images leak memory in DragonFireSDK), we can reuse images. I.e., the text box uses the same image as the dialog box.

Instead of coding all the update events in the OnTimer function, each class can have an Update function that can be called within OnTimer. Non-class components that require updates can have an Update function of their own that can also be called from within OnTimer.

AppExit should set a pause boolean to true. When pause is true, no updates should occur until the user touches the screen or some other mechanism.

Every mini-game should be initialized within AppMain. Each mini-game should have an activated boolean. If activated, then the program should update the mini-game within OnTimer.
 
Okay...

So it seems like my final post was a little over 3 years ago. At that time, I was working with DragonFireSDK, which is an SDK which allows you to build apps for Mac using Windows. At the time it showed immense potential and I got carried away with the promises. It's not really a bad SDK, it's just missing too many APIs.

Let me tell you a little bit of what's happened the past 3 years:
- Mid 2012 I must've stopped working on Brain Zap because I had a lot of med school finals
- Late 2012 I was mostly in Chicago, preparing for my USMLE Step 1
- 2013 was my internship year, which I spent mostly in Costa Rica and a tiny bit in Winston-Salem, NC
- Very early 2014 I was in Houston, doing an observership in Cardiology
- Early 2014 I was in New York City, preparing for my USMLE Step 2 CK
- Mid 2014 I went to live with my brother in Minneapolis and totally rocked my Step 2 CK; I also started preparing for the National Residency Match Program (NRMP)
- Mid to late 2014 I still had to do one more test, the USMLE Step 2 CS, a test with actors posing as patients, and scored by the actors; I took the test in Philadelphia and failed
- Late 2014 I still applied for the NRMP, and even got an interview at Mount Sinai Hospital in Florida, but obviously since I hadn't passed all my tests yet, I couldn't enter residency
- Early 2015 I worked 3 months like a slave as a GP and got fired because of some silly paperwork mixup; I don't regret working there because it was great practice, but I also don't regret getting fired

And right now, I'm preparing to retake my Step 2 CS. If you're wondering why it took so long, it's because test results take up to 3 months to get back, and getting a date for the test is near to impossible.

Anyhow, back to the game...

I reached out to my old buddy and we started shooting out some ideas. We decided to start over from scratch and use Corona SDK as our platform. I tried contacting my original composer but he disappeared from the internet (like, seriously, he erased himself from every social media and took out all evidence of his prior existence). So, as it seems, it's a very exciting time in Brain Zap. I've been hiring composers and artists, and doing some programming, and it's all looking very professional.

Next post I'll update the thread, because none of the information previously written applies to our current version of the game. I'll also post some images and maybe a video or two.
 

Spoo

Sponsor

I'm glad you're keeping with it, man! I neither have a smartphone nor do I know much about the development of apps, but I know the market is saturated with crap at the moment. Anything trying to improve that is okay with me.
 
hey man I like the tree growth graphic.
also if the performance graph isn't much work to code i think it's a nice statistical view of your performance?
It's nice to see how you're still active and also actively working on your game.
Do you also keep some sort of more formal blog?

I always enjoy seeing people dive deeper into development problems, for example: http://the-witness.net/news/page/16/
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top