Hello. I'm working on a casual game, and I'm having trouble deciding on the gameplay interface. It's a food-based game, where you make menu items and serve them to customers. So I have a quick question for you. Which of the following graphical user interfaces do you feel is the most effective? Because it's a casual game (runs in the browser), I need to make an interface that's easy jump into and understand immediately (uncomplicated).

1.) Cook, Serve, Delicious - All gameplay occurs in one screen (including different types of preparation).

2.) Papa's Freezeria - The gameplay is split between four screens usually (one for each prep step).

3.) Cooking Mama - Gameplay screen changes based on the type of dish preparation (chopping, stir frying, peeling, etc.).

Ok...and one more thing. How should I handle level progression without save data? From my own research, I've found two useful methods of handling this.

A.) Using a level/chapter selection screen. The player can play through however many levels, and just resume from one of the chapters.

B.) Using progressive difficulty in a single game session. The player clears as many levels as possible in one go, then starts over from the beginning.

I would greatly appreciate your insight. Thanks for reading my post!

Not to sure about the game play interface so I will leave that to more apt designers. As for the game state you might consider using a cookie to store your game data on the players computer. The plus to this is now your players can enter the game, play it some, come back another day and play it some more and pick up where they left off. The down side to this is if the player clears their cookies then your game data is lost and they will be starting from scratch.

With some simple AJAX calls and a database you could make it so the game state is stored on your web server. But that can get a little complicated but to me is worth the effort.

Not to sure about the game play interface so I will leave that to more apt designers. As for the game state you might consider using a cookie to store your game data on the players computer. The plus to this is now your players can enter the game, play it some, come back another day and play it some more and pick up where they left off. The down side to this is if the player clears their cookies then your game data is lost and they will be starting from scratch.

With some simple AJAX calls and a database you could make it so the game state is stored on your web server. But that can get a little complicated but to me is worth the effort.

I would use a database, but I'm making a Flash game that doesn't run on my server alone (so server-side programming would be inapplicable in my case). If I don't use one of the two methods I mentioned, cookies would definitely be the third option. After reading this, I believe it might be better to use Flash's version of a cookie (local shared object). I found this resource to be a good reference point if I do use that method. Thanks for your suggestions!

I would use a database, but I'm making a Flash game that doesn't run on my server alone (so server-side programming would be inapplicable in my case). If I don't use one of the two methods I mentioned, cookies would definitely be the third option. After reading this, I believe it might be better to use Flash's version of a cookie (local shared object). I found this resource to be a good reference point if I do use that method. Thanks for your suggestions!

Cookies are about one the most common ways to store session state in a sessionless environment. With a bit of thinking you might be able to figure out how to get data in and out of your game through a call to the web server and a custom built API that could handle session and player objects. you might have a look at this in the ActionScript documentation. This page discusses how to get data in and out of your flash project using the web standard JSON objects. With some work you could be sending data back and forth between the server and your game. Just a thought. Being able to store your players data in your database would then allow you to build ladders, top 100, etc.. type lists. But these kind of things maybe outside of your games scope.

Just curios not trying to start a language or technology war here but why did you decided to work in flash and not HTML5 Canvas, and JavaScript?

I would use a database, but I'm making a Flash game that doesn't run on my server alone (so server-side programming would be inapplicable in my case). If I don't use one of the two methods I mentioned, cookies would definitely be the third option. After reading this, I believe it might be better to use Flash's version of a cookie (local shared object). I found this resource to be a good reference point if I do use that method. Thanks for your suggestions!

Cookies are about one the most common ways to store session state in a sessionless environment. With a bit of thinking you might be able to figure out how to get data in and out of your game through a call to the web server and a custom built API that could handle session and player objects. you might have a look at this in the ActionScript documentation. This page discusses how to get data in and out of your flash project using the web standard JSON objects. With some work you could be sending data back and forth between the server and your game. Just a thought. Being able to store your players data in your database would then allow you to build ladders, top 100, etc.. type lists. But these kind of things maybe outside of your games scope.

Just curios not trying to start a language or technology war here but why did you decided to work in flash and not HTML5 Canvas, and JavaScript?

Thank you for the link.

To answer your question, I'm actually using both technologies right now, but for two different projects. I'm using HTML5 Canvas and Javascript for a different browser game that'll run on my own site (my own server as well). I've decided to also learn how to use PHP and SQL to implement a database structure as you mentioned earlier. I don't know much about AJAX or JSON, so those are two languages I'll have to add to my future research list.

I'm using Flash for this game because I'm uploading to a site that only supports .swf Flash games (I don't have access to the server). Mostly, I was just curious about the language. I love learning new things, and in the field of programming it's good to be familiar with many different technologies. I hope that clears things up!

Edit: Fixed grammar mistake.

Thanks I was just curious. Now it makes more sense why you can't store the player data in a database.

Just a small correction on your thinking. JSON and AJAX are not languages but just a term that is used with JavaScript. JSON (JavaScript Object Notation) is a way to serialize your JavaScript objects for transport across a network. And AJAX (Asynchronous JavaScript and XML) is the means to dynamically send and receive data between your web application and your web server without having to do a full page reload. But both are a JavaScript based technology. So the good news is if you have already learned JavaScript then you already have a head start on using these two terms.

It is really good to hear you want to learn more than one language.

I'd say the ui answer has a lot to do with what kind of game it is. Of the three examples #3, cooking mama probably delivers the most immersive experience due to the fact that being on a single, clean, screen lets you focus best on a task. If your game pacing is meant to be more franti, papa's style is probably better.

So in short the not helpful reply here is it depends on the feel you want to deliver :)

Just a small correction on your thinking. JSON and AJAX are not languages but just a term that is used with JavaScript. JSON (JavaScript Object Notation) is a way to serialize your JavaScript objects for transport across a network. And AJAX (Asynchronous JavaScript and XML) is the means to dynamically send and receive data between your web application and your web server without having to do a full page reload. But both are a JavaScript based technology. So the good news is if you have already learned JavaScript then you already have a head start on using these two terms.

Oh, Ok. My background is in C++, so I'm not familiar with all web technologies just yet.

I'd say the ui answer has a lot to do with what kind of game it is. Of the three examples #3, cooking mama probably delivers the most immersive experience due to the fact that being on a single, clean, screen lets you focus best on a task. If your game pacing is meant to be more franti, papa's style is probably better.

So in short the not helpful reply here is it depends on the feel you want to deliver

First comment on the UI question. Thanks for answering. I just wanted to know which one seemed to be the clearest and cleanest to other people. I could reasonably make any of them more frantic by increasing the number of customers. So that's one vote for the Cooking Mama style.

Hye On Rye,

DanglinBob is right, the UI is directly tied to the gameplay; so I cannot make a recommendation without a solid understanding of your gameplay. Any of these three examples can be similarly immersive, but any of these examples can similarly break immersion if not applied well. No one UI trumps the other, because it all depends on the gameplay.

I can at least give some general UI advice for your casual browser game. What's the most intuitive input device for PC users? That's the mouse. The most hardcore games make full use of the keyboard + mouse. The most casual games can be controlled 100% with the mouse alone. Even in many hardcore games (especially in the strategy genre) you can control everything with the mouse alone, and the keyboard serves only as an input device for shortcuts.

So let's consider all the input methods you have with a mouse in a flash game.

(1) Move up/down, move left/right

(2) Left-click

(3) Double left-click

(4) Left-hold (i.e., holding down the left mouse button)

(5) Hold, move, and drop (e.g., rectangle selection in Windows, dragging and dropping files)

All these inputs are intuitive for a casual PC gamer. From every day use in Windows and other applications, gamers have come to expect certain behavior when using this or that input. These are platform conventions. For usability, you want to stick as much as reasonable for your game to platform conventions. For accessibility, you may want to provide alternative input methods such as the keyboard. Not every PC gamer can use a mouse. The more alternative input methods you provide, the more accessible your UI.

Lastly, I point you to an excellent resource on UI design by Microsoft that will help you make better and clearer decisions yourself: Designing a User Interface (Windows). You may also wanna see if Adobe provides any documentation for UI design in Flash.

Good luck with your game! :P

Hye On Rye,


DanglinBob is right, the UI is directly tied to the gameplay; so I cannot make a recommendation without a solid understanding of your gameplay. Any of these three examples can be similarly immersive, but any of these examples can similarly break immersion if not applied well. No one UI trumps the other, because it all depends on the gameplay.

Ok. Thanks for responding! The thing is, I wasn't really inquiring about immersion. Just wanted to know which one you thought was most effective. By effective, I mean this: Do you, personally, mind switching between various screens during gameplay, or would you rather keep it on one screen (Cook, Serve, Delicious)? If you have to switch screens, would you rather do it manually (Papa's Freezeria) or have the game change it for you (Cooking Mama)? Taking this into consideration, which do you think would be more popular with casual gamers, who aren't as used to playing hardcore games and want a quick, fun, and easy experience? Things like that. I should have linked short video clips to illustrate the differences I was originally asking about.

I was careful to choose screenshots from games that have the same type of gameplay, but implement a different UI. I already have a pdf that discusses general UI design. Just wanted a second opinion, that's all... I think it really comes down to whether or not I'll use one gameplay screen or multiple. The gameplay is going to be the same regardless, but I don't know if I want to split things into different screens or not. Personally, I prefer using one screen or automatically switching to the other screen if necessary. But I know that my preferences might differ from others, and I when I played video games, I mostly played console titles (not casual games).